Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Ard Biesheuvel]

(add linux-efi@ cc)

On Thu, Jul 13, 2023 at 03:33:38PM +0200, Ard Biesheuvel wrote:
> Hello Emanuele,
> 
> Please cc the linux-efi@ mailing list and myself on EFI related patches.
> 
> First of all, I think the tone of the discussion is way out of hand on
> both sides of the debate. Please keep it civil and courteous.
> 
> On Tue, Jul 11, 2023 at 11:44:49AM -0400, Emanuele Giuseppe Esposito wrote:
> > *Important*: this is just an RFC, as I am not expert in this area and
> > I don't know what's the best way to achieve this.
> > 
> > v2:
> > * add standard "sbat,1,SBAT Version,..." header string
> > 
> > The aim of this patch is to add a .sbat section to the linux binary
> > (https://github.com/rhboot/shim/blob/main/SBAT.md).
> > We mainly need SBAT in UKIs (Unified Kernel Images), as we might want
> > to revoke authorizations to specific signed PEs that were initially
> > considered as trusted. The reason might be for example a security issue
> > related to a specific linux release.
> > 
> > A .sbat is simply a section containing a string with the component name
> > and a version number. This version number is compared with the value in
> > OVMF_VARS, and if it's less than the variable, the binary is not trusted,
> > even if it is correctly signed.
> > 
> 
> Most people will not known what OVMF_VARS is or a PE.
> 
> Also, 'version number' is a bit vague, better to stick with existing
> terminology that makes this more self explanatory: the component that
> authenticates the kernel image keeps a revocation counter, and refuses
> to load authentic images whose revocation index is lower than the
> revocation counter. This approach removes the need for revoking
> individual image hashes or having to rotate the signing keys when a
> vulnerability is discovered.
> 
> The argument that we need this in the upstream kernel seems to be
> predicated on the assumption that there is one universal signing
> authority and revocation domain, but this is not necessarily true. Even
> if the distros appear to have decided that it is a reasonable choice to
> deploy the MicroSoft signed shim and the associated components on other
> systems than Windows-crippled x86 PCs, this is not universally true, and
> UEFI secure boot can be (and is) deployed in sane ways as well.
> 

Note that by Windows-crippled, I mean x86 PCs built by OEMs who care
about nothing other than the Windows logo sticker. These PCs often don't
allow secure boot keys to be modified by the owner of the machine, or
secure boot to be disabled at all. This is why shim exists, not because
UEFI secure boot is broken by design.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Emanuele Giuseppe Esposito]

Hi Ard,

Ok in case I'll cc you. Thanks a lot!

Emanuele

Am 13/07/2023 um 15:52 schrieb Ard Biesheuvel:
> (add linux-efi@ cc)
> 
> On Thu, Jul 13, 2023 at 03:33:38PM +0200, Ard Biesheuvel wrote:
>> Hello Emanuele,
>>
>> Please cc the linux-efi@ mailing list and myself on EFI related patches.
>>
>> First of all, I think the tone of the discussion is way out of hand on
>> both sides of the debate. Please keep it civil and courteous

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Thu, 13 Jul 2023 at 14:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (add linux-efi@ cc)
>
> On Thu, Jul 13, 2023 at 03:33:38PM +0200, Ard Biesheuvel wrote:
> > Hello Emanuele,
> >
> > Please cc the linux-efi@ mailing list and myself on EFI related patches.
> >
> > First of all, I think the tone of the discussion is way out of hand on
> > both sides of the debate. Please keep it civil and courteous.
> >
> > On Tue, Jul 11, 2023 at 11:44:49AM -0400, Emanuele Giuseppe Esposito wrote:
> > > *Important*: this is just an RFC, as I am not expert in this area and
> > > I don't know what's the best way to achieve this.
> > >
> > > v2:
> > > * add standard "sbat,1,SBAT Version,..." header string
> > >
> > > The aim of this patch is to add a .sbat section to the linux binary
> > > (https://github.com/rhboot/shim/blob/main/SBAT.md).
> > > We mainly need SBAT in UKIs (Unified Kernel Images), as we might want
> > > to revoke authorizations to specific signed PEs that were initially
> > > considered as trusted. The reason might be for example a security issue
> > > related to a specific linux release.
> > >
> > > A .sbat is simply a section containing a string with the component name
> > > and a version number. This version number is compared with the value in
> > > OVMF_VARS, and if it's less than the variable, the binary is not trusted,
> > > even if it is correctly signed.
> > >
> >
> > Most people will not known what OVMF_VARS is or a PE.
> >
> > Also, 'version number' is a bit vague, better to stick with existing
> > terminology that makes this more self explanatory: the component that
> > authenticates the kernel image keeps a revocation counter, and refuses
> > to load authentic images whose revocation index is lower than the
> > revocation counter. This approach removes the need for revoking
> > individual image hashes or having to rotate the signing keys when a
> > vulnerability is discovered.
> >
> > The argument that we need this in the upstream kernel seems to be
> > predicated on the assumption that there is one universal signing
> > authority and revocation domain, but this is not necessarily true. Even
> > if the distros appear to have decided that it is a reasonable choice to
> > deploy the MicroSoft signed shim and the associated components on other
> > systems than Windows-crippled x86 PCs, this is not universally true, and
> > UEFI secure boot can be (and is) deployed in sane ways as well.
> >
>
> Note that by Windows-crippled, I mean x86 PCs built by OEMs who care
> about nothing other than the Windows logo sticker. These PCs often don't
> allow secure boot keys to be modified by the owner of the machine, or
> secure boot to be disabled at all. This is why shim exists, not because
> UEFI secure boot is broken by design.

AFAIK that's not only against the spec but also the logo
certification, which x86 OEMs are doing that and in which models?
Happy to flag that and inquire.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Ard Biesheuvel]

(cc Peter and Matthew)

On Fri, 14 Jul 2023 at 00:32, Luca Boccassi <bluca@debian.org> wrote:
>
> On Thu, 13 Jul 2023 at 14:52, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> >
> > Note that by Windows-crippled, I mean x86 PCs built by OEMs who care
> > about nothing other than the Windows logo sticker. These PCs often don't
> > allow secure boot keys to be modified by the owner of the machine, or
> > secure boot to be disabled at all. This is why shim exists, not because
> > UEFI secure boot is broken by design.
>
> AFAIK that's not only against the spec but also the logo
> certification, which x86 OEMs are doing that and in which models?
> Happy to flag that and inquire.

Thanks. My Yoga C630 Snapdragon laptop definitely does not allow me to
update the keys from the UI, but it does allow me to disable secure
boot. It might work with SetVariable() directly but I've never tried.

Maybe the OEMs have gotten better at this over the years, but it is
definitely not possible for the distros to rely on being able to get
their own cert into KEK and sign their builds directly.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Matthew Garrett]

On Fri, Jul 14, 2023 at 10:52:20AM +0200, Ard Biesheuvel wrote:

> Maybe the OEMs have gotten better at this over the years, but it is
> definitely not possible for the distros to rely on being able to get
> their own cert into KEK and sign their builds directly.

Getting certs into local machine databases should[1] be possible on all 
Windows certified machines, but in the status-quo there's no 
cross-vendor solution to doing this. Relying on the Shim-provided 
mechanisms is much safer from a consistency perspective.

[1] Every time someone has claimed it's impossible to me I've ended up 
demonstrating otherwise, but that's not a guarantee

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Ard Biesheuvel]

On Fri, 14 Jul 2023 at 11:13, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> On Fri, Jul 14, 2023 at 10:52:20AM +0200, Ard Biesheuvel wrote:
>
> > Maybe the OEMs have gotten better at this over the years, but it is
> > definitely not possible for the distros to rely on being able to get
> > their own cert into KEK and sign their builds directly.
>
> Getting certs into local machine databases should[1] be possible on all
> Windows certified machines, but in the status-quo there's no
> cross-vendor solution to doing this. Relying on the Shim-provided
> mechanisms is much safer from a consistency perspective.
>
> [1] Every time someone has claimed it's impossible to me I've ended up
> demonstrating otherwise, but that's not a guarantee

Interesting. So by 'demonstrating', do you mean running some EFI app
that calls SetVariable() on PK/KEK/db directly, rather than going via
the UI?

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Fri, 14 Jul 2023 at 09:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (cc Peter and Matthew)
>
> On Fri, 14 Jul 2023 at 00:32, Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Thu, 13 Jul 2023 at 14:52, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > >
> > > Note that by Windows-crippled, I mean x86 PCs built by OEMs who care
> > > about nothing other than the Windows logo sticker. These PCs often don't
> > > allow secure boot keys to be modified by the owner of the machine, or
> > > secure boot to be disabled at all. This is why shim exists, not because
> > > UEFI secure boot is broken by design.
> >
> > AFAIK that's not only against the spec but also the logo
> > certification, which x86 OEMs are doing that and in which models?
> > Happy to flag that and inquire.
>
> Thanks. My Yoga C630 Snapdragon laptop definitely does not allow me to
> update the keys from the UI, but it does allow me to disable secure
> boot. It might work with SetVariable() directly but I've never tried.

That's not an x86 machine though? For Arm IIRC the logo certification
requirement was more lax there (or more locked down, depending on your
point of view), at least in the past. I am not sure what is the
current state.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

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.

> On Thu, Jul 13, 2023 at 03:33:38PM +0200, Ard Biesheuvel wrote:
> > Hello Emanuele,
> > 
> > Please cc the linux-efi@ mailing list and myself on EFI related
> > patches.
> > 
> > First of all, I think the tone of the discussion is way out of hand
> > on both sides of the debate. Please keep it civil and courteous.
> > 
> > On Tue, Jul 11, 2023 at 11:44:49AM -0400, Emanuele Giuseppe
> > Esposito wrote:
> > > *Important*: this is just an RFC, as I am not expert in this area
> > > and I don't know what's the best way to achieve this.
> > > 
> > > v2:
> > > * add standard "sbat,1,SBAT Version,..." header string
> > > 
> > > The aim of this patch is to add a .sbat section to the linux
> > > binary
> > > (https://github.com/rhboot/shim/blob/main/SBAT.md).
> > > We mainly need SBAT in UKIs (Unified Kernel Images), as we might
> > > want to revoke authorizations to specific signed PEs that were
> > > initially considered as trusted. The reason might be for example
> > > a security issue related to a specific linux release.
> > > 
> > > A .sbat is simply a section containing a string with the
> > > component name and a version number. This version number is
> > > compared with the value in OVMF_VARS, and if it's less than the
> > > variable, the binary is not trusted, even if it is correctly
> > > signed.
> > > 
> > 
> > Most people will not known what OVMF_VARS is or a PE.
> > 
> > Also, 'version number' is a bit vague, better to stick with
> > existing terminology that makes this more self explanatory: the
> > component that authenticates the kernel image keeps a revocation
> > counter, and refuses to load authentic images whose revocation
> > index is lower than the revocation counter. This approach removes
> > the need for revoking individual image hashes or having to rotate
> > the signing keys when a vulnerability is discovered.
> > 
> > The argument that we need this in the upstream kernel seems to be
> > predicated on the assumption that there is one universal signing
> > authority and revocation domain, but this is not necessarily true.
> > Even if the distros appear to have decided that it is a reasonable
> > choice to deploy the MicroSoft signed shim and the associated
> > components on other systems than Windows-crippled x86 PCs, this is
> > not universally true, and UEFI secure boot can be (and is) deployed
> > in sane ways as well.

Well, yes, but just because sanity exists, doesn't mean we can ignore
the current insanity in the Laptop/desktop x86 space.

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.

There are two ways out of this: give the kernel an sbat section that's
always current, which is what the proposed patch does (but rather falls
down on the who keeps it current and how part) or actually add sbat
addition to the signing tools, so people who sign their own kernels can
simply go on doing that and no-one else need worry.

I rather incline to the latter, but as a maintainer of a secure boot
signing tool I would say that.  I could easily add tools that tell
someone what the current SBAT level is on the machine they're using, or
in any given boot component, which will make it very easy to add the
correct one.  If it becomes the responsibility of the signer, they're
the ones who decide whether what they've signed revokes everything else
(which they'd never realistically do if they want to keep booting
distro kernels in addition to their own).

James

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Daniel P. Berrangé]

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 :|

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

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.

James

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Daniel P. Berrangé]

On Mon, Jul 17, 2023 at 01:15:19PM -0400, James Bottomley 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?

Interesting, I didn't know that about SUSE's usage pattern. That
would pretty much require that the SBAT enforcement is configured
per MokList entry, to retain sufficient flexibility for users.

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

I don't know what shim maintainers are planning, this was just an
idea I came up with when thinking through how to enforce SBAT without
making it a pain for users.

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

Agreed, I think it needs some feedback from the shim maintainers about
a vision for future SBAT enforcement. I'll raise this idea and see
what they say. If we eliminate the need for upstream linux to care
about SBTA that probably makes life easier for everyone.

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 :|

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Eric Snowberg]

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

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

On Thu, 2023-07-20 at 16:46 +0000, Eric Snowberg wrote:
> 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.

Um, actually, this is actually one of the misunderstandings of the
whole thread: sbat is a revocation mechanism for protecting EFI boot
security.  It's design is to prevent malicious actors exploiting buggy
code to get into the EFI boot system before ExitBootServices is called
and nothing more.  The kernel's intrusion into EFI boot security is
tiny: it's basically the EFI stub up to ExitBootServices, so even if
the kernel were to have an sbat number it would obviously be under the
control of the maintainers of only that code (i.e. Ard) and it would
only rev if we actually found a usable exploit in the efi stub.

As far as kexec is concerned, ExitBootServices is long gone and nothing
a future kexec'd kernel can do can alter that, so there's no EFI
security benefit to making kexec sbat aware, and thus it seems there's
no need to do anything about it for kexec.  Now if we're interested in
sbat as a more general revocation mechanism, that might change, but I
think sbat is too tightly designed for the problems of EFI variables to
be more generally useful.

James

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Eric Snowberg]

> On Jul 20, 2023, at 11:07 AM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> On Thu, 2023-07-20 at 16:46 +0000, Eric Snowberg wrote:
>> 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.
> 
> Um, actually, this is actually one of the misunderstandings of the
> whole thread: sbat is a revocation mechanism for protecting EFI boot
> security.  It's design is to prevent malicious actors exploiting buggy
> code to get into the EFI boot system before ExitBootServices is called
> and nothing more.  The kernel's intrusion into EFI boot security is
> tiny: it's basically the EFI stub up to ExitBootServices, so even if
> the kernel were to have an sbat number it would obviously be under the
> control of the maintainers of only that code (i.e. Ard) and it would
> only rev if we actually found a usable exploit in the efi stub.
> 
> As far as kexec is concerned, ExitBootServices is long gone and nothing
> a future kexec'd kernel can do can alter that, so there's no EFI
> security benefit to making kexec sbat aware, and thus it seems there's
> no need to do anything about it for kexec.  Now if we're interested in
> sbat as a more general revocation mechanism, that might change, but I
> think sbat is too tightly designed for the problems of EFI variables to
> be more generally useful.

If the line of protection SBAT provides ends at EBS then I agree, kexec 
support would not be needed.  While reading the SBAT spec, I got the 
impression the revocation mechanism it provides would go beyond the 
EBS line.  I guess that needs to be clarified.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Thu, 20 Jul 2023 at 18:11, Eric Snowberg <eric.snowberg@oracle.com> wrote:
>
> (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.

Why would 'signing tools' handle that? It's just a text-based PE
section, it doesn't require access to private key materials to be
handled, nor it has any relationship with signing. Why should all the
(numerous) signing tools be extended to do also add arbitrary PE
sections? And again, the point is that it's not something you might or
might not want to have - if you are getting your Shim signed by the
3rd party CA, you need it, full stop, end of story. Without it, you
don't boot. So it needs to be easy to find and consume for all the
distributions/groups/projects that participate in the Shim + 3rd party
CA workflow, that's the main goal. Mistakes are going to be expensive.

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

The kexec question is indeed interesting, but a bit further down the
road. As James said, initially protecting the stub is probably more
interesting and urgent, as the system before ExitBootServices is much
more "valuable" to protect. For the future, IIRC a few ideas were
floated, to avoid downgrades, but nothing concrete as far as I know.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Eric Snowberg]

> On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@debian.org> wrote:
> 
> On Thu, 20 Jul 2023 at 18:11, Eric Snowberg <eric.snowberg@oracle.com> wrote:
>> 
>> (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.
> 
> Why would 'signing tools' handle that? It's just a text-based PE
> section, it doesn't require access to private key materials to be
> handled, nor it has any relationship with signing. 

There is a relationship, the sbat information within the signed file 
can be used for revocation in lieu of revoking the hash or signing 
certificate at a later time.

> And again, the point is that it's not something you might or
> might not want to have - if you are getting your Shim signed by the
> 3rd party CA, you need it, full stop, end of story. Without it, you
> don't boot. So it needs to be easy to find and consume for all the
> distributions/groups/projects that participate in the Shim + 3rd party
> CA workflow, that's the main goal. Mistakes are going to be expensive.

I thought this discussion was around adding a sbat section to a signed
kernel. When signing a kernel, there must be some type of assurance 
done immediately prior to code signing.  Currently following the assurance 
step the appropriate public and private keys are supplied to either pesign 
or sbsign.  If the signing tools were modified  to optionally accept sbat 
information through a new command line arg, the new section could be 
added immediately before signing.  

Unlike shim, every kernel will be different and have different vulnerabilities 
that individuals or distros may want to protect against.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Fri, 21 Jul 2023 at 02:49, Eric Snowberg <eric.snowberg@oracle.com> wrote:
>
>
>
> > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >>
> >> (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.
> >
> > Why would 'signing tools' handle that? It's just a text-based PE
> > section, it doesn't require access to private key materials to be
> > handled, nor it has any relationship with signing.
>
> There is a relationship, the sbat information within the signed file
> can be used for revocation in lieu of revoking the hash or signing
> certificate at a later time.

No, it is completely disjoint. In fact, the kernel doesn't even have
to be signed at all, but it still _must_ have a .sbat section when it
is used in a UKI. The UKI build tool (which is not a signing tool)
will merge the .sbat sections from the various PEs that it assemble,
currently kernel and stub, to create the final 'outer' .sbat in the
UKI PE. It's not expected for the kernel PE binary that gets merged in
the UKI to be signed. It is expected that it has a valid .sbat
section.

> > And again, the point is that it's not something you might or
> > might not want to have - if you are getting your Shim signed by the
> > 3rd party CA, you need it, full stop, end of story. Without it, you
> > don't boot. So it needs to be easy to find and consume for all the
> > distributions/groups/projects that participate in the Shim + 3rd party
> > CA workflow, that's the main goal. Mistakes are going to be expensive.
>
> I thought this discussion was around adding a sbat section to a signed
> kernel. When signing a kernel, there must be some type of assurance
> done immediately prior to code signing.  Currently following the assurance
> step the appropriate public and private keys are supplied to either pesign
> or sbsign.  If the signing tools were modified  to optionally accept sbat
> information through a new command line arg, the new section could be
> added immediately before signing.

No, as mentioned above, the kernel doesn't even have to be signed. It
needs to carry .sbat data though, if it will be part of a signed UKI
that is loaded via the 3rd party CA flow.

> Unlike shim, every kernel will be different and have different vulnerabilities
> that individuals or distros may want to protect against.

That's not any different than grub.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

On Fri, 2023-07-21 at 09:55 +0100, Luca Boccassi wrote:
> On Fri, 21 Jul 2023 at 02:49, Eric Snowberg
> <eric.snowberg@oracle.com> wrote:
> > > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@debian.org>
> > > wrote:
> > > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg
> > > <eric.snowberg@oracle.com> wrote:
[...]
> > > > 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.
> > > 
> > > Why would 'signing tools' handle that? It's just a text-based PE
> > > section, it doesn't require access to private key materials to be
> > > handled, nor it has any relationship with signing.
> > 
> > There is a relationship, the sbat information within the signed
> > file can be used for revocation in lieu of revoking the hash or
> > signing certificate at a later time.
> 
> No, it is completely disjoint. In fact, the kernel doesn't even have
> to be signed at all, but it still _must_ have a .sbat section when it
> is used in a UKI.

Just a minute, this is wrong.  I was talking to Peter after all of this
blew up about how we handle signed kernels with no sbat (since we need
that still to work for developers who sign their own kernels).  I
thought he was planning to require an sbat section for all EFI
binaries, but he says that's not true.  The current way shim does the
sbat check is that if the section doesn't exist the binary is processed
as having an empty sbat section (i.e. no sbat level checking will be
done because there's no named sbat level for anything and it will just
work) and they're planning to keep it that way so that a signed but no
sbat kernel will always "just work" without any special key handling in
shim.  So if we're planning to keep this no-sbat case in discrete
kernels, even when the shim verifier checks sbat, the UKI kernel will
need to work for this case as well.

James

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Fri, 21 Jul 2023 at 12:24, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2023-07-21 at 09:55 +0100, Luca Boccassi wrote:
> > On Fri, 21 Jul 2023 at 02:49, Eric Snowberg
> > <eric.snowberg@oracle.com> wrote:
> > > > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@debian.org>
> > > > wrote:
> > > > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg
> > > > <eric.snowberg@oracle.com> wrote:
> [...]
> > > > > 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.
> > > >
> > > > Why would 'signing tools' handle that? It's just a text-based PE
> > > > section, it doesn't require access to private key materials to be
> > > > handled, nor it has any relationship with signing.
> > >
> > > There is a relationship, the sbat information within the signed
> > > file can be used for revocation in lieu of revoking the hash or
> > > signing certificate at a later time.
> >
> > No, it is completely disjoint. In fact, the kernel doesn't even have
> > to be signed at all, but it still _must_ have a .sbat section when it
> > is used in a UKI.
>
> Just a minute, this is wrong.  I was talking to Peter after all of this
> blew up about how we handle signed kernels with no sbat (since we need
> that still to work for developers who sign their own kernels).  I
> thought he was planning to require an sbat section for all EFI
> binaries, but he says that's not true.  The current way shim does the
> sbat check is that if the section doesn't exist the binary is processed
> as having an empty sbat section (i.e. no sbat level checking will be
> done because there's no named sbat level for anything and it will just
> work) and they're planning to keep it that way so that a signed but no
> sbat kernel will always "just work" without any special key handling in
> shim.  So if we're planning to keep this no-sbat case in discrete
> kernels, even when the shim verifier checks sbat, the UKI kernel will
> need to work for this case as well.

Are you sure that's not just about local signing? IE, MoK vs embedded
cert auth flow? As far as I know, the plan for the 3rd party CA flow
is to eventually (very eventually) require it. I might have missed
some development ofc.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

On Fri, 2023-07-21 at 13:40 +0100, Luca Boccassi wrote:
> On Fri, 21 Jul 2023 at 12:24, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Fri, 2023-07-21 at 09:55 +0100, Luca Boccassi wrote:
> > > On Fri, 21 Jul 2023 at 02:49, Eric Snowberg
> > > <eric.snowberg@oracle.com> wrote:
> > > > > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@debian.org>
> > > > > wrote:
> > > > > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg
> > > > > <eric.snowberg@oracle.com> wrote:
> > [...]
> > > > > > 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.
> > > > > 
> > > > > Why would 'signing tools' handle that? It's just a text-based
> > > > > PE section, it doesn't require access to private key
> > > > > materials to be handled, nor it has any relationship with
> > > > > signing.
> > > > 
> > > > There is a relationship, the sbat information within the signed
> > > > file can be used for revocation in lieu of revoking the hash or
> > > > signing certificate at a later time.
> > > 
> > > No, it is completely disjoint. In fact, the kernel doesn't even
> > > have to be signed at all, but it still _must_ have a .sbat
> > > section when it is used in a UKI.
> > 
> > Just a minute, this is wrong.  I was talking to Peter after all of
> > this blew up about how we handle signed kernels with no sbat (since
> > we need that still to work for developers who sign their own
> > kernels).  I thought he was planning to require an sbat section for
> > all EFI binaries, but he says that's not true.  The current way
> > shim does the sbat check is that if the section doesn't exist the
> > binary is processed as having an empty sbat section (i.e. no sbat
> > level checking will be done because there's no named sbat level for
> > anything and it will just work) and they're planning to keep it
> > that way so that a signed but no sbat kernel will always "just
> > work" without any special key handling in shim.  So if we're
> > planning to keep this no-sbat case in discrete kernels, even when
> > the shim verifier checks sbat, the UKI kernel will need to work for
> > this case as well.
> 
> Are you sure that's not just about local signing?

Well, my job is to be concerned about how individuals who want to own
their own keys, either in MoK or db, participate in this, so I am
mostly thinking about local signing.  Whatever we decide, there must be
a local workflow pathway.

>  IE, MoK vs embedded cert auth flow? As far as I know, the plan for
> the 3rd party CA flow is to eventually (very eventually) require it.
> I might have missed some development ofc.

There is a thought to get sbat adopted by UEFI to solve the dbx
problem, but if that were to happen, UEFI will likely be extremely
concerned about backward compatibility (and as you have remarked, they
and the OEMs adopt at a glacial pace), so, even if they eventually
adopt it, I can't foresee them mandating refusing to execute signed EFI
binaries with no sbat.  I'll pretty much stake cash on the compromise
being that for the foreseeable future no sbat gets revoked by dbx and
the plan will be a gradual shift towards sbat ... but all this is
contingent on UEFI adoption in the first place, which isn't a given. 
There are also unsolved problems around sbat, like how the master sbat
lists are kept and how they're delivered which must be solved before a
UEFI proposal could be made.

James

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Fri, 21 Jul 2023 at 14:01, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2023-07-21 at 13:40 +0100, Luca Boccassi wrote:
> > On Fri, 21 Jul 2023 at 12:24, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > On Fri, 2023-07-21 at 09:55 +0100, Luca Boccassi wrote:
> > > > On Fri, 21 Jul 2023 at 02:49, Eric Snowberg
> > > > <eric.snowberg@oracle.com> wrote:
> > > > > > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@debian.org>
> > > > > > wrote:
> > > > > > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg
> > > > > > <eric.snowberg@oracle.com> wrote:
> > > [...]
> > > > > > > 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.
> > > > > >
> > > > > > Why would 'signing tools' handle that? It's just a text-based
> > > > > > PE section, it doesn't require access to private key
> > > > > > materials to be handled, nor it has any relationship with
> > > > > > signing.
> > > > >
> > > > > There is a relationship, the sbat information within the signed
> > > > > file can be used for revocation in lieu of revoking the hash or
> > > > > signing certificate at a later time.
> > > >
> > > > No, it is completely disjoint. In fact, the kernel doesn't even
> > > > have to be signed at all, but it still _must_ have a .sbat
> > > > section when it is used in a UKI.
> > >
> > > Just a minute, this is wrong.  I was talking to Peter after all of
> > > this blew up about how we handle signed kernels with no sbat (since
> > > we need that still to work for developers who sign their own
> > > kernels).  I thought he was planning to require an sbat section for
> > > all EFI binaries, but he says that's not true.  The current way
> > > shim does the sbat check is that if the section doesn't exist the
> > > binary is processed as having an empty sbat section (i.e. no sbat
> > > level checking will be done because there's no named sbat level for
> > > anything and it will just work) and they're planning to keep it
> > > that way so that a signed but no sbat kernel will always "just
> > > work" without any special key handling in shim.  So if we're
> > > planning to keep this no-sbat case in discrete kernels, even when
> > > the shim verifier checks sbat, the UKI kernel will need to work for
> > > this case as well.
> >
> > Are you sure that's not just about local signing?
>
> Well, my job is to be concerned about how individuals who want to own
> their own keys, either in MoK or db, participate in this, so I am
> mostly thinking about local signing.  Whatever we decide, there must be
> a local workflow pathway.

Sure but for local signing via MoK that's obviously fine, as one gets
to keep the pieces. AFAIK it's a different flow in Shim whether
something is authorized by MoK, DB or the built-in cert, so having
different policies built-in for those different cases should be
doable. Actually at the moment even if Shim loads the image, if it
gets authorized by DB .sbat isn't checked at all.

> >  IE, MoK vs embedded cert auth flow? As far as I know, the plan for
> > the 3rd party CA flow is to eventually (very eventually) require it.
> > I might have missed some development ofc.
>
> There is a thought to get sbat adopted by UEFI to solve the dbx
> problem, but if that were to happen, UEFI will likely be extremely
> concerned about backward compatibility (and as you have remarked, they
> and the OEMs adopt at a glacial pace), so, even if they eventually
> adopt it, I can't foresee them mandating refusing to execute signed EFI
> binaries with no sbat.  I'll pretty much stake cash on the compromise
> being that for the foreseeable future no sbat gets revoked by dbx and
> the plan will be a gradual shift towards sbat ... but all this is
> contingent on UEFI adoption in the first place, which isn't a given.
> There are also unsolved problems around sbat, like how the master sbat
> lists are kept and how they're delivered which must be solved before a
> UEFI proposal could be made.

I meant Shim + 3rd party CA flow here. UEFI SB 2.0 is so far ahead I'm
pretty sure a good chunk of the folks currently talking about it will
be retired by the time it actually exist ;-)

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

On Fri, 2023-07-21 at 14:10 +0100, Luca Boccassi wrote:
> On Fri, 21 Jul 2023 at 14:01, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
[...]
> > Well, my job is to be concerned about how individuals who want to
> > own their own keys, either in MoK or db, participate in this, so I
> > am mostly thinking about local signing.  Whatever we decide, there
> > must be a local workflow pathway.
> 
> Sure but for local signing via MoK that's obviously fine, as one gets
> to keep the pieces. AFAIK it's a different flow in Shim whether
> something is authorized by MoK, DB or the built-in cert, so having
> different policies built-in for those different cases should be
> doable. Actually at the moment even if Shim loads the image, if it
> gets authorized by DB .sbat isn't checked at all.

So let's be sure we mean the same thing here.  There is really no third
party CA.  Microsoft gives the distributions a signing key to allow
them to sign their version of shim.  Some distributions, like Red Hat,
also embed their signing certificates in shim, so shim can distinguish
between a RH key and another key added to MokList.  However, some
distributions, like SUSE, insist that all signing keys be approved by
the machine owner (so no embedded shim certs for non-enterprise) and
their shim can't distinguish between SUSE keys and machine owner
additions.  Given the variances in key handling, I think trying to
distinguish between official and developer keys is a huge addition of
complexity we don't need, so there has to be a workflow that functions
for both and that workflow would seem to be allowing non-existent or
empty sbat sections.  Official key holders  would *always* add sbat
sections, so there's really no problem that needs a solution to be
mandated here.

James
 

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Fri, 21 Jul 2023 at 14:34, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2023-07-21 at 14:10 +0100, Luca Boccassi wrote:
> > On Fri, 21 Jul 2023 at 14:01, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> [...]
> > > Well, my job is to be concerned about how individuals who want to
> > > own their own keys, either in MoK or db, participate in this, so I
> > > am mostly thinking about local signing.  Whatever we decide, there
> > > must be a local workflow pathway.
> >
> > Sure but for local signing via MoK that's obviously fine, as one gets
> > to keep the pieces. AFAIK it's a different flow in Shim whether
> > something is authorized by MoK, DB or the built-in cert, so having
> > different policies built-in for those different cases should be
> > doable. Actually at the moment even if Shim loads the image, if it
> > gets authorized by DB .sbat isn't checked at all.
>
> So let's be sure we mean the same thing here.  There is really no third
> party CA.  Microsoft gives the distributions a signing key to allow
> them to sign their version of shim.  Some distributions, like Red Hat,
> also embed their signing certificates in shim, so shim can distinguish
> between a RH key and another key added to MokList.  However, some
> distributions, like SUSE, insist that all signing keys be approved by
> the machine owner (so no embedded shim certs for non-enterprise) and
> their shim can't distinguish between SUSE keys and machine owner
> additions.  Given the variances in key handling, I think trying to
> distinguish between official and developer keys is a huge addition of
> complexity we don't need, so there has to be a workflow that functions
> for both and that workflow would seem to be allowing non-existent or
> empty sbat sections.  Official key holders  would *always* add sbat
> sections, so there's really no problem that needs a solution to be
> mandated here.

The certificate is called the "Microsoft Corporation UEFI CA 2011" ,
issued by the "Microsoft Corporation Third Party Marketplace Root". So
for short, we call it UEFI 3rd party CA :-)
Anyway, I wasn't aware that SUSE doesn't embed their cert in Shim,
we'll have to take that in consideration for sure.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Luca Boccassi]

On Fri, 21 Jul 2023 at 16:14, Luca Boccassi <bluca@debian.org> wrote:
>
> On Fri, 21 Jul 2023 at 14:34, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Fri, 2023-07-21 at 14:10 +0100, Luca Boccassi wrote:
> > > On Fri, 21 Jul 2023 at 14:01, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > [...]
> > > > Well, my job is to be concerned about how individuals who want to
> > > > own their own keys, either in MoK or db, participate in this, so I
> > > > am mostly thinking about local signing.  Whatever we decide, there
> > > > must be a local workflow pathway.
> > >
> > > Sure but for local signing via MoK that's obviously fine, as one gets
> > > to keep the pieces. AFAIK it's a different flow in Shim whether
> > > something is authorized by MoK, DB or the built-in cert, so having
> > > different policies built-in for those different cases should be
> > > doable. Actually at the moment even if Shim loads the image, if it
> > > gets authorized by DB .sbat isn't checked at all.
> >
> > So let's be sure we mean the same thing here.  There is really no third
> > party CA.  Microsoft gives the distributions a signing key to allow
> > them to sign their version of shim.  Some distributions, like Red Hat,
> > also embed their signing certificates in shim, so shim can distinguish
> > between a RH key and another key added to MokList.  However, some
> > distributions, like SUSE, insist that all signing keys be approved by
> > the machine owner (so no embedded shim certs for non-enterprise) and
> > their shim can't distinguish between SUSE keys and machine owner
> > additions.  Given the variances in key handling, I think trying to
> > distinguish between official and developer keys is a huge addition of
> > complexity we don't need, so there has to be a workflow that functions
> > for both and that workflow would seem to be allowing non-existent or
> > empty sbat sections.  Official key holders  would *always* add sbat
> > sections, so there's really no problem that needs a solution to be
> > mandated here.
>
> The certificate is called the "Microsoft Corporation UEFI CA 2011" ,
> issued by the "Microsoft Corporation Third Party Marketplace Root". So
> for short, we call it UEFI 3rd party CA :-)
> Anyway, I wasn't aware that SUSE doesn't embed their cert in Shim,
> we'll have to take that in consideration for sure.

Actually, a dev from SUSE's security just confirmed they embed their
CA in Shim like every other distribution. Nobody seems to be aware of
any example where a distribution relies exclusively on MoK - and
that's understandable, as that would mean failing to boot by default
on a new machine. Do you have any example/cases where that's actually
happening? Outside development/local signing/etc.

Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

On Fri, 2023-07-21 at 16:22 +0100, Luca Boccassi wrote:
> On Fri, 21 Jul 2023 at 16:14, Luca Boccassi <bluca@debian.org> wrote:
[...]
> > Anyway, I wasn't aware that SUSE doesn't embed their cert in Shim,
> > we'll have to take that in consideration for sure.
> 
> Actually, a dev from SUSE's security just confirmed they embed their
> CA in Shim like every other distribution. Nobody seems to be aware of
> any example where a distribution relies exclusively on MoK - and
> that's understandable, as that would mean failing to boot by default
> on a new machine. Do you have any example/cases where that's actually
> happening? Outside development/local signing/etc.

It happened last year for an openSUSE Leap update that changed the
kernel signing certificate.  I got asked to confirm acceptance of the
new key and it got put in my MokList, which now has three certificates:
two suse ones and my own.

James