Signed-off-by: Zhang Boyang
---
grub-core/commands/videotest.c | 4 +--
grub-core/font/font.c | 54 ++
grub-core/gfxmenu/font.c | 2 +-
grub-core/term/gfxterm.c | 2 +-
include/grub/font.h| 3 +-
5 files changed, 55 insertions(+),
Currently GRUB's default font is too small to see on a HiDPI monitor.
This patch adds preliminary HiDPI support to gfxterm. If default font
and a HiDPI monitor are both detected, it will scale the font size on
the fly.
Signed-off-by: Zhang Boyang
---
grub-core/term/gfxterm.c
later if this simple-but-slow
scaling code become performance bottleneck.
Best Regards,
Zhang Boyang
On 2022/5/31 19:36, Gerd Hoffmann wrote:
Hi,
+ /* FIXME: Scale bitmap pixel by pixel is slow */
So how about doing the scaling when loading the font,
so you have to do it only once?
a
malloc().
Best Regards,
Zhang Boyang
On 2022/5/31 20:51, Vladimir 'phcoder' Serbinenko wrote:
We should avoid mallocs on every character as mallocs can be slow. Can we
instead save scaled versions and reuse them so that we need to do mallocs
only once per glyph instead of every tim
This patch adds an argument 'scale' to grub_font_draw_glyph(). If
scale > 1, then the function will scale the bitmap of the drawing glyph,
and draw the scaled glyph. The scaled bitmap is cached in glyph itself,
so it can be reused if same glyph is used many times.
Signed-off-by:
Hi,
[PATCH v2] now caches scaled bitmaps in each corresponding glyph. So it
can be reused if same glyph is used many times.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Currently GRUB's default font is too small to see on a HiDPI monitor.
This patch adds preliminary HiDPI support to gfxterm. If default font
and a HiDPI monitor are both detected, it will scale the font size on
the fly.
Signed-off-by: Zhang Boyang
---
grub-core/term/gfxterm.c
void interger overflow during scaling, this patch intruduces
dimension limits to font files, described by GRUB_FONT_MAX_DIMENSION.
The scaled glyph should also obey this limit. In addition, scale factor
is also limited by GRUB_FONT_MAX_SCALE.
Signed-off-by: Zhang Boyang
---
grub-core/command
nction,
but I'm not sure whether a inline function is appropriate in grub headers.
+ \
+ __failed = grub_sub ((typeof(v))(align), 1, &a); \
The cast "(typeof(v))" is unnecessary and it will silen
Hi,
On 2024/5/18 15:52, Zhang Boyang wrote:
Hi,
On 2024/5/17 20:56, Gao Xiang wrote:
The following EROFS patch will use this helper to handle overflow
ALIGN_UP() cases.
Signed-off-by: Gao Xiang
---
include/grub/safemath.h | 16
1 file changed, 16 insertions(+)
diff
If set to other number, that number will be the scale
factor, overriding automatic scale factor calculation.
Signed-off-by: Zhang Boyang
---
docs/grub.texi | 11 ++
grub-core/gfxmenu/view.c | 1 +
grub-core/term/gfxterm.c | 72
include/grub/g
'gfxterm_scale'.
Changes in [PATCH v2 1/2]:
It now caches scaled bitmaps in each corresponding glyph. So it can be
reused if same glyph is used many times.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu
Hi,
This is a resend of my [PATCH v3].
Thank you.
Best Regards,
Zhang Boyang
===
Changes in [PATCH RESEND V3]:
Rebased to latest git head.
Changes in [PATCH V3]:
1/2: To avoid interger overflow during scaling, this patch intruduces
GRUB_FONT_MAX_DIMENSION and GRUB_FONT_MAX_SCALE. The font
void interger overflow during scaling, this patch intruduces
dimension limits to font files, described by GRUB_FONT_MAX_DIMENSION.
The scaled glyph should also obey this limit. In addition, scale factor
is also limited by GRUB_FONT_MAX_SCALE.
Signed-off-by: Zhang Boyang
---
grub-core/command
If set to other number, that number will be the scale
factor, overriding automatic scale factor calculation.
Signed-off-by: Zhang Boyang
---
docs/grub.texi | 11 ++
grub-core/gfxmenu/view.c | 1 +
grub-core/term/gfxterm.c | 72
include/grub/g
;case
0:" and "case 1:" may fix this problem.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
disk cache
invalidating. This patch also use "size + 1MB" as the size of new
region. This value can address the region overheads, and it can also
improve performance of small allocations when default heap is full.
Fixes: 887f98f0db43 (mm: Allow dynamically requesting additional memory regions)
disk
caches are always invalidated when almost every malloc() after default
heap size is exhausted.
However, I havn't reproduced the problem, so I haven't tested my patch.
I would appreciate if someone can test this patch.
Best Regard
On 2022/9/12 19:29, jim945 wrote:
After swapping "case 0:" and "case 1:" works fine.
Thanks for the information! I wrote a (better) patch based on the result.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub
Hi,
On 2022/9/12 23:03, Heinrich Schuchardt wrote:
On 9/12/22 16:19, Zhang Boyang wrote:
The code of dynamically adding new regions has two problems. First, it
always invalidate disk caches, which decreases performance severely.
Second, it request exactly "size" bytes for new region
coding 0x10.
Renamed "rsize" to "grow".
Check "grow" against sanity limits.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
f98f0db43 (mm: Allow dynamically requesting additional memory regions)
Signed-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 27 +++
include/grub/mm.h | 2 ++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/grub-core/kern/mm.c b/grub-core/kern/mm.c
index
+ align + GRUB_MM_MAX_COST).
For small chunks, it's adjusted to (GRUB_MM_GROW_SMALL +
GRUB_MM_MAX_COST) to improve performance.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB_MM_SIZE_SMALL requests, with GRUB_MM_MAX_COST denotes the extra
region management cost.
On platforms without dynamic heap growth support, default heap will be
created with GRUB_MM_TYPE_ALL, so any type of allocation can be
fulfilled by default heap.
Signed-off-by: Zhang Boyang
---
docs/grub
Previously, every heap grow will cause all disk caches invalidated,
which decreases performance severely. This patch moves disk cache
invalidation code to the last of memory squeezing measures, so disk
caches are released only when no other ways to get free memory.
Signed-off-by: Zhang Boyang
Previously, every heap grow will cause all disk caches invalidated,
which decreases performance severely. This patch moves disk cache
invalidation code to the last of memory squeezing measures, so disk
caches are released only when no other ways to get free memory.
Signed-off-by: Zhang Boyang
vate.h" from "mm.h".
Documented more details in comments.
* The allocation type patch will be posted later.
Best Regards,
Zhang Boyang
Changes in V2 -> V3:
1. Splited into two patches. One deal with the disk cache problem. The
other is focused on improvement.
2. Add types to reg
heap space
exhaustion, the size of heap growth is now expended to this value, and a
new region of bigger size will be added. Thus subsequent allocations can
use the remaining space of that new region.
Signed-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 18 +++---
include/grub/mm
perspective? I will probably go back to work on my
HiDPI patch after few weeks.
By the way, if I understand correctly, you patch seems reversed, and
your mail client seems corrupted your patch. You might find "git
format-patch" and "git send-email" useful :)
Best Regards,
Hi,
On 2022/10/20 20:50, Daniel Kiper wrote:
On Sat, Oct 15, 2022 at 10:15:12PM +0800, Zhang Boyang wrote:
Previously, there are two problems of the handling of adding new
Please drop "Previously". It is not needed...
regions. First, it doesn't take region management co
(size)` always success after a successful call to
`grub_mm_init_region (addr, size + GRUB_MM_MAX_COST)`.
The new region size is now set to `size + GRUB_MM_MAX_COST`, thus if
grub_mm_add_region_fn() succeeded, current allocation request can always
success.
Signed-off-by: Zhang Boyang
---
grub-core
GRUB_MM_HEAP_GROW.
(i.e. GRUB_MM_HEAP_GROW now doesn't take management cost into account)
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
igned-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 3 +++
include/grub/mm_private.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/grub-core/kern/mm.c b/grub-core/kern/mm.c
index 973cb6b15..83c618c5b 100644
--- a/grub-core/kern/mm.c
+++ b/grub-core/kern/mm.c
@@ -452,6 +
Hi,
On 2022/11/30 02:35, Steve McIntyre wrote:
Hey folks!
So, with the latest set of GRUB CVE patches we've fixed up a bunch of
potential crashes in font-handling code that could lead to Secure Boot
holes. These are good and useful fixes, and thanks to Zhang Boyang and
everyone else inv
Hi,
On 2022/12/1 00:08, Robbie Harwood wrote:
Zhang Boyang writes:
On 2022/11/30 02:35, Steve McIntyre wrote:
AFAIK Chris Coulson has a patch for the font loader to cause it to try
loading fonts from the embedded memdisk first. Is that the best
approach? If so, what fonts should we be
Hi,
PATCH 1-3 are additional fixes to font code.
PATCH 4-5 are the refactored and rebased version of HiDPI patches. They
add preliminary HiDPI support for gfxterm. There is no HiDPI support for
gfxmenu yet.
Best Regards,
Zhang Boyang
___
Grub-devel
If set to other number, that number will be the scale
factor, overriding automatic scale factor calculation.
Signed-off-by: Zhang Boyang
---
docs/grub.texi | 11
grub-core/gfxmenu/view.c | 1 +
grub-core/term/gfxterm.c | 120 ---
include/grub/gf
is patch also adds a new metadata entry named MAXS to font files,
limiting the maximum acceptable scale factor at runtime for a specific
font. Currently MAXS is set to 8, which is sufficient for 16K monitors.
Signed-off-by: Zhang Boyang
---
grub-core/commands/videotest.c | 4 +-
grub-cor
If max_char_width or max_char_height is negative, bad values might be
propagated by grub_font_get_max_char_width() or
grub_font_get_max_char_height(). Prevent this from happening.
Signed-off-by: Zhang Boyang
---
grub-core/font/font.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
There is a problem in ascii_glyph_lookup(). It doesn't check the return
value of grub_malloc(). If memory can't be allocated, then NULL pointer
will be written to.
This patch fixes the problem by fallbacking to unknown_glyph in case of
grub_malloc() returns NULL.
Signed-off-by: Zh
Like glyphs in ascii_font_glyph[], assign null_font to
unknown_glyph->font in order to prevent grub_font_get_*() from
dereferencing NULL pointer.
Signed-off-by: Zhang Boyang
---
grub-core/font/font.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/grub-core/font/font.c b/grub-core/f
On 2022/12/5 19:29, Zhang Boyang wrote:
This patch also adds a new metadata entry named MAXS to font files,
limiting the maximum acceptable scale factor at runtime for a specific
font. Currently MAXS is set to 8, which is sufficient for 16K monitors.
Oh, I forgot to delete this paragraph of
Major differences between these wrappers
and normal UEFI images are:
* DLL flag is set (nobody cares)
* Entry point is set to 0 (shim rejects this)
* Subsystem is set to Windows GUI instead of EFI Application (tianocore
rejects this)
Signed-off-by: Zhang Boyang
---
.giti
in shim to sign wrappers (this
seems like exactly what we are doing for GRUB itself).
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
quent read
operations will operate on unwrapped data. If error occurred during
unwrapping, e.g. file is not wrapped, it passthroughs original file.
Currently, this filter only operate on font files (GRUB_FILE_TYPE_FONT),
and they must be wrapped with section name set to ".GRUBpf2".
Signe
patch fixes the problem by introducing PE requirements checks to
shim lock verifier. For kernel images, it now only says ok to files
marked as EFI Application (wrappers are marked as Windows GUI).
Signed-off-by: Zhang Boyang
---
grub-core/kern/efi/sb.c | 37 +++--
1
Since font files can be wrapped as PE images by grub-wrap, use shim to
verify font files if Secure Boot is enabled. To prevent other PE files
(e.g. kernel images) used as wrappers, it only allows files marked as
Windows GUI used as wrappers.
Signed-off-by: Zhang Boyang
---
grub-core/kern/efi
now).
Nevertheless, I think it's good to have both my patches and your
patches, because I think we are focusing on different things.
Best Regards,
Zhang Boyang
Also thank you for your recommendation for the patch submission.
I will attempt to send another reply to this thread with th
new to the grub process I am not sure how to get the changes in.
I'm also new to GRUB (and other open source projects) So please
forgive me if I said something misleading.
Best Regards,
Zhang Boyang
Thank you and best
Markus
Zhang Boyang schrieb am Sa., 10. Dez. 2022,
12:32:
n't
use better Unicode codepoints. */
- N_("[WxH[xD]]"),
- N_("List available video modes. If "
- "resolution is given show only
Hi,
On 2022/12/13 21:48, Daniel Kiper wrote:
On Tue, Nov 29, 2022 at 10:17:33PM +0800, Zhang Boyang wrote:
When grub_memalign() encounters out-of-memory, it will try
grub_mm_add_region_fn() to request more memory from system firmware.
However, the size passed to it doesn't take r
Hi,
This is the v2 patchset. V1 is at
https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00147.html
For changes, please see my replys to Daniel.
Best Regards,
Zhang Boyang
Zhang Boyang (2):
mm: Adjust new region size to take management overhead into account
mm: Preallocate some
new
constant should make grub_malloc(size) always success after a successful
call to grub_mm_init_region(addr, size + GRUB_MM_MGMT_OVERHEAD).
The new region size is now set to "size + GRUB_MM_MGMT_OVERHEAD", thus
if grub_mm_add_region_fn() succeeded, current allocation request can
always su
quest is small.
The value of GRUB_MM_HEAP_GROW_EXTRA is set to 1MB. If this value is
smaller, the cost of small memory allocations will be higher. If this
value is larger, more memory will be wasted and it might cause
out-of-memory on machines with small amount of RAM.
Signed-off-by: Zhang B
uot; passed to grub_mm_add_region_fn() will include these overhead and
there is no need to add them in arch specific code.
Best Regards,
Zhang Boyang
+ total = grub_min (free_memory - RUNTIME_MIN_SPACE, total);
+
+ grub_dprintf ("ieee1275", "fallback
GRUB.
It should be pointed out that the version string is only consisted of
PACKAGE_VERSION. Any difference not reflected in PACKAGE_VERSION is not
noticed by version check (e.g. configure options).
Signed-off-by: Zhang Boyang
---
grub-core/Makefile.am | 2 +-
grub-core/genmod.sh.in
Hi,
(sorry for duplicate emails because I forgot to add CCs)
On 2022/12/21 06:58, Robbie Harwood wrote:
Zhang Boyang writes:
This patch add version information to GRUB modules. Specifically,
PACKAGE_VERSION is embedded as null-terminated string in .modver
section. This string is checked at
Hi,
On 2022/12/21 03:04, Glenn Washburn wrote:
On Mon, 19 Dec 2022 23:33:29 +0800
Zhang Boyang wrote:
This patch add version information to GRUB modules. Specifically,
PACKAGE_VERSION is embedded as null-terminated string in .modver
section. This string is checked at module loading time
Hi,
On 2022/12/21 10:43, Pete Batard via Grub-devel wrote:
Hello all,
On 2022.12.20 22:58, Robbie Harwood wrote:
Zhang Boyang writes:
This patch add version information to GRUB modules. Specifically,
PACKAGE_VERSION is embedded as null-terminated string in .modver
section. This string is
will be a 'core.img' that can work for USB BIOS boot of a
MBR partitioned FAT or NTFS media, and that even a GRUB based ISOHybrid
image will not readily provide.
Zhang Boyang wrote:
The situation is, for BIOS boot, there is no grub core file in ISO
because it's written to sectors i
ed of
PACKAGE_VERSION. Any difference not reflected in PACKAGE_VERSION is not
noticed by version check (e.g. configure options).
Link: https://lists.gnu.org/archive/html/grub-devel/2022-12/msg00228.html
Link: https://lists.gnu.org/archive/html/grub-devel/2022-12/msg00229.html
Signed-off-by: Zhang Boyang
---
Hi,
On 2022/12/21 01:16, Daniel Kiper wrote:
Please do not send your new sets of patches as a reply to previous
discussions. If you do that then it is more difficult to find them
in threaded views.
OK. I will not do that in future.
On Thu, Dec 15, 2022 at 07:19:23PM +0800, Zhang Boyang
RUB_MM_MGMT_OVERHEAD", thus if grub_mm_add_region_fn() succeeded,
current allocation request can always success.
Signed-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 54 +++--
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/grub-core/ke
tions request is small.
The value of GRUB_MM_HEAP_GROW_EXTRA is set to 1MB. If this value is
smaller, the cost of small memory allocations will be higher. If this
value is larger, more memory will be wasted and it might cause
out-of-memory on machines with small amount of RAM.
Signed-off-by: Zhang B
250.html
Best Regards,
Zhang Boyang
Zhang Boyang (2):
mm: Adjust new region size to take management overhead into account
mm: Preallocate some space when adding new regions
grub-core/kern/mm.c | 58 +++--
1 file changed, 56 insertions(+), 2 deleti
r_register().
Best Regards,
Zhang Boyang
For this purpose, rather than returning error, this patch prints log
and returns file handler.
Signed-off-by: Leo Yan
---
grub-core/kern/verifiers.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/grub-core/kern/verifier
Hi,
On 2022/12/22 20:22, Leo Yan wrote:
Hi Boyang,
On Thu, Dec 22, 2022 at 07:25:13PM +0800, Zhang Boyang wrote:
Hi,
On 2022/12/22 19:14, Leo Yan wrote:
When boot from menu and the flag GRUB_VERIFY_FLAGS_DEFER_AUTH is set,
grub returns error:
Booting a command list
error
ique for one given vendor (signer). For example, version
string need to be different for Debian 10 and Debian 11 even they both
use GRUB 2.06, and no two build in Debian 10 (or Debian 11) have same
version string.
Best Regards,
Zhang Boyang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
t have any effect if GRUB is locked down.
It should be pointed out that the version string is only consisted of
PACKAGE_VERSION. Any difference not reflected in PACKAGE_VERSION is not
noticed by version check (e.g. configure options).
Link: https://lists.gnu.org/archive/html/grub-devel/2022
hipping another bunch of core.img. However,
since I'm not a expert of this area, please point out if I said
something wrong.
Best Regards,
Zhang Boyang
On 2022/12/23 02:16, Pete Batard wrote:
I'm sorry but that's NO_GO for me.
This is a major step back from v2, where the check was
Hi,
On 2022/12/22 14:31, Glenn Washburn wrote:
On Wed, 21 Dec 2022 20:11:57 +0800
Zhang Boyang wrote:
+ grub_printf_ (N_("warning: module %.63s has incorrect version:
%.63s != %s\n"),
+ mod->name, modver, PACKAGE_VERSION);
I don't quite like this
Hi,
On 2022/12/23 21:07, Pete Batard wrote:
On 2022.12.23 07:18, Zhang Boyang wrote:
This feature is implemented in kern/dl.c in core.img, which is UNDER
YOUR CONTROL.
Let me analyze the worst case from your perspective:
1) Every distro is enforcing version check, even in BIOS mode.
2
On 2022/12/24 00:44, Zhang Boyang wrote:
- || grub_dl_check_version (mod, e)
+ || (1||grub_dl_check_version (mod, e))
Oh, there is a small error, it should be:
- || grub_dl_check_version (mod, e)
+ || (0 && grub_dl_check_version (mod, e))
Best Regards,
Zhan
isabled by "--without-vermagic". However, this option has no effect if
GRUB is locked down (mismatched modules will be always rejected with an
error message in this case).
Signed-off-by: Zhang Boyang
---
config.h.in | 3 +++
configure.ac | 24 +
27;t
help in vermagic check
4) If there is no vermagic check, it's possible to load GRUB 2.YY modules into
GRUB 2.XX (and vice versa)
5) However, due to some changes in API or ABI, although unlikely, there is
possibility that there are vulnerabilities when using GRUB 2.YY modules with
Hi,
On 2022/12/26 16:13, Leo Yan wrote:
Hi Boyang,
On Thu, Dec 22, 2022 at 10:37:01PM +0800, Zhang Boyang wrote:
[...]
On 2022/12/22 19:14, Leo Yan wrote:
When boot from menu and the flag GRUB_VERIFY_FLAGS_DEFER_AUTH is set,
grub returns error:
Booting a command list
error
Hi,
On 2023/1/12 21:52, Daniel Kiper wrote:
On Thu, Dec 22, 2022 at 05:18:23PM +0800, Zhang Boyang wrote:
When grub_memalign() encounters out-of-memory, it will try
grub_mm_add_region_fn() to request more memory from system firmware.
However, the size passed to it doesn't take r
ase see my reply at:
https://lists.gnu.org/archive/html/grub-devel/2023-01/msg00099.html
Best Regards,
Zhang Boyang
Zhang Boyang (2):
mm: Adjust new region size to take management overhead into account
mm: Preallocate some space when adding new regions
grub-core/kern/mm.c |
tions request is small.
The value of GRUB_MM_HEAP_GROW_EXTRA is set to 1MB. If this value is
smaller, the cost of small memory allocations will be higher. If this
value is larger, more memory will be wasted and it might cause
out-of-memory on machines with small amount of RAM.
Signed-off-by: Zhang B
if grub_mm_add_region_fn() succeeded, current allocation request
can always success.
Signed-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 64 ++---
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/grub-core/kern/mm.c b/grub-core/kern/mm.c
index ae
Hi,
Sorry for late reply...
On 2023/1/19 23:36, Daniel Kiper wrote:
I looked at this patch again and found a few more (minor) issues...
On Sat, Jan 14, 2023 at 09:23:22PM +0800, Zhang Boyang wrote:
When grub_memalign() encounters out-of-memory, it will try
grub_mm_add_region_fn() to request
rub-devel/2022-12/msg00271.html
V2 is at:
https://lists.gnu.org/archive/html/grub-devel/2022-12/msg00164.html
V1 is at:
https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00147.html
Best Regards,
Zhang Boyang
Zhang Boyang (3):
mm: Adjust new region size to take management overhead i
rrectly adjusted,
thus if grub_mm_add_region_fn() succeeded, current allocation request
can always succeed.
Signed-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 64 ++---
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/grub-core/kern/mm.c b/grub-core/
tions request is small.
The value of GRUB_MM_HEAP_GROW_EXTRA is set to 1MB. If this value is
smaller, the cost of small memory allocations will be higher. If this
value is larger, more memory will be wasted and it might cause
out-of-memory on machines with small amount of RAM.
Signed-off-by: Zhang B
also help compiler to optimize interger overflow checks away.
Signed-off-by: Zhang Boyang
---
grub-core/kern/mm.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/grub-core/kern/mm.c b/grub-core/kern/mm.c
index c3d96e2b0..94eb29108 100644
--- a
85 matches
Mail list logo
