All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: Zhang Boyang <zhangboyang.id@gmail.com>, grub-devel@gnu.org
Cc: Zhang Boyang <zhangboyang.id@gmail.com>
Subject: Re: [RFC PATCH] kern/dl: Add module version check
Date: Tue, 20 Dec 2022 17:58:50 -0500	[thread overview]
Message-ID: <jlgo7rxk7h1.fsf@redhat.com> (raw)
In-Reply-To: <20221219153329.154238-1-zhangboyang.id@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

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.

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).

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  parent reply	other threads:[~2022-12-20 22:59 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 [this message]
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

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=jlgo7rxk7h1.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=grub-devel@gnu.org \
    --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.