From: "Daniel P. Berrangé" <berrange@redhat.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Emanuele Giuseppe Esposito <eesposit@redhat.com>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
bluca@debian.org, lennart@poettering.net,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Alexander Potapenko <glider@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
Date: Mon, 17 Jul 2023 17:56:28 +0100 [thread overview]
Message-ID: <ZLVyvAXwtemx1I6p@redhat.com> (raw)
In-Reply-To: <ba2354dc63fd741d2d351b18d4312d0771c0935d.camel@HansenPartnership.com>
On Mon, Jul 17, 2023 at 12:08:26PM -0400, James Bottomley wrote:
> On Thu, 2023-07-13 at 15:52 +0200, Ard Biesheuvel wrote:
> > (add linux-efi@ cc)
>
> Thanks for that, since this is really EFI related rather than x86.
snip
> The problem, as I see it, is if the distros give the kernel an .sbat
> section, that means any vanilla kernel that's built by a user and
> signed by their key now won't work (even if their key is in MoK)
> because it won't have an sbat section ... and the sbat mechanism is
> component specific, not key specific, so the signer has no choice but
> to adopt it.
AFAICT, that problem only exists for binaries directly invoked
from shim. So that would be a problem for the boot loader (grub),
or a kernel image being booted directly without a bootloader
present.
For kernel binaries invoked indirectly by the boot loader, the
use of SBAT is currently optional. ie missing SBAT record would
be treated as success.
This was a pragmatic way to introduce SBAT support as it only
impacted grub at that time.
Once a distro starts adding SBAT to their kenrels too though, we
can forsee that they would like to enforce SBAT for the whole
boot chain, to prevent rollback to previously signed binaries
that lacked SBAT info.
This policy could be enforced per key though. eg require SBAT
for anything verified against the vendor key that's compiled into
shim, but not require SBAT for binaries verified with the MoK
entries.
The user specific MoK entries don't have such a compelling use
case for SBAT, since if they need to revoke old binaries, the
end users always have the easy fallback option of just rotating
their signing keys and switching out the enrolled key in MoK.
The choice of whether to mandate SBAT for binaries signed with
a MoK entry, could be set by the end user themselves at the time
their enroll their signing cert in the MoK DB.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-07-17 16:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230711154449.1378385-1-eesposit@redhat.com>
[not found] ` <ZK/9MlTh435FP5Ji@gambale.home>
2023-07-13 13:52 ` [RFC PATCH v2] x86/boot: add .sbat section to the bzImage Ard Biesheuvel
2023-07-13 20:39 ` Emanuele Giuseppe Esposito
2023-07-13 22:31 ` Luca Boccassi
2023-07-14 8:52 ` Ard Biesheuvel
2023-07-14 9:13 ` Matthew Garrett
2023-07-14 9:14 ` Ard Biesheuvel
2023-07-14 9:25 ` Luca Boccassi
2023-07-17 16:08 ` James Bottomley
2023-07-17 16:56 ` Daniel P. Berrangé [this message]
2023-07-17 17:15 ` James Bottomley
2023-07-17 18:16 ` Daniel P. Berrangé
2023-07-20 16:46 ` Eric Snowberg
2023-07-20 17:07 ` James Bottomley
2023-07-20 18:10 ` Eric Snowberg
2023-07-20 19:16 ` Luca Boccassi
2023-07-21 0:02 ` Eric Snowberg
2023-07-21 8:55 ` Luca Boccassi
2023-07-21 11:24 ` James Bottomley
2023-07-21 12:40 ` Luca Boccassi
2023-07-21 13:01 ` James Bottomley
2023-07-21 13:10 ` Luca Boccassi
2023-07-21 13:33 ` James Bottomley
2023-07-21 15:14 ` Luca Boccassi
2023-07-21 15:22 ` Luca Boccassi
2023-07-21 15:27 ` James Bottomley
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=ZLVyvAXwtemx1I6p@redhat.com \
--to=berrange@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bluca@debian.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eesposit@redhat.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=lennart@poettering.net \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=ndesaulniers@google.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox