From: Eric Snowberg <eric.snowberg@oracle.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>,
Ard Biesheuvel <ardb@kernel.org>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Emanuele Giuseppe Esposito" <eesposit@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"bluca@debian.org" <bluca@debian.org>,
"lennart@poettering.net" <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>,
"open list" <linux-kernel@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"Jarkko Sakkinen" <jarkko@kernel.org>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
Date: Thu, 20 Jul 2023 16:46:25 +0000 [thread overview]
Message-ID: <FBDC67DD-856F-429B-8E91-B0CA8B0F24B9@oracle.com> (raw)
In-Reply-To: <0aa647f719103e8620d7209cbde40f04a7334749.camel@HansenPartnership.com>
(add keyrings@ cc)
> On Jul 17, 2023, at 11:15 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2023-07-17 at 17:56 +0100, Daniel P. Berrangé wrote:
>> 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.
>
> Well, currently, yes; that's the in_protocol check in
> shim.c:verify_sbat_section(). However, I was assuming based on this
> thread, that that was being tightened up (either because people are
> moving away from grub or because the shim verifier protocol would
> enforce it) as you imply below.
>
>> 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.
>
> That might work, but it's not currently in the shim code base. It also
> wouldn't work for SUSE I suspect: they actually put all of their distro
> keys into MokList (so the machine owner has to approve any SUSE key
> update), so how can shim tell the difference between my key and their
> key?
>
>> 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.
>
> Well, I agree with this, since it was my original point. However, a
> key observation still seems to be that none of this exception proposal
> is actually coded anywhere, so if shim does tighten up sbat
> verification, everyone currently gets caught by it (and if it doesn't
> then the kernel doesn't need an sbat section).
>
> I really think if this exception proposal is what everyone is planning,
> then you can simply leave the upstream kernel alone, since it won't
> require sbat information unless incorporated into a distro.
>
> So the direction forward seems to be to get this exception proposal
> coded up and agreed and then we can decide based on that whether the
> upstream kernel needs to care.
I agree with James in the previous thread; adding the SBAT section to
the kernel should be handled by the signing tools. It really doesn't need to
be included in the mainline kernel code. I also agree with the sentiment that
mainline and the stable branches should not have SBAT versions attached
to them. These are things distros should be responsible for including in their
kernel if they want to have SBAT support.
If a distro adds a SBAT section to either their UKI, or if kernel SBAT enforcement
is turned on from GRUB2 by default, there is one piece missing that would need
to be handled by the mainline kernel which is SBAT enforcement for kexec. This
would mean the revocations SBAT protect against would need to be referenced
before doing the signature validation in kexec. If this is not added, any distro that
allows kexec really doesn’t have a SBAT protected kernel.
Proposal for SBAT kexec protection:
Linux contains a machine and a platform keyring. The platform keyring contains
keys that are in the UEFI Secure Boot DB. The machine keyring contains all the
Machine Owner Keys (MOK). Today, MOK keys are a collection of keys
embedded into shim as well as user enrolled keys. There is also a MOKX which
contains revocations that currently get loaded into the blacklist keyring.
The current SBAT doc implies that things signed by a MOK cert can be revoked
by SBAT. Previously, revocations came from MOKX. Instead of changing the
current MOK usage in the kernel, how about shim adding a new keyring? Any
cert that is embedded or enrolled into shim requiring SBAT enforcement would
be contained within this new keyring. The original MOK keyring would start out
empty in shim (or it could also contain distro certs used to sign older non-SBAT
kernels for backwards compatibility). If the enduser wants to enroll their own key
to boot a custom signed kernel, nothing changes. When the machine boots, shim
references both keyrings. MOK keys do not require SBAT enforcement, the shim
SBAT keyring does. When Linux boots, MOK keys go into the machine keyring.
Linux then adds support for a new keyring that loads the keys requiring SBAT
enforcement (calling it the sbat keyring for now). During kexec the machine,
platform, builtin_trusted, secondary and new sbat keyring all get referenced. The
machine, builtin, and secondary keyrings do not require SBAT enforcement for
kexec. Both the platform and sbat keyring require SBAT enforcement.
This would allow distros to sign kernels using updated signing tools that append the
proper SBAT information. It allows distros to support non-SBAT kernels it previously
signed for backwards compatibility. It leaves the mainline kernel out of needing to
have a SBAT level or ever maintaining one. It allows end-users to enroll their own
keys and sign their own kernels just like they can today. It also allows mainline Linux
to understand SBAT only to the point necessary to enforce the SBAT level for a kexec.
next parent reply other threads:[~2023-07-20 16:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230711154449.1378385-1-eesposit@redhat.com>
[not found] ` <ZK/9MlTh435FP5Ji@gambale.home>
[not found] ` <ZLABozIRVGmwuIBf@gambale.home>
[not found] ` <ba2354dc63fd741d2d351b18d4312d0771c0935d.camel@HansenPartnership.com>
[not found] ` <ZLVyvAXwtemx1I6p@redhat.com>
[not found] ` <0aa647f719103e8620d7209cbde40f04a7334749.camel@HansenPartnership.com>
2023-07-20 16:46 ` Eric Snowberg [this message]
2023-07-20 17:07 ` [RFC PATCH v2] x86/boot: add .sbat section to the bzImage 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=FBDC67DD-856F-429B-8E91-B0CA8B0F24B9@oracle.com \
--to=eric.snowberg@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=berrange@redhat.com \
--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=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).