Re: [PATCH V2] i386: Using 64-bit boot protocol for 64-bit linux kernel

[Wei Zhang]

Daniel Kiper 于2022年8月20日 周六19:01写道：

> On Fri, Aug 12, 2022 at 01:39:42PM +0800, Wei Zhang wrote:
> > On Fri, Aug 12, 2022 at 1:18 AM Daniel Kiper 
> wrote:
> > > On Thu, Aug 04, 2022 at 11:07:30PM +0800, Wei Zhang wrote:
> > > > On Wed, Aug 3, 2022 at 11:33 PM Daniel Kiper 
> wrote:
> > > > > On Sat, Jul 23, 2022 at 07:20:43PM +0800, Wei Zhang wrote:
> > > > > > From: Wei Zhang 
> > > > > >
> > > > > > Currently GRUB boots linux with 32-bit protocol for 64 bit
> kernel.
> > > > > > Thus if both GRUB and linux kernel are in 64-bit, we'll have to
> go
> > > > > > through 64-bit grub -> 32-bit boot protocol -> 64-bit kernel
> > > > > > transitions, and extra instructions have to be executed in the
> kernel.
> > > > > >
> > > > > > Since linux has long ago supported 64-bit boot protocol, we can
> take
> > > > > > advantage of that to directly boot to 64-bit kernel.
> > > > > >
> > > > > > To do this, first we determine whether the kernel is 64-bit by
> > > > > > xloadflags (since linux boot protocol 2.12), then we build the
> > > > > > identity-mapped page table required by the 64-bit kernel, and
> that's
> > > > > > it. The memory needed by the page table is allocated after the
> > > > > > protected kernel image proper.
> > > > > >
> > > > > > So if we're in 32-bit GRUB to boot a 64-bit kernel, the
> transition
> > > > > > will happen before handing over to the kernel, and if we're in
> 64-bit
> > > > > > GRUB, we don't have to go down to 32-bit and back to 64-bit. The
> > > > > > 32-bit kernel boot process will not be affected.
> > > > > >
> > > > > > Tested on my 64-bit machine and QEMU.
> > > > >
> > > > > Could you tell us what target and platform you configure for the
> GRUB?
> > > > > Or send us full GRUB configure command you use?
> > > >
> > > > Sure, I mainly focused on x86, and my configure command is:
> > > > ./configure --target=x86_64 --with-platform=efi
> > >
> > > This is what I expected. I appreciate your work. Sadly this is not
> > > a direction which we are heading. So, I have to NAK your patch.
> >
> > That's OK. This is just a random thought I had when I was going
> > through the kernel boot code, and I'm happy that you took a look.
> >
> > > However,
> > > if you want to improve the EFI boot protocol in the GRUB please take
> > > a look at [1] and my comments starting at [2]. I would really want to
> > > see the patch set at [1] updated and at some point merged into the GRUB
> > > upstream.
> >
> > I haven't looked into it, but I'll take it if it's not too far beyond my
> scope:)
>
> FYI, Ard reposted it [1].
>
> Daniel
>
> [1] https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00187.html


>
Right, I saw it last night too, thanks.

-- 
Wei Zhang
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] kern/efi/mm: Double the default heap size

[Heinrich Schuchardt]

On 8/20/22 17:24, Hector Martin via Grub-devel wrote:

GRUB is already running out of memory on Apple M1 systems, causing
graphics init to fail, as of the latest Git changes. Since dynamic
growing of the heap isn't done yet, double the default heap size for
now.

Signed-off-by: Hector Martin 
---
  grub-core/kern/efi/mm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index d290c9a76270..377d8d3a1c1b 100644
--- a/grub-core/kern/efi/mm.c
+++ b/grub-core/kern/efi/mm.c
@@ -39,7 +39,7 @@
  #define MEMORY_MAP_SIZE   0x3000
  
  /* The default heap size for GRUB itself in bytes.  */

-#define DEFAULT_HEAP_SIZE  0x10
+#define DEFAULT_HEAP_SIZE  0x20


GRUB's memory is allocated as LoaderCode and therefore released at 
ExitBootServices(). There should be no problem to allocate even much 
higher amounts of memory.


Reviewed-by: Heinrich Schuchardt 

Beyond the scope of this patch:

Using LoaderCode here seems wrong. Heap should be LoaderData.

