[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: Robbie Harwood
Subject: Re: [RFC PATCH] kern/dl: Add module version check
Date: Wed, 21 Dec 2022 13:01:25 -0500

Zhang Boyang <> writes:

> On 2022/12/21 06: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.
> This feature is a prerequisite for external signed module support (and 
> it is mainly designed for this purpose). SBAT itself is not sufficient 
> to protect version mismatch attacks.

To be clear, I was not intending it as such.  That said, I dislike some
of your terminology: version mismatch is not generally an attack, merely
a self-own.  If you can write to and subsequently execute bootloader
files, you already have root to the box - there's no attack.  Secureboot
works by limiting what can be executed, and you simply can't have that
on Legacy BIOS.  So I think the order you're designing here is backward.

>> 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.
> Sorry but I'm not familiar with the kernel's ephemeral key approach. 
> Could you please give me some links to this?

Be well,

Attachment: signature.asc
Description: PGP signature

reply via email to

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