[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Zhang Boyang
Subject: Re: [RFC PATCH] kern/dl: Add module version check
Date: Wed, 21 Dec 2022 16:21:25 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0


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 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.

The situation is, for BIOS boot, there is no grub core file in ISO because it's written to sectors instead of files? Did I understand correctly?

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.

Please see my reply to Glenn for a real example of mismatched modules crashes GRUB ( ). I strongly recommend test whether that commit (052e6068be62) breaks Rufus (e.g. Rufus with latest git GRUB, to boot Debian ISO).

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").

This patch lives in core, so even it's enforced (I will not enforce this check in next patch reversion, see below), Rufus can still ship its own unpatched version of grub core and thing will still work.

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...

Will overwriting .mod files in USB drive with Rufus's build helps?

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.

The main propose is to implement external modules for UEFI secure boot and it's not related to BIOS boot though. Please see my replies to Glenn & Robbie for details.

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.

I will make next reversion emit a warning but still load such module if grub is not in lockdown mode (e.g. UEFI secure boot enabled). Would you mind a ugly warning will be displayed if mismatched module is loaded?

Best Regards,
Zhang Boyang




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,

Grub-devel mailing list

Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]