The problematic part of heap allocation is function add_memory_regions() 
that does not let AllocatePages() do its job to find a fitting region 
but just forces a random free memory region. It would be preferable to 
call AllocatePages() not with GRUB_EFI_ALLOCATE_ADDRESS but with 
GRUB_EFI_ALLOCATE_MAX_ADDRESS to avoid problems on architectures that 
want to move the kernel into low memory.


Best regards

Heinrich

  
  static void *finish_mmap_buf = 0;

  static grub_efi_uintn_t finish_mmap_size = 0;



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] kern/efi/mm: Double the default heap size

[Hector Martin via Grub-devel]

GRUB is already running out of memory on Apple M1 systems, causing
graphics init to fail, as of the latest Git changes. Since dynamic
growing of the heap isn't done yet, double the default heap size for
now.

Signed-off-by: Hector Martin 
---
 grub-core/kern/efi/mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index d290c9a76270..377d8d3a1c1b 100644
--- a/grub-core/kern/efi/mm.c
+++ b/grub-core/kern/efi/mm.c
@@ -39,7 +39,7 @@
 #define MEMORY_MAP_SIZE0x3000
 
 /* The default heap size for GRUB itself in bytes.  */
-#define DEFAULT_HEAP_SIZE  0x10
+#define DEFAULT_HEAP_SIZE  0x20
 
 static void *finish_mmap_buf = 0;
 static grub_efi_uintn_t finish_mmap_size = 0;
-- 
2.35.1


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Remove HFS support

[Daniel Axtens]

"Vladimir 'phcoder' Serbinenko"  writes:

> No go from me either. Older macs may not be able to read HFS+ /boot. Also
> HFS+ presents couple of problems the biggest one is that in case of sudden
> reboot HFS+ often needs to be mounted by OSX or cleaning dirty flag
> manually before it becomes writeable.

I don't understand what you mean about the HFS+ dirtying issue. Aren't
grub's accesses to the file-system read-only anyway?

I'd really genuinely like to know how old a mac has to be not to support
booting from HFS+, a filesystem that came out around 1998, ~24 years
ago. I'd also like to know what use people have for running modern grub
on a machine that old.

Kind regards,
Daniel


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Remove HFS support

[Daniel Axtens]

>> As Daniel Axtens has been finding out, the HFS code is terrible in
>> terms of security. If you still need it for old/semi-dead machines,
>> maybe you should fork an older grub release and stay with that?
>
> I don't know what should be the deal with the security of a boot loader
> to be honest. If someone has access to your hardware so they can control
> your bootloader, you have much worse problems anyway.
>
> Forking is also a terrible idea as every forked package means having to
> track it manually.

Not to engage in the Debian specific parts of this, but fwiw the threat
model isn't hardware access. Firmware-enforced secure boot (e.g. UEFI,
AIX and Linux on PowerVM, whatever modern macs do) basically goes:

 - assume an attacker gets root on a running system
 - prevent the attacker from compromising the kernel

On Linux this takes 2 parts: some form of signing grub that gets
validated by firmware, and lockdown mode once Linux is booted.

Now I haven't really used a PowerMac since I was a kid, but if memory
serves, they had no concept of this. If you got access to Mac OS (or if
you got root on linux), there is no way to protect the kernel. There is,
in effect, no security boundary between root and the kernel.

Kind regards,
Daniel

