Re: [RFC PATCH] kern/dl: Add module version check

[Pete Batard]

Hello all,

On 2022.12.20 22:58, Robbie Harwood wrote:
> Zhang Boyang <zhangboyang.id@gmail.com> 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 module loading time. That module will
> > be rejected if mismatch is found. This will prevent loading modules from
> > different versions of 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).
>
> Right now, this only affects non-secureboot scenarios (because we don't
> have external signed module support).  I would want to see a resolution
> to the external module signing question first so that we don't paint
> ourselves into a corner with something like this.
>
> I share Glenn's confusion about what real-world problems this addresses:
> my understanding is that grub modules mostly register callbacks, so the
> possibility of disaster is low (unless the callback interfaces change of
> course, but that generally has not happened).

I'll add a note that integrating this proposal will make life A LOT more 
difficult for Rufus [1] users (and potentially users of other boot media 
creation software) when booting in BIOS/CSM mode.

The reason is that, unlike what is the case for UEFI, one can not expect 
to be able to pick all the GRUB core files needed to convert a GRUB 
based ISO bootable media to a GRUB based USB bootable media when using 
the kind File System Transposition one needs to apply, in order to avoid 
end-users, especially Windows ones, being left confused as to why their 
USB media is not showing the content they expect. Typically, one of the 
missing files 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.

As a result, whereas it can also write a GRUB base ISOHybrid image in DD 
mode, Rufus usually recommends to write such images in what it calls 
"ISO mode" (shorthand for "ISO extraction mode") with the ISO content 
extracted to a FAT or NTFS file system and with a GRUB core.img 
bootloader being installed by the application itself rather than being 
provided by the source image. This core.img, which is usually recompiled 
from GRUB dot releases to include support for MBR partition scheme, FAT, 
NTFS and potentially other required elements, then calls into the GRUB 
modules that were extracted from the ISO image.

And whereas, on paper, this may look a recipe for disaster, ~8 years of 
boot media creation for GRUB 2.x, using this default method of mixing a 
GRUB core.img that wasn't built alongside the modules it is using, shows 
the method to actually work quite well, *even* when most distros take it 
upon themselves to cherry-pick an extra selection of GRUB patches to 
their source while waiting for the next dot release.

However, if this proposal gets applied for BIOS modules, this will break 
the mechanism described above thereby penalising users who have come to 
rely on Rufus on account that most distros, and especially the ones that 
add patches to their GRUB sources, tend to use a distro specific version 
for GRUB (e.g. "2.06~unbuntu_xyz").

Thus, right at the time where we are finally seeing light at the end of 
the tunnel for UEFI, with regards to the root of the problem we are 
trying to address (about Windows users thinking their boot media is not 
created properly when using DD mode, and therefore not even trying to 
boot to Linux -- this is a VERY REAL issue for which I have provided a 
large number of examples already), by ensuring that GRUB will properly 
support File System Transposition for UEFI moving forward (with my 
thanks to Daniel for having reviewed the respective patch series just 
today!) this proposal is now planning to undo the whole File System 
Transposition support *equivalent* we spent a lot of time trying to find 
a workaround for, for BIOS...

I therefore have to second asking what kind of real-world problems this 
is meant to address, especially as I can vouch that, if GRUB goes 
through with this proposal for BIOS, this will most certainly result in 
real-world problems for users trying to create GRUB based BIOS bootable 
media on Windows.

One thing I will point out however is that I have no issue with the 
module version check proposal if it is to be restricted to UEFI boot 
only (or with any other means to validate the UEFI trust/compatibility 
chain), as the underlying problem of not being able to find all the GRUB 
data we need for File System Transposition only applies to BIOS boot.

Regards,

/Pete

[1] https://github.com/pbatard/rufus

> The combination of those two things leads me to suspect this is not the
> right approach.  It seems likely that if we want to down the road of
> versionlocking, something like the kernel's ephemeral key approach would
> be better suited - and if we want external modules (which I don't think
> we do), full SBAT support.
>
> Be well,
> --Robbie
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel