From: Robbie Harwood <rharwood@redhat.com>
To: Zhang Boyang <zhangboyang.id@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
Glenn Washburn <development@efficientek.com>,
Daniel Kiper <dkiper@net-space.pl>, Pete Batard <pete@akeo.ie>
Subject: Re: [RFC PATCH] kern/dl: Add module version check
Date: Wed, 21 Dec 2022 13:01:25 -0500 [thread overview]
Message-ID: <jlgy1r0bpqi.fsf@redhat.com> (raw)
In-Reply-To: <3326fa35-0c2a-2a71-c191-a1195b52f550@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
prev parent reply other threads:[~2022-12-21 18:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 15:33 [RFC PATCH] kern/dl: Add module version check Zhang Boyang
2022-12-20 19:04 ` Glenn Washburn
2022-12-21 8:07 ` Zhang Boyang
2022-12-21 17:27 ` Glenn Washburn
2022-12-20 22:58 ` Robbie Harwood
2022-12-21 2:43 ` Pete Batard
2022-12-21 8:21 ` Zhang Boyang
2022-12-21 9:43 ` Thomas Schmitt
2022-12-21 11:34 ` Didier Spaier
2022-12-21 11:38 ` Zhang Boyang
2022-12-21 14:39 ` Pete Batard
2022-12-21 7:57 ` Zhang Boyang
2022-12-21 18:01 ` Robbie Harwood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jlgy1r0bpqi.fsf@redhat.com \
--to=rharwood@redhat.com \
--cc=development@efficientek.com \
--cc=dkiper@net-space.pl \
--cc=grub-devel@gnu.org \
--cc=pete@akeo.ie \
--cc=zhangboyang.id@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.