>
> Adrian
>
> -- 
>   .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>`-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Remove HFS support

[Daniel Axtens]

"Vladimir 'phcoder' Serbinenko"  writes:

> Le ven. 19 août 2022, 21:05, Dimitri John Ledkov <
> dimitri.led...@canonical.com> a écrit :
>
>> There is no need for that code on any signed grubs or upstream. Ports that
>> want to support this patch can have it conditionally compiled / enabled
>> only on that arch, but not other.
>>
>> For example, in Ubuntu we already use separate builds for signed &
>> unsigned bootloaders. Or one may keep grub-2.06 as separate source package.
>> It's not like those old platforms need any new features in the bootloader
>> ever again.
>>
>> The issue of insecure code is for signed bootloaders. Because there is a
>> separate level of protection that prevents replacing arbitrary bootloaders
>> (whilst potentially allow downgrade/upgrade attacks). Thus a responsible
>> upstream should drop this code.
>>
>
> This kind of consideration was taken into account when designing security
> system and even when GRUB2 itself was designed. The solution is modules
> whitelist. There are many modules that can be dropped from signed build not
> just filesystems but also commands or loaders. There is no need to cut old
> systems from new grub if existing infrastructure can handle it.

At least one grub binary signed as part of the UEFI shim process
contains the HFS code. (I'm not involved in the process that signs off
on what should be permitted in a signed grub.) Fortunately, the patch I
wrote earlier to disable HFS in lockdown should be sufficient to protect
the users of that binary.

That binary comes from one of the larger software companies in the
world, and passed the shim signing process. If they got a shim signed
that trusts a grub with HFS built in, I'm not sure we can really trust a
module whitelist as a good way to protect end users.

You ask in your other email what my concerns with the HFS code are and
how it could be fixed. The HFS code crashes when fuzz tested: that is,
you can construct a number of HFS images such that `grub-fstest hfs.img
ls '(loop0)/'` crashes. (There is public information on fuzzing grub
now, and that information is sufficient to reproduce the crashes I've
found. I can also provide sample crashing inputs.) It would be really
nice if the file systems in grub could survive malicious input, even if
ideally they would not be built into a signed grub binary.

Kind regards,
Daniel
>
>
>> On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, <
>> glaub...@physik.fu-berlin.de> wrote:
>>
>>> On 8/19/22 20:09, Steve McIntyre wrote:
>>> > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz
>>> wrote:
>>> >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper 
>>> wrote:
>>> >>>
>>> >>> If I do not hear any major objections in the following weeks I will
>>> >>> merge this patch or a variant of it in the second half of September.
>>> >>
>>> >> We’re still formatting our /boot partitions for Debian PowerPC for
>>> >> PowerMacs using HFS, so this change would be a breaking change for
>>> >> us.
>>> >>
>>> >> So, that would be a no from Debian’s side.
>>> >
>>> > Not so fast please, Adrian. At the risk of sounding harsh, non-release
>>> > old ports like powerpc *really* don't get to dictate things in Debian
>>> > terms.
>>>
>>> Add "Ports" to this.
>>>
>>> > As Daniel Axtens has been finding out, the HFS code is terrible in
>>> > terms of security. If you still need it for old/semi-dead machines,
>>> > maybe you should fork an older grub release and stay with that?
>>>
>>> I don't know what should be the deal with the security of a boot loader
>>> to be honest. If someone has access to your hardware so they can control
>>> your bootloader, you have much worse problems anyway.
>>>
>>> Forking is also a terrible idea as every forked package means having to
>>> track it manually.
>>>
>>> Adrian
>>>
>>> --
>>>   .''`.  John Paul Adrian Glaubitz
>>> : :' :  Debian Developer
>>> `. `'   Physicist
>>>`-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>>
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Remove HFS support

[Daniel Axtens]

John Paul Adrian Glaubitz  writes:

>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper  wrote:
>> 
>> On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
>>> HFS is so so very old now. According to Wikipedia, HFS was
>>> introduced in 1985 and the successor HFS+ came out in January
>>> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
>>> support for reading HFS in 2019 with macOS 10.15.
>>> 
>>> Grub's support for it doesn't survive contact with a fuzzer, and
>>> the issues involve some horrible mess of mutual recursion that
>>> would be time-consuming to sort out.
>>> 
>>> HFS has been disabled under lockdown since commit 1c15848838d9
>>> ("fs/hfs: Disable under lockdown") which was part of an earlier
>>> spin of security fixes.
>>> 
>>> I think it's time to consign HFS to the dustbin of history. It's
>>> firmly in the category of retrocomputing at this stage.
>>> 
>>> This should not affect HFS+.
>>> 
>>> There's a little bit of mess remaining: the macbless runtime
>>> command and HFS+ need the HFS headers for embedded volume support.
>>> I don't think that's really deployed any more, as it would have
>>> been part of the HFS->HFS+ transition, but I'm not really game to
>>> mess with either, in particular as macbless writes(!) to disk live.
>>> (I'm fairly sure the grub-macbless tool invokes code from the
>>> macbless module as well.)
>>> 
>>> Signed-off-by: Daniel Axtens 
>> 
>> Reviewed-by: Daniel Kiper 
>> 
>> Daniel, thank you for preparing this patch!
>> 
>> If I do not hear any major objections in the following weeks I will
>> merge this patch or a variant of it in the second half of September.
>
> We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs 
> using HFS, so this change would be a breaking change for us.
>

Really, plain HFS, not HFS+? Wowsers!

Just to be clear, by PowerMacs you mean Macs with PowerPC chips, so
machines last produced around 2006?

Have you checked that you can't boot them with HFS+? Because HFS+
came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
I'd be really surprised if the firmware didn't support booting from
HFS+. I'd be very keen to hear.

Anyway, if I've understood correctly, the _most recent_ PowerMacs date
from around 16 years ago, and potentially the machines broken by this
would be even older. I still think that's in the domain of
retrocomputing and I don't understand the use case for running modern
software on something where the performance per watt is worse than a
recent raspberry pi.

Kind regards,
Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries

[Daniel Kiper]

On Tue, Aug 16, 2022 at 12:07:06PM -0400, Robbie Harwood wrote:
> Raymund Will  writes:
>
> > Hi,
> >
> > please let me try to add a bit of context and explain three IMHO
> > crucial points of the proposed patch.
> >
> > First, it is meant to work without any changes to config-files
> > on 'linux'-systems, simply by calling `grub-emu --kexec`.
> > And, called this way, it actually uses `systemctl kexec` exclusively
> > to instruct `systemd` to perform the "kexec"-reboot in a sane and
> > safe manner.
> >
> > Second, it only supports a very limited set of commands in `grub.cfg`,
> > as `grub-emu` can not implement the full functionality of a firmware-
> > loaded `grub` binary (like raw-device access) and it hinges massively
> > on proper `kexec`-support from the machine/firmware, so unfortunately
> > it won't be universally useful,
> >
> > Third, for use in a "pre-boot environment" (i.e. initrd/chroot), which
> > has full control over it's state, but no (fully) working `systemd`,
> > a call to `grub-emu --kexec --kexec` changes the behavior to allow a
> > fall-forward to `kexec -e`.  As a safe-guard for the adventurously
> > minded `systemctl kexec` is still tried first!
> >
> > This third point describes the use-case the original patch-set was
> > developed for and the second doesn't hurt (much) on the systems it
> > is deployed/used in the field.  But the first was found to be really
> > useful, especially on machines, which can reliably `kexec`, but are
> > dead slow through cold-boot (think "huge memory", "tons of devices")
> > and/or have "exotic" console setups ("3215" anybody?).  Note that,
> > as the boot configuration (namely `grub.cfg`) wasn't changed, regular
> > boot can't be affected by this short-cut (particularly, when `kexec`
> > might have failed).
> >
> > Granted, the duplication of `--kexec` to signify "force it", might
> > as well be spelled out as `--force-kexec` (or something similar).
> > (But that change will provoke inconsistencies during an indefinite
> > migration phase, where pre-boot images don't match binaries in the
> > root filesystem, notably, when rollback snapshots come into play.)
>
> Passing --kexec twice (or --force-kexec) doesn't appear to change
> anything in the versions of this patch I can easily find.  We could add

Yeah, I think Raymund is talking about a bit different version of the
patch. Raymund, could you provide us the one which has that features,
and potentially others, implemented?

> the behavior you're describing though - Daniel, would that help with
> your concerns about it?

I would prefer --force-kexec but if double --kexec is used in existing
environments I am OK with the latter. However, please document this
behavior in the GRUB's docs.

> > Config-overrides in `grub.cfg` in turn would be a nice addition, but
> > are relatively expensive to implement, as they'd probably need to be
> > parsed and split into an array for `grub_util_exec()`, right?
>
> Yes.  It's inevitably best-effort, especially if we can't depend on a
> working shell.

I would prefer to have "config-overrides" but if it requires tons of
work I am OK with existing implementation, +/- minor tweaks/fixes,
assuming its assumptions and limitations are properly documented.

> > But, please, still leave sane defaults in the binary, for out-of-
> > the-box, no-config-changes-necessary usage, pretty please!

As I said earlier, I am (mostly) OK with current defaults.

> > Would it be possible to re-evaluate the proposed patch with this
> > in mind?

Yep!

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH V2] i386: Using 64-bit boot protocol for 64-bit linux kernel

[Daniel Kiper]

On Fri, Aug 12, 2022 at 01:39:42PM +0800, Wei Zhang wrote:
> On Fri, Aug 12, 2022 at 1:18 AM Daniel Kiper  wrote:
> > On Thu, Aug 04, 2022 at 11:07:30PM +0800, Wei Zhang wrote:
> > > On Wed, Aug 3, 2022 at 11:33 PM Daniel Kiper  wrote:
> > > > On Sat, Jul 23, 2022 at 07:20:43PM +0800, Wei Zhang wrote:
> > > > > From: Wei Zhang 
> > > > >
> > > > > Currently GRUB boots linux with 32-bit protocol for 64 bit kernel.
> > > > > Thus if both GRUB and linux kernel are in 64-bit, we'll have to go
> > > > > through 64-bit grub -> 32-bit boot protocol -> 64-bit kernel
> > > > > transitions, and extra instructions have to be executed in the kernel.
> > > > >
> > > > > Since linux has long ago supported 64-bit boot protocol, we can take
> > > > > advantage of that to directly boot to 64-bit kernel.
> > > > >
> > > > > To do this, first we determine whether the kernel is 64-bit by
> > > > > xloadflags (since linux boot protocol 2.12), then we build the
> > > > > identity-mapped page table required by the 64-bit kernel, and that's
> > > > > it. The memory needed by the page table is allocated after the
> > > > > protected kernel image proper.
> > > > >
> > > > > So if we're in 32-bit GRUB to boot a 64-bit kernel, the transition
> > > > > will happen before handing over to the kernel, and if we're in 64-bit
> > > > > GRUB, we don't have to go down to 32-bit and back to 64-bit. The
> > > > > 32-bit kernel boot process will not be affected.
> > > > >
> > > > > Tested on my 64-bit machine and QEMU.
> > > >
> > > > Could you tell us what target and platform you configure for the GRUB?
> > > > Or send us full GRUB configure command you use?
> > >
> > > Sure, I mainly focused on x86, and my configure command is:
> > > ./configure --target=x86_64 --with-platform=efi
> >
> > This is what I expected. I appreciate your work. Sadly this is not
> > a direction which we are heading. So, I have to NAK your patch.
>
> That's OK. This is just a random thought I had when I was going
> through the kernel boot code, and I'm happy that you took a look.
>
> > However,
> > if you want to improve the EFI boot protocol in the GRUB please take
> > a look at [1] and my comments starting at [2]. I would really want to
> > see the patch set at [1] updated and at some point merged into the GRUB
> > upstream.
>
> I haven't looked into it, but I'll take it if it's not too far beyond my 
> scope:)

FYI, Ard reposted it [1].

Daniel

[1] https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00187.html

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] luks2: Continue trying all keyslots even if there are some failures

[Patrick Steinhardt]

On Fri, Aug 19, 2022 at 04:10:44PM +0200, Daniel Kiper wrote:
> On Mon, Aug 15, 2022 at 05:23:15PM +0200, Patrick Steinhardt wrote:
> > On Fri, Jul 22, 2022 at 03:04:50AM -0500, Glenn Washburn wrote:
> > > luks2_get_keyslot can fail for a variety of reasons that do not 
> > > neccesarily
> > > mean the next keyslot should not be tried (eg. a new kdf type). So always
> > > try the next slot. This will make GRUB more resilient to non-spec json 
> > > data
> > > that 3rd party systems may add. We do not care if some of the keyslots are
> > > unusable, only if there is at least one that is.
> > >
> > > Signed-off-by: Glenn Washburn 
> > > ---
> > >  grub-core/disk/luks2.c | 10 +-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/grub-core/disk/luks2.c b/grub-core/disk/luks2.c
> > > index bf741d70f..d8d3180ed 100644
> > > --- a/grub-core/disk/luks2.c
> > > +++ b/grub-core/disk/luks2.c
> > > @@ -610,7 +610,15 @@ luks2_recover_key (grub_disk_t source,
> > >grub_errno = GRUB_ERR_NONE;
> > >ret = luks2_get_keyslot (, , , json, 
> > > json_idx);
> > >if (ret)
> > > - goto err;
> > > + {
> > > +   /*
> > > +* luks2_get_keyslot can fail for a variety of reasons that do not
> > > +* neccesarily mean the next keyslot should not be tried (eg. a new
> > > +* kdf type). So always try the next slot.
> > > +*/
> > > +   grub_dprintf ("luks2", "Failed to get keyslot %" PRIuGRUB_UINT64_T 
> > > "\n", keyslot.idx);
> > > +   continue;
> > > + }
> > >if (grub_errno != GRUB_ERR_NONE)
> > > grub_dprintf ("luks2", "Ignoring unhandled error %d from 
> > > luks2_get_keyslot\n", grub_errno);
> > >
> > > --
> > > 2.34.1
> > >
> >
> > Reviewed-by: Patrick Steinhardt 
> 
> Thank you for review but I have merged this patch earlier and cannot add
> your RB now... :-(
> 
> Daniel

No worries! I assumed as much when I reviewed this but was too lazy to
check ;)

Patrick


signature.asc
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel