grub-devel
[Top][All Lists]
Advanced

[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 <zhangboyang.id@gmail.com> writes:

> On 2022/12/21 06: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.
>
> 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?

https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/module-signing.rst

Be well,
--Robbie

Attachment: signature.asc
Description: PGP signature


reply via email to

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