[Top][All Lists]

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

Re: [RFC PATCH v4 0/1] kern/dl: Add module vermagic check

From: Pete Batard
Subject: Re: [RFC PATCH v4 0/1] kern/dl: Add module vermagic check
Date: Thu, 29 Dec 2022 18:21:03 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1


I finally got a chance to test this proposal (mostly in the context of Rufus and for BIOS boot), and everything looks good to me.

Thanks a lot for adding an option to disable the warning when invoking configure!

I also second the idea that we want a unique identifier added to the version string, on account that (from my experience) a few distros do apply patches to GRUB, including potentially breaking ones, without altering the version, and we want to make sure that these can be detected.



On 2022.12.25 07:57, Zhang Boyang wrote:

This is the V4 of my patch.

V3 is at:

V2 is at:

V1 is at:

[ TL;DR ]

1) V4 use a string like "2.11 x86_64-efi Zgmcauq40DxP78CHS2fvUf" as "vermagic", 
unlike V3 which only has PACKAGE_VERSION in version string.

2) Modules with mismatched vermagic will be always rejected if GRUB is locked 

3) If GRUB is not locked down, unlike V3, the check is never enforced.

4) If GRUB is not locked down, and GRUB is built with "--without-vermagic", the 
warning about mismatchd modules is disabled. This option has no effect if GRUB is locked 

5) For reproducible builds, the vermagic string can be overridden by 

[ Why use vermagic instead of PACKAGE_VERSION ]

PACKAGE_VERSION is not sufficient to make each individual build unique. For 
example, i386-efi and i386-pc shares same PACKAGE_VERSION but they should be 
considered different.

The vermagic approach adopted the idea of ephemeral key which can also be found in Linux 
kernel (suggested by Robbie), but it is much simpler. The vermagic string is uniquely 
generated by configure script in each run, formatted like "{version} 
{target}-{platform} {random}" (may be changed in future). The random part of 
vermagic is a string taken from a space lager than 2**128, so it can be considerd unique.

For reproducible builds, the vermagic string can be overridden by 
"--with-vermagic=foobar". It's recommended to include vendor, product, version 
of product, version of GRUB package in product repository, target of GRUB (e.g. i386, 
x86_64), platform of GRUB (e.g. pc, efi, emu) in that string.

[ Why this patch is useful, even for BIOS boot ]

Because it helps people diagnose broken (or improper) GRUB installations.

For example, if you google "452: out of range pointer", you will got a lot of results in 2022. I 
think the most of them are related to mismatched modules. However, these problem are often not properly 
diagnosed because they disappear magically, e.g. update whole system (which triggers grub reinstall). There 
are several people even suspect there are problems with their hard disk / BIOS. However, the root cause is 
052e6068be62 ("mm: When adding a region, merge with region after as well as before") changed the 
layout of `struct grub_mm_region`, which is both used in main program and "relocator.mod", so the 
module reads the wrong field and crashes GRUB. Please note the commit did nothing wrong because there is no 
API/ABI compatibility guarantees in GRUB.

If there are warning messages about mismatched modules, user will easily notice 
there are problems with their GRUB installation.

[ Why not enforce this check to prevent crashes ]

As Glenn & Pete said, most mismatched modules isn't harmful. At most times, 
GRUB with mismatched modules can boot Linux happily, even if these modules come 
from another Linux distribution. This also enables user to fix his/her GRUB 
installation without using a boot/rescue disk, because the user can boot the 
existing Linux using the existing (but improperly installed) GRUB.

[ Why warning can be disabled ]

Some tools like Rufus relies on mismatched modules. Some advanced users also 
doesn't like redundant warnings for their existing known-to-work configurations.

However, it's highly unrecommended to disable this warning.

[ Why this patch is a prerequisite for external signed module support ]

Consider this scenario:

1) GRUB 2.XX is free of vulnerabilities

2) GRUB 2.YY is also free of vulnerabilities

3) So GRUB 2.XX shares same SBAT numbers with GRUB 2.YY, therefore SBAT can'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 
GRUB 2.XX (and vice versa)

6) So we must enforce vermagic check to prevent this from happening

Best Regards,
Zhang Boyang

Zhang Boyang (1):
   kern/dl: Add module vermagic check                   |  3 +++                  | 24 +++++++++++++++++++++
  grub-core/        | 28 +++++++++++++++----------
  grub-core/kern/dl.c           | 39 +++++++++++++++++++++++++++++++++++
  util/grub-module-verifierXX.c | 10 +++++++++
  5 files changed, 93 insertions(+), 11 deletions(-)

reply via email to

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