Hello all,
On 2022.12.20 22:58, Robbie Harwood wrote:
Zhang Boyang <zhangboyang...@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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel