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

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

Right now an UKI is built with a .sbat section containing the
systemd-stub sbat string (upstream + vendor), we would like to add
also a per-component specific string (ie vmlinux has its own sbat,
again upstream + vendor, each signed add-on its own and so on).
In this way, if a specific kernel version has an issue, we can revoke
it without compromising all other UKIs that are using a different
kernel with the same stub/initrd/something else.

Issues with this patch:
* the string is added in a file but it is never deleted
* if the code is not modified but make is issued again, objcopy will
  be called again and will fail because .sbat exists already, making
  compilation fail
* minor display issue: objcopy command is printed in the make logs

Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
---
 arch/x86/boot/Makefile | 3 +++
 1 file changed, 3 insertions(+)
  

On July 11, 2023 8:44:49 AM PDT, Emanuele Giuseppe Esposito <eesposit@redhat.com> 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.
>
>Right now an UKI is built with a .sbat section containing the
>systemd-stub sbat string (upstream + vendor), we would like to add
>also a per-component specific string (ie vmlinux has its own sbat,
>again upstream + vendor, each signed add-on its own and so on).
>In this way, if a specific kernel version has an issue, we can revoke
>it without compromising all other UKIs that are using a different
>kernel with the same stub/initrd/something else.
>
>Issues with this patch:
>* the string is added in a file but it is never deleted
>* if the code is not modified but make is issued again, objcopy will
>  be called again and will fail because .sbat exists already, making
>  compilation fail
>* minor display issue: objcopy command is printed in the make logs
>
>Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>---
> arch/x86/boot/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>index 9e38ffaadb5d..6982a50ba0c0 100644
>--- a/arch/x86/boot/Makefile
>+++ b/arch/x86/boot/Makefile
>@@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
> 
> $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
> 	$(call if_changed,image)
>+	@$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat
>+	@$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat;
>+	$(OBJCOPY) --set-section-alignment '.sbat=512' --add-section .sbat=linux.sbat $@;
> 	@$(kecho) 'Kernel: $@ is ready' ' (#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
> 
> OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S

Why is this a special section rather than in the kernel_info structure?
  

On July 11, 2023 8:44:49 AM PDT, Emanuele Giuseppe Esposito <eesposit@redhat.com> 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.
>
>Right now an UKI is built with a .sbat section containing the
>systemd-stub sbat string (upstream + vendor), we would like to add
>also a per-component specific string (ie vmlinux has its own sbat,
>again upstream + vendor, each signed add-on its own and so on).
>In this way, if a specific kernel version has an issue, we can revoke
>it without compromising all other UKIs that are using a different
>kernel with the same stub/initrd/something else.
>
>Issues with this patch:
>* the string is added in a file but it is never deleted
>* if the code is not modified but make is issued again, objcopy will
>  be called again and will fail because .sbat exists already, making
>  compilation fail
>* minor display issue: objcopy command is printed in the make logs
>
>Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>---
> arch/x86/boot/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>index 9e38ffaadb5d..6982a50ba0c0 100644
>--- a/arch/x86/boot/Makefile
>+++ b/arch/x86/boot/Makefile
>@@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
> 
> $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
> 	$(call if_changed,image)
>+	@$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat
>+	@$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat;
>+	$(OBJCOPY) --set-section-alignment '.sbat=512' --add-section .sbat=linux.sbat $@;
> 	@$(kecho) 'Kernel: $@ is ready' ' (#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
> 
> OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S

Please ignore my previous message. It is a separate PECOFF section because it is consumed by UEFI rather than Linux.
  

Am 12/07/2023 um 03:33 schrieb H. Peter Anvin:
> On July 11, 2023 8:44:49 AM PDT, Emanuele Giuseppe Esposito <eesposit@redhat.com> 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.
>>
>> Right now an UKI is built with a .sbat section containing the
>> systemd-stub sbat string (upstream + vendor), we would like to add
>> also a per-component specific string (ie vmlinux has its own sbat,
>> again upstream + vendor, each signed add-on its own and so on).
>> In this way, if a specific kernel version has an issue, we can revoke
>> it without compromising all other UKIs that are using a different
>> kernel with the same stub/initrd/something else.
>>
>> Issues with this patch:
>> * the string is added in a file but it is never deleted
>> * if the code is not modified but make is issued again, objcopy will
>>  be called again and will fail because .sbat exists already, making
>>  compilation fail
>> * minor display issue: objcopy command is printed in the make logs
>>
> Please ignore my previous message. It is a separate PECOFF section because it is consumed by UEFI rather than Linux.
> 
No worries :) thanks for responding!
Any hints on how to solve any of the issues I mention above?

And any comment on the SBAT string itself? I would like to get an
agreement on
"linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org"
before we use it as semplate also for downstream.

Thank you,
Emanuele
  

On Wed, Jul 12, 2023 at 08:19:32AM +0200, Emanuele Giuseppe Esposito wrote:
> And any comment on the SBAT string itself? I would like to get an
> agreement on
> "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org"
> before we use it as semplate also for downstream.

Yeah, looks useless to me. With your patch I get:

$ cat linux.sbat
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org

But my branch is:

$ git describe
v6.5-rc1-6-g3f01e9fed845

So your thing needs to enable CONFIG_LOCALVERSION_AUTO or so which
allows for uniquely identifying the build. At least I think it did at
some point. So that you can do stuff like:

$ file vmlinux
vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=19f22ac85675ea30042fb703373d97c460bb5a61, with debug_info, not stripped

and you have a build ID sha there.

But not even that works because if I change the source, I still get the
same sha. So it needs to be an mechanism which identifies the kernel
image uniquely.

And then why does it have to be a separate section? All those
requirements need to be written down.

And regardless what you do, this looks like a contract between the
kernel and userspace tools so it absolutely needs to be documented
somewhere prominently - not in a commit message with links to flaky URLs
which would probably change in the future - and explained what the tools
parse and where one can find that parsing code.

Because if we go and change that, we need to be able to verify whether
we're not breaking any userspace tools.

Actually, I wouldn't mind even having a small script which does the
parsing and which we can use to check that we're not breaking things.

Also, while building this says:

objcopy --set-section-alignment '.sbat=512' --add-section .sbat=linux.sbat arch/x86/boot/bzImage;
objcopy: arch/x86/boot/st2fStm6:.sbat: section below image base

So you need to make it quiet.

And so on and so on...
  

On Wed, Jul 12, 2023 at 02:00:02PM +0200, Borislav Petkov wrote:
> On Wed, Jul 12, 2023 at 08:19:32AM +0200, Emanuele Giuseppe Esposito wrote:
> > And any comment on the SBAT string itself? I would like to get an
> > agreement on
> > "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org"
> > before we use it as semplate also for downstream.
> 
> Yeah, looks useless to me. With your patch I get:
> 
> $ cat linux.sbat
> sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> 
> But my branch is:
> 
> $ git describe
> v6.5-rc1-6-g3f01e9fed845

That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
file are just human targetted metadata. The validation process just
works off the 1st/2nd field.

> So your thing needs to enable CONFIG_LOCALVERSION_AUTO or so which
> allows for uniquely identifying the build. At least I think it did at
> some point. So that you can do stuff like:
> 
> $ file vmlinux
> vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=19f22ac85675ea30042fb703373d97c460bb5a61, with debug_info, not stripped
> 
> and you have a build ID sha there.
> 
> But not even that works because if I change the source, I still get the
> same sha. So it needs to be an mechanism which identifies the kernel
> image uniquely.

From a functional POV, it doesn't have to be unique identified,
as it is just a human targetted metadata field. A friendly git
version as from 'git describe' is more appropriate than a build
ID sha.

> And then why does it have to be a separate section? All those
> requirements need to be written down.
>
> And regardless what you do, this looks like a contract between the
> kernel and userspace tools so it absolutely needs to be documented
> somewhere prominently - not in a commit message with links to flaky URLs
> which would probably change in the future - and explained what the tools
> parse and where one can find that parsing code.

More precisely this is a contract between 'shim' and any other
EFI binary that is intended to be validated by 'shim' during EFI
boot, with SecureBoot enabled. Normally 'shim' would be loading
a bootloader like 'grub', but with unified kernel images (vmlinuz+
cmdline+initrd bundled in one EFI binary), there's a desire to
load the kernels directly from shim without an intermediate
bootloader. IIUC, the sbat info against the kernel would actually
be relevant even if grub is loading the kernel, as grub would still
call back into shim todo validation of the binary for secureboot
compliance.

The shim project has defined this format, and the linked git repo
provided URL is the canonical location for where this is documented.

The first doc gives the background and design approach

  https://github.com/rhboot/shim/blob/main/SBAT.md

The second docs gives an example of how revocation happens

  https://github.com/rhboot/shim/blob/main/SBAT.example.md

shim is also where you'll find the parsing code, though it is
not especially interesting, since this is just a CSV file

  https://github.com/rhboot/shim/blob/main/csv.c

called from

  https://github.com/rhboot/shim/blob/main/sbat.c

> Because if we go and change that, we need to be able to verify whether
> we're not breaking any userspace tools.
>
> Actually, I wouldn't mind even having a small script which does the
> parsing and which we can use to check that we're not breaking things.

The parsing isn't the interesting bit - any trivial CSV parsing
can validate, the semantics of each field are more important.

The first line just identifies the file format and should
never change:

  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md

The second line identifies the kernel generation

  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org

The first field 'linux' should never change once decided upon, as it is
the name of the upstream project's EFI component - in this case the
linux kernel.

The second field '1' is the most important one, as it is the mechanism
through which revokation takes places, and the only one a human upstream
maintainer should manually change.

If there is discovered a flaw in Linux that allows the Secure Boot chain
to be broken (eg some flaw allowed linux to be exploited as a mechanism
to load an unsigned binary), then this 'generation' number would need
to be incremented when a fix is provided in upstream Linux trees.

The SBAT config for shim would be updated to say 'linux,2' was the new
baseline, at which point it would refuse to load any binaries that still
had 'linux,1' in their sbat PE section.

When a downstream vendor builds the kernel they would actually add a
third record, where they append a vendor identifier to the 'linux'
component name, so the .sbat PE section might say.

 $ cat linux.sbat
 sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
 linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
 linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org

this allows Fedora to deal with revokation if they make a downstream
only mistake that compromises SecureBoot.

With regards,
Daniel
  

On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> file are just human targetted metadata. The validation process just
> works off the 1st/2nd field.

It's a good thing I asked - feels like I'm just scratching the surface
on what this thing actually is and the commit message is not explaining
any of that.

First, second field, that's what, "linux,1"?

> From a functional POV, it doesn't have to be unique identified,
> as it is just a human targetted metadata field. A friendly git
> version as from 'git describe' is more appropriate than a build
> ID sha.

So can you explain what exactly that version is supposed to describe?
Exact kernel sources the kernel was built from? Or a random, increasing
number which tools can use to mark as bad?

How do you prevent people from binary-editing that section? Secure boot
does that because that changes the signed kernel image?

> > And then why does it have to be a separate section? All those
> > requirements need to be written down.

You missed this question.

> More precisely this is a contract between 'shim' and any other
> EFI binary that is intended to be validated by 'shim' during EFI
> boot, with SecureBoot enabled. Normally 'shim' would be loading
> a bootloader like 'grub', but with unified kernel images (vmlinuz+
> cmdline+initrd bundled in one EFI binary), there's a desire to
> load the kernels directly from shim without an intermediate
> bootloader. IIUC, the sbat info against the kernel would actually
> be relevant even if grub is loading the kernel, as grub would still
> call back into shim todo validation of the binary for secureboot
> compliance.
> 
> The shim project has defined this format, and the linked git repo
> provided URL is the canonical location for where this is documented.
> 
> The first doc gives the background and design approach
> 
>   https://github.com/rhboot/shim/blob/main/SBAT.md

Yeah, tried reading that. That section explaining the prior to
disclosure, after disclosure numbers incrementing is a mess waiting to
happen.

> The first line just identifies the file format and should
> never change:
> 
>   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md

Why do you even need it then?

> The second line identifies the kernel generation
> 
>   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> 
> The first field 'linux' should never change once decided upon, as it is
> the name of the upstream project's EFI component - in this case the
> linux kernel.
> 
> The second field '1' is the most important one, as it is the mechanism
> through which revokation takes places, and the only one a human upstream
> maintainer should manually change.

Hold on, how often are those things going to change? And who's going to
change them? I sure hope we won't start getting patches constantly
updating those numbers?

> If there is discovered a flaw in Linux that allows the Secure Boot chain
> to be broken (eg some flaw allowed linux to be exploited as a mechanism
> to load an unsigned binary), then this 'generation' number would need
> to be incremented when a fix is provided in upstream Linux trees.

Oh boy, there it is. And then when those fixes need to be backported to
stable, then those patches updating that number would need to be
backported too. I can already see the mess on the horizon.

> The SBAT config for shim would be updated to say 'linux,2' was the new
> baseline, at which point it would refuse to load any binaries that still
> had 'linux,1' in their sbat PE section.

Ok, I fetch the latest upstream kernel, it has "linux,1", shim refuses
to load. I go, edit the sources, increment that to "linux,234" and secure
boot works. No fixes applied.

So either I'm missing something but if not, that number thing is really
silly.

> When a downstream vendor builds the kernel they would actually add a
> third record, where they append a vendor identifier to the 'linux'
> component name, so the .sbat PE section might say.
> 
>  $ cat linux.sbat
>  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
>  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
>  linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org
> 
> this allows Fedora to deal with revokation if they make a downstream
> only mistake that compromises SecureBoot.

What does that mean, "allows Fedora to deal with revokation"?

Anyway, thanks for taking the time to explain.

In any case, I think this does not belong in the upstream kernel as this
will turn us into CVE trackers. Distros sure, ofc, that's more along the
lines of what they do but not the upstream kernel.

And there must be a better way to map "fixes present in the tree" to
a number which shim verifies.

Thx.
  

On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > file are just human targetted metadata. The validation process just
> > works off the 1st/2nd field.
> 
> It's a good thing I asked - feels like I'm just scratching the surface
> on what this thing actually is and the commit message is not explaining
> any of that.
> 
> First, second field, that's what, "linux,1"?

Each sbat CSV file line has following fields:

  component_name: the name we're comparing
  component_generation: the generation number for the comparison
  vendor_name: human readable vendor name
  vendor_package_name: human readable package name
  vendor_version: human readable package version (maybe machine parseable too, not specified here)
  vendor_url: url to look stuff up, contact, whatever.

So 'linux' is 'component_name' and '1' is component_generation

> > From a functional POV, it doesn't have to be unique identified,
> > as it is just a human targetted metadata field. A friendly git
> > version as from 'git describe' is more appropriate than a build
> > ID sha.
> 
> So can you explain what exactly that version is supposed to describe?
> Exact kernel sources the kernel was built from? Or a random, increasing
> number which tools can use to mark as bad?

AFAICT beyond being "human readable package version", it is a fairly
arbitrary decision. A release version number for formal releases, or
a 'git describe' version string for git snapshots both satisfy the
versioning requirement IMHO.

> How do you prevent people from binary-editing that section? Secure boot
> does that because that changes the signed kernel image?

The PE files are signed by the vendor who builds them, using their
SecureBoot signing key. The data covered by the signature includes
the '.sbat' section.

IOW, if you binary edit the section, the SecureBoot signature
verification fails and the kernel won't be booted.

> > > And then why does it have to be a separate section? All those
> > > requirements need to be written down.
> 
> You missed this question.

That's simply what the spec defines as the approach.

The PE file format used by EFI applications has multiple
sections and the spec has declare that the '.sbat' section
is where this data shall live.

> > The first line just identifies the file format and should
> > never change:
> > 
> >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> 
> Why do you even need it then?

First it identifies the data format, and second if a
problem is ever discovered with the  SBAT concept,
a fixed approach can be indicated by changing to
'sbat,2,.....' and thus have the effect of revoking
use of any binaries which declare the 'sbat,1,....'
version. Pretty unlikely this will happen, but a useful
backup plan/safety net.

> > The second line identifies the kernel generation
> > 
> >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > 
> > The first field 'linux' should never change once decided upon, as it is
> > the name of the upstream project's EFI component - in this case the
> > linux kernel.
> > 
> > The second field '1' is the most important one, as it is the mechanism
> > through which revokation takes places, and the only one a human upstream
> > maintainer should manually change.
> 
> Hold on, how often are those things going to change? And who's going to
> change them? I sure hope we won't start getting patches constantly
> updating those numbers?

It is hard to predict the future, but my gut feeling is very infrequently.

I can't say I recall any specific Linux bugs that would warrant it, but
those involved in Linux/Bootloade/SecureBoot world can probably answer
this better than me. IIUC, the scope of bugs relevent to this is quite
narrow.

> > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > to load an unsigned binary), then this 'generation' number would need
> > to be incremented when a fix is provided in upstream Linux trees.
> 
> Oh boy, there it is. And then when those fixes need to be backported to
> stable, then those patches updating that number would need to be
> backported too. I can already see the mess on the horizon.

If applicable, yes.

> > The SBAT config for shim would be updated to say 'linux,2' was the new
> > baseline, at which point it would refuse to load any binaries that still
> > had 'linux,1' in their sbat PE section.
> 
> Ok, I fetch the latest upstream kernel, it has "linux,1", shim refuses
> to load. I go, edit the sources, increment that to "linux,234" and secure
> boot works. No fixes applied.

Everything involved in the boot path is covered by signatures, so if
SecureBoot is enabled you can't simply build custom binaries. They
won't run unless you modify your EFI firmware config to trust your
own signing keys. If a user wants to compromise their own machine in
that way, that's fine.

> > When a downstream vendor builds the kernel they would actually add a
> > third record, where they append a vendor identifier to the 'linux'
> > component name, so the .sbat PE section might say.
> > 
> >  $ cat linux.sbat
> >  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> >  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> >  linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org
> > 
> > this allows Fedora to deal with revokation if they make a downstream
> > only mistake that compromises SecureBoot.
> 
> What does that mean, "allows Fedora to deal with revokation"?

Lets say Fedora applied a non-upstream kernel patch that compromised
SecureBoot. Upstream Linux has no reason to change their SBAT component
generation number. Instead Fedora would change their 'linux.fedora'
component generation number to reflect their own mistake.

> In any case, I think this does not belong in the upstream kernel as this
> will turn us into CVE trackers. Distros sure, ofc, that's more along the
> lines of what they do but not the upstream kernel.

My understanding is that CVEs in general would not apply in this
scenario, the scope of bugs that are impactful is reasonably
narrow. I'll defer to people more experienced in SecureBoot though
if they have a better answer.


With regards,
Daniel
  

On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > file are just human targetted metadata. The validation process just
> > > works off the 1st/2nd field.
> > 
> > It's a good thing I asked - feels like I'm just scratching the surface
> > on what this thing actually is and the commit message is not explaining
> > any of that.
> > 
> > First, second field, that's what, "linux,1"?
> 
> Each sbat CSV file line has following fields:
> 
>   component_name: the name we're comparing
>   component_generation: the generation number for the comparison
>   vendor_name: human readable vendor name
>   vendor_package_name: human readable package name
>   vendor_version: human readable package version (maybe machine parseable too, not specified here)
>   vendor_url: url to look stuff up, contact, whatever.
> 
> So 'linux' is 'component_name' and '1' is component_generation
> 
> > > From a functional POV, it doesn't have to be unique identified,
> > > as it is just a human targetted metadata field. A friendly git
> > > version as from 'git describe' is more appropriate than a build
> > > ID sha.
> > 
> > So can you explain what exactly that version is supposed to describe?
> > Exact kernel sources the kernel was built from? Or a random, increasing
> > number which tools can use to mark as bad?
> 
> AFAICT beyond being "human readable package version", it is a fairly
> arbitrary decision. A release version number for formal releases, or
> a 'git describe' version string for git snapshots both satisfy the
> versioning requirement IMHO.
> 
> > How do you prevent people from binary-editing that section? Secure boot
> > does that because that changes the signed kernel image?
> 
> The PE files are signed by the vendor who builds them, using their
> SecureBoot signing key. The data covered by the signature includes
> the '.sbat' section.
> 
> IOW, if you binary edit the section, the SecureBoot signature
> verification fails and the kernel won't be booted.
> 
> > > > And then why does it have to be a separate section? All those
> > > > requirements need to be written down.
> > 
> > You missed this question.
> 
> That's simply what the spec defines as the approach.
> 
> The PE file format used by EFI applications has multiple
> sections and the spec has declare that the '.sbat' section
> is where this data shall live.
> 
> > > The first line just identifies the file format and should
> > > never change:
> > > 
> > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > 
> > Why do you even need it then?
> 
> First it identifies the data format, and second if a
> problem is ever discovered with the  SBAT concept,
> a fixed approach can be indicated by changing to
> 'sbat,2,.....' and thus have the effect of revoking
> use of any binaries which declare the 'sbat,1,....'
> version. Pretty unlikely this will happen, but a useful
> backup plan/safety net.
> 
> > > The second line identifies the kernel generation
> > > 
> > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > 
> > > The first field 'linux' should never change once decided upon, as it is
> > > the name of the upstream project's EFI component - in this case the
> > > linux kernel.
> > > 
> > > The second field '1' is the most important one, as it is the mechanism
> > > through which revokation takes places, and the only one a human upstream
> > > maintainer should manually change.
> > 
> > Hold on, how often are those things going to change? And who's going to
> > change them? I sure hope we won't start getting patches constantly
> > updating those numbers?
> 
> It is hard to predict the future, but my gut feeling is very infrequently.

Have you looked at the past as proof of this?

> I can't say I recall any specific Linux bugs that would warrant it, but
> those involved in Linux/Bootloade/SecureBoot world can probably answer
> this better than me. IIUC, the scope of bugs relevent to this is quite
> narrow.

Really?  I know a lot of people who would disagree...

> > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > to load an unsigned binary), then this 'generation' number would need
> > > to be incremented when a fix is provided in upstream Linux trees.
> > 
> > Oh boy, there it is. And then when those fixes need to be backported to
> > stable, then those patches updating that number would need to be
> > backported too. I can already see the mess on the horizon.
> 
> If applicable, yes.

And how are you going to determine this?

> > > The SBAT config for shim would be updated to say 'linux,2' was the new
> > > baseline, at which point it would refuse to load any binaries that still
> > > had 'linux,1' in their sbat PE section.
> > 
> > Ok, I fetch the latest upstream kernel, it has "linux,1", shim refuses
> > to load. I go, edit the sources, increment that to "linux,234" and secure
> > boot works. No fixes applied.
> 
> Everything involved in the boot path is covered by signatures, so if
> SecureBoot is enabled you can't simply build custom binaries. They
> won't run unless you modify your EFI firmware config to trust your
> own signing keys. If a user wants to compromise their own machine in
> that way, that's fine.

"SecureBoot" is a distro-specific thing, they handle the keys, it's not
anything the normal kernel deals with.

> > > When a downstream vendor builds the kernel they would actually add a
> > > third record, where they append a vendor identifier to the 'linux'
> > > component name, so the .sbat PE section might say.
> > > 
> > >  $ cat linux.sbat
> > >  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > >  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > >  linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org
> > > 
> > > this allows Fedora to deal with revokation if they make a downstream
> > > only mistake that compromises SecureBoot.
> > 
> > What does that mean, "allows Fedora to deal with revokation"?
> 
> Lets say Fedora applied a non-upstream kernel patch that compromised
> SecureBoot. Upstream Linux has no reason to change their SBAT component
> generation number. Instead Fedora would change their 'linux.fedora'
> component generation number to reflect their own mistake.

Why are you somehow trying to differenciate between "upstream" and
Fedora's kernels here?

Why does "upstream" need any of this?

And how can you tell if upstream "makes a mistake" that compromises
secure boot?  Who is going to keep track of this?  Who is auditing all
of our fixes/changes to verify this?  Have you looked at the past year
or so and actually determined if you could properly determine this?  If
not, why not?

> > In any case, I think this does not belong in the upstream kernel as this
> > will turn us into CVE trackers. Distros sure, ofc, that's more along the
> > lines of what they do but not the upstream kernel.
> 
> My understanding is that CVEs in general would not apply in this
> scenario, the scope of bugs that are impactful is reasonably
> narrow. I'll defer to people more experienced in SecureBoot though
> if they have a better answer.

You have a kernel version number, we don't change anything outside of
those version numbers (i.e. if we add changes to a release, we bump the
version number.)

So why do you need anything other than the kernel version number?

thanks,

greg k-h
  

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.
> 
> Right now an UKI is built with a .sbat section containing the
> systemd-stub sbat string (upstream + vendor), we would like to add
> also a per-component specific string (ie vmlinux has its own sbat,
> again upstream + vendor, each signed add-on its own and so on).
> In this way, if a specific kernel version has an issue, we can revoke
> it without compromising all other UKIs that are using a different
> kernel with the same stub/initrd/something else.
> 
> Issues with this patch:
> * the string is added in a file but it is never deleted
> * if the code is not modified but make is issued again, objcopy will
>   be called again and will fail because .sbat exists already, making
>   compilation fail
> * minor display issue: objcopy command is printed in the make logs
> 
> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
> ---
>  arch/x86/boot/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
> index 9e38ffaadb5d..6982a50ba0c0 100644
> --- a/arch/x86/boot/Makefile
> +++ b/arch/x86/boot/Makefile
> @@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
>  
>  $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
>  	$(call if_changed,image)
> +	@$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat
> +	@$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat;

Who controls "linux.org"?  Why are you thinking they have anything to do
with kernel development?

This shows a huge lack of understanding of loads of things, please go
get other experienced Red Hat developers to sign off on the next version
of your patch before you ask the community to review it.

As is, this is not going to go far.

thanks,

greg k-h
  

On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > file are just human targetted metadata. The validation process just
> > > > works off the 1st/2nd field.
> > >
> > > It's a good thing I asked - feels like I'm just scratching the surface
> > > on what this thing actually is and the commit message is not explaining
> > > any of that.
> > >
> > > First, second field, that's what, "linux,1"?
> >
> > Each sbat CSV file line has following fields:
> >
> >   component_name: the name we're comparing
> >   component_generation: the generation number for the comparison
> >   vendor_name: human readable vendor name
> >   vendor_package_name: human readable package name
> >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> >   vendor_url: url to look stuff up, contact, whatever.
> >
> > So 'linux' is 'component_name' and '1' is component_generation
> >
> > > > From a functional POV, it doesn't have to be unique identified,
> > > > as it is just a human targetted metadata field. A friendly git
> > > > version as from 'git describe' is more appropriate than a build
> > > > ID sha.
> > >
> > > So can you explain what exactly that version is supposed to describe?
> > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > number which tools can use to mark as bad?
> >
> > AFAICT beyond being "human readable package version", it is a fairly
> > arbitrary decision. A release version number for formal releases, or
> > a 'git describe' version string for git snapshots both satisfy the
> > versioning requirement IMHO.
> >
> > > How do you prevent people from binary-editing that section? Secure boot
> > > does that because that changes the signed kernel image?
> >
> > The PE files are signed by the vendor who builds them, using their
> > SecureBoot signing key. The data covered by the signature includes
> > the '.sbat' section.
> >
> > IOW, if you binary edit the section, the SecureBoot signature
> > verification fails and the kernel won't be booted.
> >
> > > > > And then why does it have to be a separate section? All those
> > > > > requirements need to be written down.
> > >
> > > You missed this question.
> >
> > That's simply what the spec defines as the approach.
> >
> > The PE file format used by EFI applications has multiple
> > sections and the spec has declare that the '.sbat' section
> > is where this data shall live.
> >
> > > > The first line just identifies the file format and should
> > > > never change:
> > > >
> > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > >
> > > Why do you even need it then?
> >
> > First it identifies the data format, and second if a
> > problem is ever discovered with the  SBAT concept,
> > a fixed approach can be indicated by changing to
> > 'sbat,2,.....' and thus have the effect of revoking
> > use of any binaries which declare the 'sbat,1,....'
> > version. Pretty unlikely this will happen, but a useful
> > backup plan/safety net.
> >
> > > > The second line identifies the kernel generation
> > > >
> > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > >
> > > > The first field 'linux' should never change once decided upon, as it is
> > > > the name of the upstream project's EFI component - in this case the
> > > > linux kernel.
> > > >
> > > > The second field '1' is the most important one, as it is the mechanism
> > > > through which revokation takes places, and the only one a human upstream
> > > > maintainer should manually change.
> > >
> > > Hold on, how often are those things going to change? And who's going to
> > > change them? I sure hope we won't start getting patches constantly
> > > updating those numbers?
> >
> > It is hard to predict the future, but my gut feeling is very infrequently.
>
> Have you looked at the past as proof of this?

I can't quite think of relevant bugs, in the recent past. Are you
aware of past instances of kernel module signature verification being
broken? Or userspace being allowed to do arbitrary kernel memory
manipulation before ExitBootServices?

> > I can't say I recall any specific Linux bugs that would warrant it, but
> > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > this better than me. IIUC, the scope of bugs relevent to this is quite
> > narrow.
>
> Really?  I know a lot of people who would disagree...

They'd better have some convincing reasons

> > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > to load an unsigned binary), then this 'generation' number would need
> > > > to be incremented when a fix is provided in upstream Linux trees.
> > >
> > > Oh boy, there it is. And then when those fixes need to be backported to
> > > stable, then those patches updating that number would need to be
> > > backported too. I can already see the mess on the horizon.
> >
> > If applicable, yes.
>
> And how are you going to determine this?

Same as it's done for the bootloaders - does it enable a secure boot
bypass -> yes/no

> > > > The SBAT config for shim would be updated to say 'linux,2' was the new
> > > > baseline, at which point it would refuse to load any binaries that still
> > > > had 'linux,1' in their sbat PE section.
> > >
> > > Ok, I fetch the latest upstream kernel, it has "linux,1", shim refuses
> > > to load. I go, edit the sources, increment that to "linux,234" and secure
> > > boot works. No fixes applied.
> >
> > Everything involved in the boot path is covered by signatures, so if
> > SecureBoot is enabled you can't simply build custom binaries. They
> > won't run unless you modify your EFI firmware config to trust your
> > own signing keys. If a user wants to compromise their own machine in
> > that way, that's fine.
>
> "SecureBoot" is a distro-specific thing, they handle the keys, it's not
> anything the normal kernel deals with.

Nah, you are thinking of key management, but this is not about that.
This is about vulnerabilities that allow secure boot bypass, and the
normal kernel very much deals with that. Kernel module signature
enforcement, Lockdown LSM, ensuring ExitBootServices is called at the
right time, etc.

> > > > When a downstream vendor builds the kernel they would actually add a
> > > > third record, where they append a vendor identifier to the 'linux'
> > > > component name, so the .sbat PE section might say.
> > > >
> > > >  $ cat linux.sbat
> > > >  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > >  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > >  linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org
> > > >
> > > > this allows Fedora to deal with revokation if they make a downstream
> > > > only mistake that compromises SecureBoot.
> > >
> > > What does that mean, "allows Fedora to deal with revokation"?
> >
> > Lets say Fedora applied a non-upstream kernel patch that compromised
> > SecureBoot. Upstream Linux has no reason to change their SBAT component
> > generation number. Instead Fedora would change their 'linux.fedora'
> > component generation number to reflect their own mistake.
>
> Why are you somehow trying to differenciate between "upstream" and
> Fedora's kernels here?

Because they _are_ different, and a secure boot bypass can be added
via a downstream patch or an upstream change, and it is important to
differentiate as we don't want to needlessly revoke. Having to rollout
a new Debian kernel because there is a vulnerability in a Fedora patch
would be a silly waste of time.

> Why does "upstream" need any of this?

Because 'upstream' is involved in the boot chain

> And how can you tell if upstream "makes a mistake" that compromises
> secure boot?  Who is going to keep track of this?  Who is auditing all
> of our fixes/changes to verify this?  Have you looked at the past year
> or so and actually determined if you could properly determine this?  If
> not, why not?

The same people who are already doing this for bootloaders, I would guess.

> > > In any case, I think this does not belong in the upstream kernel as this
> > > will turn us into CVE trackers. Distros sure, ofc, that's more along the
> > > lines of what they do but not the upstream kernel.
> >
> > My understanding is that CVEs in general would not apply in this
> > scenario, the scope of bugs that are impactful is reasonably
> > narrow. I'll defer to people more experienced in SecureBoot though
> > if they have a better answer.
>
> You have a kernel version number, we don't change anything outside of
> those version numbers (i.e. if we add changes to a release, we bump the
> version number.)
>
> So why do you need anything other than the kernel version number?

This is not about version identification, it is about cutoff points,
which are much more coarse _but_ apply to both mainline and stable
branches. The version number is not usable, as you would need N of
them, and the principal goal of SBAT is having fixed size metadata
that doesn't explode in size as time progresses.
  

On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > file are just human targetted metadata. The validation process just
> > > > > works off the 1st/2nd field.
> > > >
> > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > on what this thing actually is and the commit message is not explaining
> > > > any of that.
> > > >
> > > > First, second field, that's what, "linux,1"?
> > >
> > > Each sbat CSV file line has following fields:
> > >
> > >   component_name: the name we're comparing
> > >   component_generation: the generation number for the comparison
> > >   vendor_name: human readable vendor name
> > >   vendor_package_name: human readable package name
> > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > >   vendor_url: url to look stuff up, contact, whatever.
> > >
> > > So 'linux' is 'component_name' and '1' is component_generation
> > >
> > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > as it is just a human targetted metadata field. A friendly git
> > > > > version as from 'git describe' is more appropriate than a build
> > > > > ID sha.
> > > >
> > > > So can you explain what exactly that version is supposed to describe?
> > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > number which tools can use to mark as bad?
> > >
> > > AFAICT beyond being "human readable package version", it is a fairly
> > > arbitrary decision. A release version number for formal releases, or
> > > a 'git describe' version string for git snapshots both satisfy the
> > > versioning requirement IMHO.
> > >
> > > > How do you prevent people from binary-editing that section? Secure boot
> > > > does that because that changes the signed kernel image?
> > >
> > > The PE files are signed by the vendor who builds them, using their
> > > SecureBoot signing key. The data covered by the signature includes
> > > the '.sbat' section.
> > >
> > > IOW, if you binary edit the section, the SecureBoot signature
> > > verification fails and the kernel won't be booted.
> > >
> > > > > > And then why does it have to be a separate section? All those
> > > > > > requirements need to be written down.
> > > >
> > > > You missed this question.
> > >
> > > That's simply what the spec defines as the approach.
> > >
> > > The PE file format used by EFI applications has multiple
> > > sections and the spec has declare that the '.sbat' section
> > > is where this data shall live.
> > >
> > > > > The first line just identifies the file format and should
> > > > > never change:
> > > > >
> > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > >
> > > > Why do you even need it then?
> > >
> > > First it identifies the data format, and second if a
> > > problem is ever discovered with the  SBAT concept,
> > > a fixed approach can be indicated by changing to
> > > 'sbat,2,.....' and thus have the effect of revoking
> > > use of any binaries which declare the 'sbat,1,....'
> > > version. Pretty unlikely this will happen, but a useful
> > > backup plan/safety net.
> > >
> > > > > The second line identifies the kernel generation
> > > > >
> > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > >
> > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > the name of the upstream project's EFI component - in this case the
> > > > > linux kernel.
> > > > >
> > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > through which revokation takes places, and the only one a human upstream
> > > > > maintainer should manually change.
> > > >
> > > > Hold on, how often are those things going to change? And who's going to
> > > > change them? I sure hope we won't start getting patches constantly
> > > > updating those numbers?
> > >
> > > It is hard to predict the future, but my gut feeling is very infrequently.
> >
> > Have you looked at the past as proof of this?
> 
> I can't quite think of relevant bugs, in the recent past. Are you
> aware of past instances of kernel module signature verification being
> broken? Or userspace being allowed to do arbitrary kernel memory
> manipulation before ExitBootServices?

Yes.

And no, I will not provide examples for obvious reasons.

> > > I can't say I recall any specific Linux bugs that would warrant it, but
> > > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > > this better than me. IIUC, the scope of bugs relevent to this is quite
> > > narrow.
> >
> > Really?  I know a lot of people who would disagree...
> 
> They'd better have some convincing reasons
> 
> > > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > > to load an unsigned binary), then this 'generation' number would need
> > > > > to be incremented when a fix is provided in upstream Linux trees.
> > > >
> > > > Oh boy, there it is. And then when those fixes need to be backported to
> > > > stable, then those patches updating that number would need to be
> > > > backported too. I can already see the mess on the horizon.
> > >
> > > If applicable, yes.
> >
> > And how are you going to determine this?
> 
> Same as it's done for the bootloaders - does it enable a secure boot
> bypass -> yes/no

And how are you going to determine this?  Seriously, please explain the
auditing you are going to do here and who is going to maintain it and
fund the effort?

> > > > > The SBAT config for shim would be updated to say 'linux,2' was the new
> > > > > baseline, at which point it would refuse to load any binaries that still
> > > > > had 'linux,1' in their sbat PE section.
> > > >
> > > > Ok, I fetch the latest upstream kernel, it has "linux,1", shim refuses
> > > > to load. I go, edit the sources, increment that to "linux,234" and secure
> > > > boot works. No fixes applied.
> > >
> > > Everything involved in the boot path is covered by signatures, so if
> > > SecureBoot is enabled you can't simply build custom binaries. They
> > > won't run unless you modify your EFI firmware config to trust your
> > > own signing keys. If a user wants to compromise their own machine in
> > > that way, that's fine.
> >
> > "SecureBoot" is a distro-specific thing, they handle the keys, it's not
> > anything the normal kernel deals with.
> 
> Nah, you are thinking of key management, but this is not about that.
> This is about vulnerabilities that allow secure boot bypass, and the
> normal kernel very much deals with that. Kernel module signature
> enforcement, Lockdown LSM, ensuring ExitBootServices is called at the
> right time, etc.

Yes, that's all fun things but they have nothing to do with a vague idea
of "SecureBoot" that you wish to apply for your specific threat model.
They make up the potential solution for your model, but individually
don't.

> > > > > When a downstream vendor builds the kernel they would actually add a
> > > > > third record, where they append a vendor identifier to the 'linux'
> > > > > component name, so the .sbat PE section might say.
> > > > >
> > > > >  $ cat linux.sbat
> > > > >  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > >  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > >  linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org
> > > > >
> > > > > this allows Fedora to deal with revokation if they make a downstream
> > > > > only mistake that compromises SecureBoot.
> > > >
> > > > What does that mean, "allows Fedora to deal with revokation"?
> > >
> > > Lets say Fedora applied a non-upstream kernel patch that compromised
> > > SecureBoot. Upstream Linux has no reason to change their SBAT component
> > > generation number. Instead Fedora would change their 'linux.fedora'
> > > component generation number to reflect their own mistake.
> >
> > Why are you somehow trying to differenciate between "upstream" and
> > Fedora's kernels here?
> 
> Because they _are_ different, and a secure boot bypass can be added
> via a downstream patch or an upstream change, and it is important to
> differentiate as we don't want to needlessly revoke. Having to rollout
> a new Debian kernel because there is a vulnerability in a Fedora patch
> would be a silly waste of time.

Agreed, why would any of us care about Fedora-specific patches?

> > Why does "upstream" need any of this?
> 
> Because 'upstream' is involved in the boot chain

How exactly?

> > And how can you tell if upstream "makes a mistake" that compromises
> > secure boot?  Who is going to keep track of this?  Who is auditing all
> > of our fixes/changes to verify this?  Have you looked at the past year
> > or so and actually determined if you could properly determine this?  If
> > not, why not?
> 
> The same people who are already doing this for bootloaders, I would guess.

If you don't know who is doing this work, that means the work isn't
actually happening, so none of this will ever work at all.

sorry,

greg k-h
  

On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > file are just human targetted metadata. The validation process just
> > > > > > works off the 1st/2nd field.
> > > > >
> > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > on what this thing actually is and the commit message is not explaining
> > > > > any of that.
> > > > >
> > > > > First, second field, that's what, "linux,1"?
> > > >
> > > > Each sbat CSV file line has following fields:
> > > >
> > > >   component_name: the name we're comparing
> > > >   component_generation: the generation number for the comparison
> > > >   vendor_name: human readable vendor name
> > > >   vendor_package_name: human readable package name
> > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > >   vendor_url: url to look stuff up, contact, whatever.
> > > >
> > > > So 'linux' is 'component_name' and '1' is component_generation
> > > >
> > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > ID sha.
> > > > >
> > > > > So can you explain what exactly that version is supposed to describe?
> > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > number which tools can use to mark as bad?
> > > >
> > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > arbitrary decision. A release version number for formal releases, or
> > > > a 'git describe' version string for git snapshots both satisfy the
> > > > versioning requirement IMHO.
> > > >
> > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > does that because that changes the signed kernel image?
> > > >
> > > > The PE files are signed by the vendor who builds them, using their
> > > > SecureBoot signing key. The data covered by the signature includes
> > > > the '.sbat' section.
> > > >
> > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > verification fails and the kernel won't be booted.
> > > >
> > > > > > > And then why does it have to be a separate section? All those
> > > > > > > requirements need to be written down.
> > > > >
> > > > > You missed this question.
> > > >
> > > > That's simply what the spec defines as the approach.
> > > >
> > > > The PE file format used by EFI applications has multiple
> > > > sections and the spec has declare that the '.sbat' section
> > > > is where this data shall live.
> > > >
> > > > > > The first line just identifies the file format and should
> > > > > > never change:
> > > > > >
> > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > >
> > > > > Why do you even need it then?
> > > >
> > > > First it identifies the data format, and second if a
> > > > problem is ever discovered with the  SBAT concept,
> > > > a fixed approach can be indicated by changing to
> > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > use of any binaries which declare the 'sbat,1,....'
> > > > version. Pretty unlikely this will happen, but a useful
> > > > backup plan/safety net.
> > > >
> > > > > > The second line identifies the kernel generation
> > > > > >
> > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > >
> > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > linux kernel.
> > > > > >
> > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > maintainer should manually change.
> > > > >
> > > > > Hold on, how often are those things going to change? And who's going to
> > > > > change them? I sure hope we won't start getting patches constantly
> > > > > updating those numbers?
> > > >
> > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > >
> > > Have you looked at the past as proof of this?
> >
> > I can't quite think of relevant bugs, in the recent past. Are you
> > aware of past instances of kernel module signature verification being
> > broken? Or userspace being allowed to do arbitrary kernel memory
> > manipulation before ExitBootServices?
>
> Yes.

Then you already know the answer w.r.t. frequency

> And no, I will not provide examples for obvious reasons.

Security-through-obscurity? Nice!

> > > > I can't say I recall any specific Linux bugs that would warrant it, but
> > > > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > > > this better than me. IIUC, the scope of bugs relevent to this is quite
> > > > narrow.
> > >
> > > Really?  I know a lot of people who would disagree...
> >
> > They'd better have some convincing reasons
> >
> > > > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > > > to load an unsigned binary), then this 'generation' number would need
> > > > > > to be incremented when a fix is provided in upstream Linux trees.
> > > > >
> > > > > Oh boy, there it is. And then when those fixes need to be backported to
> > > > > stable, then those patches updating that number would need to be
> > > > > backported too. I can already see the mess on the horizon.
> > > >
> > > > If applicable, yes.
> > >
> > > And how are you going to determine this?
> >
> > Same as it's done for the bootloaders - does it enable a secure boot
> > bypass -> yes/no
>
> And how are you going to determine this?  Seriously, please explain the
> auditing you are going to do here and who is going to maintain it and
> fund the effort?

Same way it is determined for Shim, Grub, sd-boot, Windows BootMngr,
etc - maintainers doing their jobs, researchers poking at them, or if
we are particularly unlucky by live exploits in the wild. I'm not
exactly sure where the confusion comes from, none of this is novel.

> > > > > > The SBAT config for shim would be updated to say 'linux,2' was the new
> > > > > > baseline, at which point it would refuse to load any binaries that still
> > > > > > had 'linux,1' in their sbat PE section.
> > > > >
> > > > > Ok, I fetch the latest upstream kernel, it has "linux,1", shim refuses
> > > > > to load. I go, edit the sources, increment that to "linux,234" and secure
> > > > > boot works. No fixes applied.
> > > >
> > > > Everything involved in the boot path is covered by signatures, so if
> > > > SecureBoot is enabled you can't simply build custom binaries. They
> > > > won't run unless you modify your EFI firmware config to trust your
> > > > own signing keys. If a user wants to compromise their own machine in
> > > > that way, that's fine.
> > >
> > > "SecureBoot" is a distro-specific thing, they handle the keys, it's not
> > > anything the normal kernel deals with.
> >
> > Nah, you are thinking of key management, but this is not about that.
> > This is about vulnerabilities that allow secure boot bypass, and the
> > normal kernel very much deals with that. Kernel module signature
> > enforcement, Lockdown LSM, ensuring ExitBootServices is called at the
> > right time, etc.
>
> Yes, that's all fun things but they have nothing to do with a vague idea
> of "SecureBoot" that you wish to apply for your specific threat model.
> They make up the potential solution for your model, but individually
> don't.

First of all, it's not 'my' model, secondly, I have no clue where you
got the idea that any one of those 'individually implemented secure
boot', because that's certainly not what I wrote.

> > > > > > When a downstream vendor builds the kernel they would actually add a
> > > > > > third record, where they append a vendor identifier to the 'linux'
> > > > > > component name, so the .sbat PE section might say.
> > > > > >
> > > > > >  $ cat linux.sbat
> > > > > >  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > >  linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > >  linux.fedora,1,The Fedora Project,linux,6.5.0-rc1,https://fedoraproject.org
> > > > > >
> > > > > > this allows Fedora to deal with revokation if they make a downstream
> > > > > > only mistake that compromises SecureBoot.
> > > > >
> > > > > What does that mean, "allows Fedora to deal with revokation"?
> > > >
> > > > Lets say Fedora applied a non-upstream kernel patch that compromised
> > > > SecureBoot. Upstream Linux has no reason to change their SBAT component
> > > > generation number. Instead Fedora would change their 'linux.fedora'
> > > > component generation number to reflect their own mistake.
> > >
> > > Why are you somehow trying to differenciate between "upstream" and
> > > Fedora's kernels here?
> >
> > Because they _are_ different, and a secure boot bypass can be added
> > via a downstream patch or an upstream change, and it is important to
> > differentiate as we don't want to needlessly revoke. Having to rollout
> > a new Debian kernel because there is a vulnerability in a Fedora patch
> > would be a silly waste of time.
>
> Agreed, why would any of us care about Fedora-specific patches?

Precisely, hence why the SBAT protocol explicitly supports separate
downstream vs upstream fields

> > > Why does "upstream" need any of this?
> >
> > Because 'upstream' is involved in the boot chain
>
> How exactly?

Seriously?

> > > And how can you tell if upstream "makes a mistake" that compromises
> > > secure boot?  Who is going to keep track of this?  Who is auditing all
> > > of our fixes/changes to verify this?  Have you looked at the past year
> > > or so and actually determined if you could properly determine this?  If
> > > not, why not?
> >
> > The same people who are already doing this for bootloaders, I would guess.
>
> If you don't know who is doing this work, that means the work isn't
> actually happening, so none of this will ever work at all.

Yes, famously there's nobody doing kernel maintenance/research/etc,
how silly of me
  

On Wed, Jul 12, 2023 at 07:59:12PM +0100, Luca Boccassi wrote:
> On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > > file are just human targetted metadata. The validation process just
> > > > > > > works off the 1st/2nd field.
> > > > > >
> > > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > > on what this thing actually is and the commit message is not explaining
> > > > > > any of that.
> > > > > >
> > > > > > First, second field, that's what, "linux,1"?
> > > > >
> > > > > Each sbat CSV file line has following fields:
> > > > >
> > > > >   component_name: the name we're comparing
> > > > >   component_generation: the generation number for the comparison
> > > > >   vendor_name: human readable vendor name
> > > > >   vendor_package_name: human readable package name
> > > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > > >   vendor_url: url to look stuff up, contact, whatever.
> > > > >
> > > > > So 'linux' is 'component_name' and '1' is component_generation
> > > > >
> > > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > > ID sha.
> > > > > >
> > > > > > So can you explain what exactly that version is supposed to describe?
> > > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > > number which tools can use to mark as bad?
> > > > >
> > > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > > arbitrary decision. A release version number for formal releases, or
> > > > > a 'git describe' version string for git snapshots both satisfy the
> > > > > versioning requirement IMHO.
> > > > >
> > > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > > does that because that changes the signed kernel image?
> > > > >
> > > > > The PE files are signed by the vendor who builds them, using their
> > > > > SecureBoot signing key. The data covered by the signature includes
> > > > > the '.sbat' section.
> > > > >
> > > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > > verification fails and the kernel won't be booted.
> > > > >
> > > > > > > > And then why does it have to be a separate section? All those
> > > > > > > > requirements need to be written down.
> > > > > >
> > > > > > You missed this question.
> > > > >
> > > > > That's simply what the spec defines as the approach.
> > > > >
> > > > > The PE file format used by EFI applications has multiple
> > > > > sections and the spec has declare that the '.sbat' section
> > > > > is where this data shall live.
> > > > >
> > > > > > > The first line just identifies the file format and should
> > > > > > > never change:
> > > > > > >
> > > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > >
> > > > > > Why do you even need it then?
> > > > >
> > > > > First it identifies the data format, and second if a
> > > > > problem is ever discovered with the  SBAT concept,
> > > > > a fixed approach can be indicated by changing to
> > > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > > use of any binaries which declare the 'sbat,1,....'
> > > > > version. Pretty unlikely this will happen, but a useful
> > > > > backup plan/safety net.
> > > > >
> > > > > > > The second line identifies the kernel generation
> > > > > > >
> > > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > > >
> > > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > > linux kernel.
> > > > > > >
> > > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > > maintainer should manually change.
> > > > > >
> > > > > > Hold on, how often are those things going to change? And who's going to
> > > > > > change them? I sure hope we won't start getting patches constantly
> > > > > > updating those numbers?
> > > > >
> > > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > > >
> > > > Have you looked at the past as proof of this?
> > >
> > > I can't quite think of relevant bugs, in the recent past. Are you
> > > aware of past instances of kernel module signature verification being
> > > broken? Or userspace being allowed to do arbitrary kernel memory
> > > manipulation before ExitBootServices?
> >
> > Yes.
> 
> Then you already know the answer w.r.t. frequency

I have a clue, yes.  But given that others do not that are proposing
this, that's quite worrying.

> > And no, I will not provide examples for obvious reasons.
> 
> Security-through-obscurity? Nice!

That's not what this is, please see the many places this is explained
in detail.  If you wish to discuss how the kernel security team handles
known security fixes, we can do so on a relevant thread (i.e. not this
one.)

> > > > > I can't say I recall any specific Linux bugs that would warrant it, but
> > > > > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > > > > this better than me. IIUC, the scope of bugs relevent to this is quite
> > > > > narrow.
> > > >
> > > > Really?  I know a lot of people who would disagree...
> > >
> > > They'd better have some convincing reasons
> > >
> > > > > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > > > > to load an unsigned binary), then this 'generation' number would need
> > > > > > > to be incremented when a fix is provided in upstream Linux trees.
> > > > > >
> > > > > > Oh boy, there it is. And then when those fixes need to be backported to
> > > > > > stable, then those patches updating that number would need to be
> > > > > > backported too. I can already see the mess on the horizon.
> > > > >
> > > > > If applicable, yes.
> > > >
> > > > And how are you going to determine this?
> > >
> > > Same as it's done for the bootloaders - does it enable a secure boot
> > > bypass -> yes/no
> >
> > And how are you going to determine this?  Seriously, please explain the
> > auditing you are going to do here and who is going to maintain it and
> > fund the effort?
> 
> Same way it is determined for Shim, Grub, sd-boot, Windows BootMngr,
> etc - maintainers doing their jobs, researchers poking at them, or if
> we are particularly unlucky by live exploits in the wild. I'm not
> exactly sure where the confusion comes from, none of this is novel.

But why does any of this matter at all?  Just use the kernel version
(which is already in the image), and be done with it.  We always
increment it so all should be fine.

If a distro wants to track how they add various fixes/changes/hacks/etc
to the kernel image, that's fine for them to do so too, but it doesn't
deserve some opaque "epoch number" like you all are proposing here.

thanks,

greg k-h
  

On Wed, 12 Jul 2023 at 20:05, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 07:59:12PM +0100, Luca Boccassi wrote:
> > On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > > > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > > > file are just human targetted metadata. The validation process just
> > > > > > > > works off the 1st/2nd field.
> > > > > > >
> > > > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > > > on what this thing actually is and the commit message is not explaining
> > > > > > > any of that.
> > > > > > >
> > > > > > > First, second field, that's what, "linux,1"?
> > > > > >
> > > > > > Each sbat CSV file line has following fields:
> > > > > >
> > > > > >   component_name: the name we're comparing
> > > > > >   component_generation: the generation number for the comparison
> > > > > >   vendor_name: human readable vendor name
> > > > > >   vendor_package_name: human readable package name
> > > > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > > > >   vendor_url: url to look stuff up, contact, whatever.
> > > > > >
> > > > > > So 'linux' is 'component_name' and '1' is component_generation
> > > > > >
> > > > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > > > ID sha.
> > > > > > >
> > > > > > > So can you explain what exactly that version is supposed to describe?
> > > > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > > > number which tools can use to mark as bad?
> > > > > >
> > > > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > > > arbitrary decision. A release version number for formal releases, or
> > > > > > a 'git describe' version string for git snapshots both satisfy the
> > > > > > versioning requirement IMHO.
> > > > > >
> > > > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > > > does that because that changes the signed kernel image?
> > > > > >
> > > > > > The PE files are signed by the vendor who builds them, using their
> > > > > > SecureBoot signing key. The data covered by the signature includes
> > > > > > the '.sbat' section.
> > > > > >
> > > > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > > > verification fails and the kernel won't be booted.
> > > > > >
> > > > > > > > > And then why does it have to be a separate section? All those
> > > > > > > > > requirements need to be written down.
> > > > > > >
> > > > > > > You missed this question.
> > > > > >
> > > > > > That's simply what the spec defines as the approach.
> > > > > >
> > > > > > The PE file format used by EFI applications has multiple
> > > > > > sections and the spec has declare that the '.sbat' section
> > > > > > is where this data shall live.
> > > > > >
> > > > > > > > The first line just identifies the file format and should
> > > > > > > > never change:
> > > > > > > >
> > > > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > > >
> > > > > > > Why do you even need it then?
> > > > > >
> > > > > > First it identifies the data format, and second if a
> > > > > > problem is ever discovered with the  SBAT concept,
> > > > > > a fixed approach can be indicated by changing to
> > > > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > > > use of any binaries which declare the 'sbat,1,....'
> > > > > > version. Pretty unlikely this will happen, but a useful
> > > > > > backup plan/safety net.
> > > > > >
> > > > > > > > The second line identifies the kernel generation
> > > > > > > >
> > > > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > > > >
> > > > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > > > linux kernel.
> > > > > > > >
> > > > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > > > maintainer should manually change.
> > > > > > >
> > > > > > > Hold on, how often are those things going to change? And who's going to
> > > > > > > change them? I sure hope we won't start getting patches constantly
> > > > > > > updating those numbers?
> > > > > >
> > > > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > > > >
> > > > > Have you looked at the past as proof of this?
> > > >
> > > > I can't quite think of relevant bugs, in the recent past. Are you
> > > > aware of past instances of kernel module signature verification being
> > > > broken? Or userspace being allowed to do arbitrary kernel memory
> > > > manipulation before ExitBootServices?
> > >
> > > Yes.
> >
> > Then you already know the answer w.r.t. frequency
>
> I have a clue, yes.  But given that others do not that are proposing
> this, that's quite worrying.

Not really, as that's not the purpose. As the documentation clearly
states, the purpose is to have a revocation mechanism that won't
exhaust nvram space.

> > > And no, I will not provide examples for obvious reasons.
> >
> > Security-through-obscurity? Nice!
>
> That's not what this is, please see the many places this is explained
> in detail.  If you wish to discuss how the kernel security team handles
> known security fixes, we can do so on a relevant thread (i.e. not this
> one.)
>
> > > > > > I can't say I recall any specific Linux bugs that would warrant it, but
> > > > > > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > > > > > this better than me. IIUC, the scope of bugs relevent to this is quite
> > > > > > narrow.
> > > > >
> > > > > Really?  I know a lot of people who would disagree...
> > > >
> > > > They'd better have some convincing reasons
> > > >
> > > > > > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > > > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > > > > > to load an unsigned binary), then this 'generation' number would need
> > > > > > > > to be incremented when a fix is provided in upstream Linux trees.
> > > > > > >
> > > > > > > Oh boy, there it is. And then when those fixes need to be backported to
> > > > > > > stable, then those patches updating that number would need to be
> > > > > > > backported too. I can already see the mess on the horizon.
> > > > > >
> > > > > > If applicable, yes.
> > > > >
> > > > > And how are you going to determine this?
> > > >
> > > > Same as it's done for the bootloaders - does it enable a secure boot
> > > > bypass -> yes/no
> > >
> > > And how are you going to determine this?  Seriously, please explain the
> > > auditing you are going to do here and who is going to maintain it and
> > > fund the effort?
> >
> > Same way it is determined for Shim, Grub, sd-boot, Windows BootMngr,
> > etc - maintainers doing their jobs, researchers poking at them, or if
> > we are particularly unlucky by live exploits in the wild. I'm not
> > exactly sure where the confusion comes from, none of this is novel.
>
> But why does any of this matter at all?  Just use the kernel version
> (which is already in the image), and be done with it.  We always
> increment it so all should be fine.

No, all will not be fine, because stable branches exist, so it would
not be _one_ kernel version but N, with monotonically increasing
values of N. That doesn't work, and the reason for that are explained
in the protocol documentation that was linked in the initial mail.
  

On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> No, all will not be fine, because stable branches exist, so it would
> not be _one_ kernel version but N, with monotonically increasing
> values of N. That doesn't work, and the reason for that are explained
> in the protocol documentation that was linked in the initial mail.

Lemme give Peter's example from earlier today:

Bugfix A -> number 2
Bugfix B -> number 3

Tree backports only Bugfix B. Which number do you use?

And so on and so on. 

Patch your own trees - this doesn't belong upstream.

Thx.
  

On Wed, 12 Jul 2023 at 20:42, Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> > No, all will not be fine, because stable branches exist, so it would
> > not be _one_ kernel version but N, with monotonically increasing
> > values of N. That doesn't work, and the reason for that are explained
> > in the protocol documentation that was linked in the initial mail.
>
> Lemme give Peter's example from earlier today:
>
> Bugfix A -> number 2
> Bugfix B -> number 3
>
> Tree backports only Bugfix B. Which number do you use?
>
> And so on and so on.

Everything < 3 is revoked _and_ the generation id in the stable branch
is _not_ bumped, because it's still vulnerable and so that branch is
effectively dead and unbootable on any system with secure boot
enabled. This is a revocation mechanism, not a bug tracking mechanism.
There's no mix-and-matching.

> Patch your own trees - this doesn't belong upstream.

Nah, it belongs in both places. Please read the documentation and
spend at least some time trying to understand the actual problem being
solved before commenting - or don't comment at all, that's fine too.
  

On Wed, Jul 12, 2023 at 08:56:36PM +0100, Luca Boccassi wrote:
> Everything < 3 is revoked _and_ the generation id in the stable branch
> is _not_ bumped, because it's still vulnerable and so that branch is
> effectively dead and unbootable on any system with secure boot
> enabled. This is a revocation mechanism, not a bug tracking mechanism.
> There's no mix-and-matching.

No, this is a mess waiting to happen.

> Nah, it belongs in both places. Please read the documentation and
> spend at least some time trying to understand the actual problem being

You want to have this patch in the tree - the commit message should
explain why it is needed and not point to some documentation somewhere.

> solved before commenting - or don't comment at all, that's fine too.

Here's a comment for ya:

Naked-by: Borislav Petkov (AMD) <bp@alien8.de>
  

On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> On Wed, 12 Jul 2023 at 20:05, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jul 12, 2023 at 07:59:12PM +0100, Luca Boccassi wrote:
> > > On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > > > > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > > > > file are just human targetted metadata. The validation process just
> > > > > > > > > works off the 1st/2nd field.
> > > > > > > >
> > > > > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > > > > on what this thing actually is and the commit message is not explaining
> > > > > > > > any of that.
> > > > > > > >
> > > > > > > > First, second field, that's what, "linux,1"?
> > > > > > >
> > > > > > > Each sbat CSV file line has following fields:
> > > > > > >
> > > > > > >   component_name: the name we're comparing
> > > > > > >   component_generation: the generation number for the comparison
> > > > > > >   vendor_name: human readable vendor name
> > > > > > >   vendor_package_name: human readable package name
> > > > > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > > > > >   vendor_url: url to look stuff up, contact, whatever.
> > > > > > >
> > > > > > > So 'linux' is 'component_name' and '1' is component_generation
> > > > > > >
> > > > > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > > > > ID sha.
> > > > > > > >
> > > > > > > > So can you explain what exactly that version is supposed to describe?
> > > > > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > > > > number which tools can use to mark as bad?
> > > > > > >
> > > > > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > > > > arbitrary decision. A release version number for formal releases, or
> > > > > > > a 'git describe' version string for git snapshots both satisfy the
> > > > > > > versioning requirement IMHO.
> > > > > > >
> > > > > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > > > > does that because that changes the signed kernel image?
> > > > > > >
> > > > > > > The PE files are signed by the vendor who builds them, using their
> > > > > > > SecureBoot signing key. The data covered by the signature includes
> > > > > > > the '.sbat' section.
> > > > > > >
> > > > > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > > > > verification fails and the kernel won't be booted.
> > > > > > >
> > > > > > > > > > And then why does it have to be a separate section? All those
> > > > > > > > > > requirements need to be written down.
> > > > > > > >
> > > > > > > > You missed this question.
> > > > > > >
> > > > > > > That's simply what the spec defines as the approach.
> > > > > > >
> > > > > > > The PE file format used by EFI applications has multiple
> > > > > > > sections and the spec has declare that the '.sbat' section
> > > > > > > is where this data shall live.
> > > > > > >
> > > > > > > > > The first line just identifies the file format and should
> > > > > > > > > never change:
> > > > > > > > >
> > > > > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > > > >
> > > > > > > > Why do you even need it then?
> > > > > > >
> > > > > > > First it identifies the data format, and second if a
> > > > > > > problem is ever discovered with the  SBAT concept,
> > > > > > > a fixed approach can be indicated by changing to
> > > > > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > > > > use of any binaries which declare the 'sbat,1,....'
> > > > > > > version. Pretty unlikely this will happen, but a useful
> > > > > > > backup plan/safety net.
> > > > > > >
> > > > > > > > > The second line identifies the kernel generation
> > > > > > > > >
> > > > > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > > > > >
> > > > > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > > > > linux kernel.
> > > > > > > > >
> > > > > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > > > > maintainer should manually change.
> > > > > > > >
> > > > > > > > Hold on, how often are those things going to change? And who's going to
> > > > > > > > change them? I sure hope we won't start getting patches constantly
> > > > > > > > updating those numbers?
> > > > > > >
> > > > > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > > > > >
> > > > > > Have you looked at the past as proof of this?
> > > > >
> > > > > I can't quite think of relevant bugs, in the recent past. Are you
> > > > > aware of past instances of kernel module signature verification being
> > > > > broken? Or userspace being allowed to do arbitrary kernel memory
> > > > > manipulation before ExitBootServices?
> > > >
> > > > Yes.
> > >
> > > Then you already know the answer w.r.t. frequency
> >
> > I have a clue, yes.  But given that others do not that are proposing
> > this, that's quite worrying.
> 
> Not really, as that's not the purpose. As the documentation clearly
> states, the purpose is to have a revocation mechanism that won't
> exhaust nvram space.

How do you know that the list of issues will not exhaust it, if you
don't know how many issues are found?

Take the time and look over the past 10 years and get an idea of what
you are dealing with here please.

Also note that "single identifiers for individual issues" do NOT work
for kernel fixes (and arguably do not work for any other software
project either) as they fail to properly describe things.

Think about Meltdown, one "identifier" of a CVE, and hundreds of
patches.  What if you happened to not backport one of them?

Same goes for the issue reported last week or so, tens of fixes, over
multiple stable kernel releases, for one "identifier", how would you
have classified that?

Anyway, I've been over this loads before, giving whole talks about this,
there's a reason the kernel developers don't mess with CVEs (i.e.
individual identifiers), they fail to work.

> > > > And no, I will not provide examples for obvious reasons.
> > >
> > > Security-through-obscurity? Nice!
> >
> > That's not what this is, please see the many places this is explained
> > in detail.  If you wish to discuss how the kernel security team handles
> > known security fixes, we can do so on a relevant thread (i.e. not this
> > one.)
> >
> > > > > > > I can't say I recall any specific Linux bugs that would warrant it, but
> > > > > > > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > > > > > > this better than me. IIUC, the scope of bugs relevent to this is quite
> > > > > > > narrow.
> > > > > >
> > > > > > Really?  I know a lot of people who would disagree...
> > > > >
> > > > > They'd better have some convincing reasons
> > > > >
> > > > > > > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > > > > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > > > > > > to load an unsigned binary), then this 'generation' number would need
> > > > > > > > > to be incremented when a fix is provided in upstream Linux trees.
> > > > > > > >
> > > > > > > > Oh boy, there it is. And then when those fixes need to be backported to
> > > > > > > > stable, then those patches updating that number would need to be
> > > > > > > > backported too. I can already see the mess on the horizon.
> > > > > > >
> > > > > > > If applicable, yes.
> > > > > >
> > > > > > And how are you going to determine this?
> > > > >
> > > > > Same as it's done for the bootloaders - does it enable a secure boot
> > > > > bypass -> yes/no
> > > >
> > > > And how are you going to determine this?  Seriously, please explain the
> > > > auditing you are going to do here and who is going to maintain it and
> > > > fund the effort?
> > >
> > > Same way it is determined for Shim, Grub, sd-boot, Windows BootMngr,
> > > etc - maintainers doing their jobs, researchers poking at them, or if
> > > we are particularly unlucky by live exploits in the wild. I'm not
> > > exactly sure where the confusion comes from, none of this is novel.
> >
> > But why does any of this matter at all?  Just use the kernel version
> > (which is already in the image), and be done with it.  We always
> > increment it so all should be fine.
> 
> No, all will not be fine, because stable branches exist, so it would
> not be _one_ kernel version but N, with monotonically increasing
> values of N. That doesn't work, and the reason for that are explained
> in the protocol documentation that was linked in the initial mail.

Pointing to an external document that is thousands of lines long,
talking about bootloaders, is NOT a good way to get people to want to
accept a kernel patch :)

good luck!

greg k-h
  

On Wed, 12 Jul 2023 at 21:01, Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Jul 12, 2023 at 08:56:36PM +0100, Luca Boccassi wrote:
> > Everything < 3 is revoked _and_ the generation id in the stable branch
> > is _not_ bumped, because it's still vulnerable and so that branch is
> > effectively dead and unbootable on any system with secure boot
> > enabled. This is a revocation mechanism, not a bug tracking mechanism.
> > There's no mix-and-matching.
>
> No, this is a mess waiting to happen.

That's not very convincing. You are aware that this mechanism exists
and is already used by other EFI components, yes?

> > Nah, it belongs in both places. Please read the documentation and
> > spend at least some time trying to understand the actual problem being
>
> You want to have this patch in the tree - the commit message should
> explain why it is needed and not point to some documentation somewhere.

Then why not just ask for that, instead of making convoluted
assumptions based on nothing of substance?

> > solved before commenting - or don't comment at all, that's fine too.
>
> Here's a comment for ya:
>
> Naked-by: Borislav Petkov (AMD) <bp@alien8.de>

So very mature. No wonder kernel maintainers and the LKML are
universally loved and praised.
  

On Wed, 12 Jul 2023 at 21:07, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> > On Wed, 12 Jul 2023 at 20:05, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 07:59:12PM +0100, Luca Boccassi wrote:
> > > > On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > > > > > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > > > > > file are just human targetted metadata. The validation process just
> > > > > > > > > > works off the 1st/2nd field.
> > > > > > > > >
> > > > > > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > > > > > on what this thing actually is and the commit message is not explaining
> > > > > > > > > any of that.
> > > > > > > > >
> > > > > > > > > First, second field, that's what, "linux,1"?
> > > > > > > >
> > > > > > > > Each sbat CSV file line has following fields:
> > > > > > > >
> > > > > > > >   component_name: the name we're comparing
> > > > > > > >   component_generation: the generation number for the comparison
> > > > > > > >   vendor_name: human readable vendor name
> > > > > > > >   vendor_package_name: human readable package name
> > > > > > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > > > > > >   vendor_url: url to look stuff up, contact, whatever.
> > > > > > > >
> > > > > > > > So 'linux' is 'component_name' and '1' is component_generation
> > > > > > > >
> > > > > > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > > > > > ID sha.
> > > > > > > > >
> > > > > > > > > So can you explain what exactly that version is supposed to describe?
> > > > > > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > > > > > number which tools can use to mark as bad?
> > > > > > > >
> > > > > > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > > > > > arbitrary decision. A release version number for formal releases, or
> > > > > > > > a 'git describe' version string for git snapshots both satisfy the
> > > > > > > > versioning requirement IMHO.
> > > > > > > >
> > > > > > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > > > > > does that because that changes the signed kernel image?
> > > > > > > >
> > > > > > > > The PE files are signed by the vendor who builds them, using their
> > > > > > > > SecureBoot signing key. The data covered by the signature includes
> > > > > > > > the '.sbat' section.
> > > > > > > >
> > > > > > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > > > > > verification fails and the kernel won't be booted.
> > > > > > > >
> > > > > > > > > > > And then why does it have to be a separate section? All those
> > > > > > > > > > > requirements need to be written down.
> > > > > > > > >
> > > > > > > > > You missed this question.
> > > > > > > >
> > > > > > > > That's simply what the spec defines as the approach.
> > > > > > > >
> > > > > > > > The PE file format used by EFI applications has multiple
> > > > > > > > sections and the spec has declare that the '.sbat' section
> > > > > > > > is where this data shall live.
> > > > > > > >
> > > > > > > > > > The first line just identifies the file format and should
> > > > > > > > > > never change:
> > > > > > > > > >
> > > > > > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > > > > >
> > > > > > > > > Why do you even need it then?
> > > > > > > >
> > > > > > > > First it identifies the data format, and second if a
> > > > > > > > problem is ever discovered with the  SBAT concept,
> > > > > > > > a fixed approach can be indicated by changing to
> > > > > > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > > > > > use of any binaries which declare the 'sbat,1,....'
> > > > > > > > version. Pretty unlikely this will happen, but a useful
> > > > > > > > backup plan/safety net.
> > > > > > > >
> > > > > > > > > > The second line identifies the kernel generation
> > > > > > > > > >
> > > > > > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > > > > > >
> > > > > > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > > > > > linux kernel.
> > > > > > > > > >
> > > > > > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > > > > > maintainer should manually change.
> > > > > > > > >
> > > > > > > > > Hold on, how often are those things going to change? And who's going to
> > > > > > > > > change them? I sure hope we won't start getting patches constantly
> > > > > > > > > updating those numbers?
> > > > > > > >
> > > > > > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > > > > > >
> > > > > > > Have you looked at the past as proof of this?
> > > > > >
> > > > > > I can't quite think of relevant bugs, in the recent past. Are you
> > > > > > aware of past instances of kernel module signature verification being
> > > > > > broken? Or userspace being allowed to do arbitrary kernel memory
> > > > > > manipulation before ExitBootServices?
> > > > >
> > > > > Yes.
> > > >
> > > > Then you already know the answer w.r.t. frequency
> > >
> > > I have a clue, yes.  But given that others do not that are proposing
> > > this, that's quite worrying.
> >
> > Not really, as that's not the purpose. As the documentation clearly
> > states, the purpose is to have a revocation mechanism that won't
> > exhaust nvram space.
>
> How do you know that the list of issues will not exhaust it, if you
> don't know how many issues are found?
>
> Take the time and look over the past 10 years and get an idea of what
> you are dealing with here please.
>
> Also note that "single identifiers for individual issues" do NOT work
> for kernel fixes (and arguably do not work for any other software
> project either) as they fail to properly describe things.
>
> Think about Meltdown, one "identifier" of a CVE, and hundreds of
> patches.  What if you happened to not backport one of them?
>
> Same goes for the issue reported last week or so, tens of fixes, over
> multiple stable kernel releases, for one "identifier", how would you
> have classified that?
>
> Anyway, I've been over this loads before, giving whole talks about this,
> there's a reason the kernel developers don't mess with CVEs (i.e.
> individual identifiers), they fail to work.

There is no 'single identifier for individual issues' nor CVE involved
here. The purpose of the generation id (which is per EFI component,
not per bug) is to let the boot process know whether an EFI component
should be accepted or rejected, in a way that doesn't exhaust nvram.
Issues are not individually singled out, and there is no direct
correlation with CVEs. It doesn't matter how many fixes there are, or
how many bugs, if a generation of a component is vulnerable in any way
that matters, then it gets denied.

The only thing that matters is, "if we had infinite space in DBX and
sensible ways to service it and nvram didn't wear down, would we
blocklist this component version" - if the answer is no, then nothing
happens. If the answer is yes, then the counter goes up.

> > > > > And no, I will not provide examples for obvious reasons.
> > > >
> > > > Security-through-obscurity? Nice!
> > >
> > > That's not what this is, please see the many places this is explained
> > > in detail.  If you wish to discuss how the kernel security team handles
> > > known security fixes, we can do so on a relevant thread (i.e. not this
> > > one.)
> > >
> > > > > > > > I can't say I recall any specific Linux bugs that would warrant it, but
> > > > > > > > those involved in Linux/Bootloade/SecureBoot world can probably answer
> > > > > > > > this better than me. IIUC, the scope of bugs relevent to this is quite
> > > > > > > > narrow.
> > > > > > >
> > > > > > > Really?  I know a lot of people who would disagree...
> > > > > >
> > > > > > They'd better have some convincing reasons
> > > > > >
> > > > > > > > > > If there is discovered a flaw in Linux that allows the Secure Boot chain
> > > > > > > > > > to be broken (eg some flaw allowed linux to be exploited as a mechanism
> > > > > > > > > > to load an unsigned binary), then this 'generation' number would need
> > > > > > > > > > to be incremented when a fix is provided in upstream Linux trees.
> > > > > > > > >
> > > > > > > > > Oh boy, there it is. And then when those fixes need to be backported to
> > > > > > > > > stable, then those patches updating that number would need to be
> > > > > > > > > backported too. I can already see the mess on the horizon.
> > > > > > > >
> > > > > > > > If applicable, yes.
> > > > > > >
> > > > > > > And how are you going to determine this?
> > > > > >
> > > > > > Same as it's done for the bootloaders - does it enable a secure boot
> > > > > > bypass -> yes/no
> > > > >
> > > > > And how are you going to determine this?  Seriously, please explain the
> > > > > auditing you are going to do here and who is going to maintain it and
> > > > > fund the effort?
> > > >
> > > > Same way it is determined for Shim, Grub, sd-boot, Windows BootMngr,
> > > > etc - maintainers doing their jobs, researchers poking at them, or if
> > > > we are particularly unlucky by live exploits in the wild. I'm not
> > > > exactly sure where the confusion comes from, none of this is novel.
> > >
> > > But why does any of this matter at all?  Just use the kernel version
> > > (which is already in the image), and be done with it.  We always
> > > increment it so all should be fine.
> >
> > No, all will not be fine, because stable branches exist, so it would
> > not be _one_ kernel version but N, with monotonically increasing
> > values of N. That doesn't work, and the reason for that are explained
> > in the protocol documentation that was linked in the initial mail.
>
> Pointing to an external document that is thousands of lines long,
> talking about bootloaders, is NOT a good way to get people to want to
> accept a kernel patch :)

Then how about just asking for that? "Hello submitter, please send a
v2 with a detailed summary of the problem being solved for those of us
who are not familiar with it, thank you"
  

On Wed, Jul 12, 2023 at 09:41:23PM +0100, Luca Boccassi wrote:
> > Pointing to an external document that is thousands of lines long,
> > talking about bootloaders, is NOT a good way to get people to want to
> > accept a kernel patch :)
> 
> Then how about just asking for that? "Hello submitter, please send a
> v2 with a detailed summary of the problem being solved for those of us
> who are not familiar with it, thank you"

That is what our documentation states that the submitter should have
already done:
	https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
  

Hello,

On Wed, Jul 12, 2023 at 09:41:23PM +0100, Luca Boccassi wrote:
> > Also note that "single identifiers for individual issues" do NOT work
> > for kernel fixes (and arguably do not work for any other software
> > project either) as they fail to properly describe things.
> >
> > Think about Meltdown, one "identifier" of a CVE, and hundreds of
> > patches.  What if you happened to not backport one of them?
> >
> > Same goes for the issue reported last week or so, tens of fixes, over
> > multiple stable kernel releases, for one "identifier", how would you
> > have classified that?
> >
> > Anyway, I've been over this loads before, giving whole talks about this,
> > there's a reason the kernel developers don't mess with CVEs (i.e.
> > individual identifiers), they fail to work.
> 
> There is no 'single identifier for individual issues' nor CVE involved
> here. The purpose of the generation id (which is per EFI component,
> not per bug) is to let the boot process know whether an EFI component
> should be accepted or rejected, in a way that doesn't exhaust nvram.
> Issues are not individually singled out, and there is no direct
> correlation with CVEs. It doesn't matter how many fixes there are, or
> how many bugs, if a generation of a component is vulnerable in any way
> that matters, then it gets denied.

I refrained from chiming in but I'm really reading shocking stuff here,
so please let me make a few comments based on some old experience.

Several times in this thread you seemed to imply that there is "someone" or
"something" that knows whether or not a kernel is absolutely vulnerable
or absolutely trustable regarding a certain bug, when developers
themselves only have an estimate about it, whose probability quickly
fades away with the depth of backports.

When I was in charge of extended 2.6.32 many years ago, the Debian kernel
team helped me by occasionally sending me series of backports of fixes
for issues I had missed, and fixes for backports I had failed. That's the
principle of maintenance: adding incremental fixes that make the whole
code better.

With your process (OK you said it's not yours, but then why adopt it when
it doesn't match the workflow of the software it tries to adapt to), how
would we proceed ? "Let's bump this ID now that the new 2.6.32.233 has
everything fixed". Or rather "let's *not* bump it because nobody knows
how to backport this other stuff that's blocking the ID increment". Then
once finally bumped, one month later we figure that the fixes were still
incorrect due to important differences in the older branches, and have
to be fixed again, so according to what I understand, we must then
immediately revoke the current ID, that is also shared by upstream and
all correctly fixed maintenance branches, and have to emit a new one
for all branches at once even if the code didn't change, just because
myself incompetent stable maintainer of the week-end failed to fix
something non-obvious at once ? If so, I'm sorry but this is non-sense.
There must be another approach to this or it was designed by someone
having never met a bug in person!

What I'm also wondering is, if in the end it turns out that only the
distro has the skills to decide which kernel version is fixed and which
one isn't (after all, it's the distro who chooses the config and the
compiler, both are as much involved in bugs as the code itself), then
why not make sort of a wrapper or an envelope around an existing kernel
image, which provides this ID that the distro can freely choose, then
transfer the control to the embedded kernel image ? This might give
the distro the freedom to proceed as it wants with no cross-dependency
on kernel branches.

> > Pointing to an external document that is thousands of lines long,
> > talking about bootloaders, is NOT a good way to get people to want to
> > accept a kernel patch :)
> 
> Then how about just asking for that? "Hello submitter, please send a
> v2 with a detailed summary of the problem being solved for those of us
> who are not familiar with it, thank you"

Probably that there was a problem with process in the first place by
which someone asks some maintainers to accept to merge, maintain and
become responsible for breaking changes they disagree with, without
having even being presented to them before being developed ?

Regards,
Willy
  

On Wed, Jul 12, 2023 at 09:41:23PM +0100, Luca Boccassi wrote:
> On Wed, 12 Jul 2023 at 21:07, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> > > On Wed, 12 Jul 2023 at 20:05, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, Jul 12, 2023 at 07:59:12PM +0100, Luca Boccassi wrote:
> > > > > On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > > > > > > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > > > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > > > > > > file are just human targetted metadata. The validation process just
> > > > > > > > > > > works off the 1st/2nd field.
> > > > > > > > > >
> > > > > > > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > > > > > > on what this thing actually is and the commit message is not explaining
> > > > > > > > > > any of that.
> > > > > > > > > >
> > > > > > > > > > First, second field, that's what, "linux,1"?
> > > > > > > > >
> > > > > > > > > Each sbat CSV file line has following fields:
> > > > > > > > >
> > > > > > > > >   component_name: the name we're comparing
> > > > > > > > >   component_generation: the generation number for the comparison
> > > > > > > > >   vendor_name: human readable vendor name
> > > > > > > > >   vendor_package_name: human readable package name
> > > > > > > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > > > > > > >   vendor_url: url to look stuff up, contact, whatever.
> > > > > > > > >
> > > > > > > > > So 'linux' is 'component_name' and '1' is component_generation
> > > > > > > > >
> > > > > > > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > > > > > > ID sha.
> > > > > > > > > >
> > > > > > > > > > So can you explain what exactly that version is supposed to describe?
> > > > > > > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > > > > > > number which tools can use to mark as bad?
> > > > > > > > >
> > > > > > > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > > > > > > arbitrary decision. A release version number for formal releases, or
> > > > > > > > > a 'git describe' version string for git snapshots both satisfy the
> > > > > > > > > versioning requirement IMHO.
> > > > > > > > >
> > > > > > > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > > > > > > does that because that changes the signed kernel image?
> > > > > > > > >
> > > > > > > > > The PE files are signed by the vendor who builds them, using their
> > > > > > > > > SecureBoot signing key. The data covered by the signature includes
> > > > > > > > > the '.sbat' section.
> > > > > > > > >
> > > > > > > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > > > > > > verification fails and the kernel won't be booted.
> > > > > > > > >
> > > > > > > > > > > > And then why does it have to be a separate section? All those
> > > > > > > > > > > > requirements need to be written down.
> > > > > > > > > >
> > > > > > > > > > You missed this question.
> > > > > > > > >
> > > > > > > > > That's simply what the spec defines as the approach.
> > > > > > > > >
> > > > > > > > > The PE file format used by EFI applications has multiple
> > > > > > > > > sections and the spec has declare that the '.sbat' section
> > > > > > > > > is where this data shall live.
> > > > > > > > >
> > > > > > > > > > > The first line just identifies the file format and should
> > > > > > > > > > > never change:
> > > > > > > > > > >
> > > > > > > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > > > > > >
> > > > > > > > > > Why do you even need it then?
> > > > > > > > >
> > > > > > > > > First it identifies the data format, and second if a
> > > > > > > > > problem is ever discovered with the  SBAT concept,
> > > > > > > > > a fixed approach can be indicated by changing to
> > > > > > > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > > > > > > use of any binaries which declare the 'sbat,1,....'
> > > > > > > > > version. Pretty unlikely this will happen, but a useful
> > > > > > > > > backup plan/safety net.
> > > > > > > > >
> > > > > > > > > > > The second line identifies the kernel generation
> > > > > > > > > > >
> > > > > > > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > > > > > > >
> > > > > > > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > > > > > > linux kernel.
> > > > > > > > > > >
> > > > > > > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > > > > > > maintainer should manually change.
> > > > > > > > > >
> > > > > > > > > > Hold on, how often are those things going to change? And who's going to
> > > > > > > > > > change them? I sure hope we won't start getting patches constantly
> > > > > > > > > > updating those numbers?
> > > > > > > > >
> > > > > > > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > > > > > > >
> > > > > > > > Have you looked at the past as proof of this?
> > > > > > >
> > > > > > > I can't quite think of relevant bugs, in the recent past. Are you
> > > > > > > aware of past instances of kernel module signature verification being
> > > > > > > broken? Or userspace being allowed to do arbitrary kernel memory
> > > > > > > manipulation before ExitBootServices?
> > > > > >
> > > > > > Yes.
> > > > >
> > > > > Then you already know the answer w.r.t. frequency
> > > >
> > > > I have a clue, yes.  But given that others do not that are proposing
> > > > this, that's quite worrying.
> > >
> > > Not really, as that's not the purpose. As the documentation clearly
> > > states, the purpose is to have a revocation mechanism that won't
> > > exhaust nvram space.
> >
> > How do you know that the list of issues will not exhaust it, if you
> > don't know how many issues are found?
> >
> > Take the time and look over the past 10 years and get an idea of what
> > you are dealing with here please.
> >
> > Also note that "single identifiers for individual issues" do NOT work
> > for kernel fixes (and arguably do not work for any other software
> > project either) as they fail to properly describe things.
> >
> > Think about Meltdown, one "identifier" of a CVE, and hundreds of
> > patches.  What if you happened to not backport one of them?
> >
> > Same goes for the issue reported last week or so, tens of fixes, over
> > multiple stable kernel releases, for one "identifier", how would you
> > have classified that?
> >
> > Anyway, I've been over this loads before, giving whole talks about this,
> > there's a reason the kernel developers don't mess with CVEs (i.e.
> > individual identifiers), they fail to work.
> 
> There is no 'single identifier for individual issues' nor CVE involved
> here. The purpose of the generation id (which is per EFI component,
> not per bug) is to let the boot process know whether an EFI component
> should be accepted or rejected, in a way that doesn't exhaust nvram.
> Issues are not individually singled out, and there is no direct
> correlation with CVEs. It doesn't matter how many fixes there are, or
> how many bugs, if a generation of a component is vulnerable in any way
> that matters, then it gets denied.

What does "in any way that matters" mean exactly?

And are you treating the whole kernel as an "EFI component" here?

Who is going to be responsible for determining that this number needs to
be updated?

How are they going to determine this?

What is their response time?

Who will they be submitting the patch to this string in order to have it
change?

And how is any of this going to interact with stable kernel releases,
long term kernel releases and end-of-life kernel releases?

How long will this feature have to be maintained?

> The only thing that matters is, "if we had infinite space in DBX and
> sensible ways to service it and nvram didn't wear down, would we
> blocklist this component version" - if the answer is no, then nothing
> happens. If the answer is yes, then the counter goes up.

I suggest you all take a look at the past 10 years of kernel releases
and changes (to pick a simple number) and determine what the number
would be now if you were to start counting then.  Is it 10?  100?
10000?  What do you think it will be in the next 40 years?

We have a plethora of kernel changes in our history to learn from here,
please do so and show how this will affect us going forward based on our
past, otherwise we have no way of knowing how any of this is going to
work.

thanks,

greg k-h
  

On Wed, 12 Jul 2023 at 22:20, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 09:41:23PM +0100, Luca Boccassi wrote:
> > On Wed, 12 Jul 2023 at 21:07, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> > > > On Wed, 12 Jul 2023 at 20:05, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Wed, Jul 12, 2023 at 07:59:12PM +0100, Luca Boccassi wrote:
> > > > > > On Wed, 12 Jul 2023 at 17:57, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 12, 2023 at 05:23:18PM +0100, Luca Boccassi wrote:
> > > > > > > > On Wed, 12 Jul 2023 at 16:43, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Jul 12, 2023 at 03:06:46PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > > > On Wed, Jul 12, 2023 at 03:28:40PM +0200, Borislav Petkov wrote:
> > > > > > > > > > > On Wed, Jul 12, 2023 at 01:48:45PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > > > > > That doesn't make it useless, as the 3rd/4th/5th fields in the SBAT
> > > > > > > > > > > > file are just human targetted metadata. The validation process just
> > > > > > > > > > > > works off the 1st/2nd field.
> > > > > > > > > > >
> > > > > > > > > > > It's a good thing I asked - feels like I'm just scratching the surface
> > > > > > > > > > > on what this thing actually is and the commit message is not explaining
> > > > > > > > > > > any of that.
> > > > > > > > > > >
> > > > > > > > > > > First, second field, that's what, "linux,1"?
> > > > > > > > > >
> > > > > > > > > > Each sbat CSV file line has following fields:
> > > > > > > > > >
> > > > > > > > > >   component_name: the name we're comparing
> > > > > > > > > >   component_generation: the generation number for the comparison
> > > > > > > > > >   vendor_name: human readable vendor name
> > > > > > > > > >   vendor_package_name: human readable package name
> > > > > > > > > >   vendor_version: human readable package version (maybe machine parseable too, not specified here)
> > > > > > > > > >   vendor_url: url to look stuff up, contact, whatever.
> > > > > > > > > >
> > > > > > > > > > So 'linux' is 'component_name' and '1' is component_generation
> > > > > > > > > >
> > > > > > > > > > > > From a functional POV, it doesn't have to be unique identified,
> > > > > > > > > > > > as it is just a human targetted metadata field. A friendly git
> > > > > > > > > > > > version as from 'git describe' is more appropriate than a build
> > > > > > > > > > > > ID sha.
> > > > > > > > > > >
> > > > > > > > > > > So can you explain what exactly that version is supposed to describe?
> > > > > > > > > > > Exact kernel sources the kernel was built from? Or a random, increasing
> > > > > > > > > > > number which tools can use to mark as bad?
> > > > > > > > > >
> > > > > > > > > > AFAICT beyond being "human readable package version", it is a fairly
> > > > > > > > > > arbitrary decision. A release version number for formal releases, or
> > > > > > > > > > a 'git describe' version string for git snapshots both satisfy the
> > > > > > > > > > versioning requirement IMHO.
> > > > > > > > > >
> > > > > > > > > > > How do you prevent people from binary-editing that section? Secure boot
> > > > > > > > > > > does that because that changes the signed kernel image?
> > > > > > > > > >
> > > > > > > > > > The PE files are signed by the vendor who builds them, using their
> > > > > > > > > > SecureBoot signing key. The data covered by the signature includes
> > > > > > > > > > the '.sbat' section.
> > > > > > > > > >
> > > > > > > > > > IOW, if you binary edit the section, the SecureBoot signature
> > > > > > > > > > verification fails and the kernel won't be booted.
> > > > > > > > > >
> > > > > > > > > > > > > And then why does it have to be a separate section? All those
> > > > > > > > > > > > > requirements need to be written down.
> > > > > > > > > > >
> > > > > > > > > > > You missed this question.
> > > > > > > > > >
> > > > > > > > > > That's simply what the spec defines as the approach.
> > > > > > > > > >
> > > > > > > > > > The PE file format used by EFI applications has multiple
> > > > > > > > > > sections and the spec has declare that the '.sbat' section
> > > > > > > > > > is where this data shall live.
> > > > > > > > > >
> > > > > > > > > > > > The first line just identifies the file format and should
> > > > > > > > > > > > never change:
> > > > > > > > > > > >
> > > > > > > > > > > >   sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > > > > > > > > > >
> > > > > > > > > > > Why do you even need it then?
> > > > > > > > > >
> > > > > > > > > > First it identifies the data format, and second if a
> > > > > > > > > > problem is ever discovered with the  SBAT concept,
> > > > > > > > > > a fixed approach can be indicated by changing to
> > > > > > > > > > 'sbat,2,.....' and thus have the effect of revoking
> > > > > > > > > > use of any binaries which declare the 'sbat,1,....'
> > > > > > > > > > version. Pretty unlikely this will happen, but a useful
> > > > > > > > > > backup plan/safety net.
> > > > > > > > > >
> > > > > > > > > > > > The second line identifies the kernel generation
> > > > > > > > > > > >
> > > > > > > > > > > >   linux,1,The Linux Developers,linux,6.5.0-rc1,https://linux.org
> > > > > > > > > > > >
> > > > > > > > > > > > The first field 'linux' should never change once decided upon, as it is
> > > > > > > > > > > > the name of the upstream project's EFI component - in this case the
> > > > > > > > > > > > linux kernel.
> > > > > > > > > > > >
> > > > > > > > > > > > The second field '1' is the most important one, as it is the mechanism
> > > > > > > > > > > > through which revokation takes places, and the only one a human upstream
> > > > > > > > > > > > maintainer should manually change.
> > > > > > > > > > >
> > > > > > > > > > > Hold on, how often are those things going to change? And who's going to
> > > > > > > > > > > change them? I sure hope we won't start getting patches constantly
> > > > > > > > > > > updating those numbers?
> > > > > > > > > >
> > > > > > > > > > It is hard to predict the future, but my gut feeling is very infrequently.
> > > > > > > > >
> > > > > > > > > Have you looked at the past as proof of this?
> > > > > > > >
> > > > > > > > I can't quite think of relevant bugs, in the recent past. Are you
> > > > > > > > aware of past instances of kernel module signature verification being
> > > > > > > > broken? Or userspace being allowed to do arbitrary kernel memory
> > > > > > > > manipulation before ExitBootServices?
> > > > > > >
> > > > > > > Yes.
> > > > > >
> > > > > > Then you already know the answer w.r.t. frequency
> > > > >
> > > > > I have a clue, yes.  But given that others do not that are proposing
> > > > > this, that's quite worrying.
> > > >
> > > > Not really, as that's not the purpose. As the documentation clearly
> > > > states, the purpose is to have a revocation mechanism that won't
> > > > exhaust nvram space.
> > >
> > > How do you know that the list of issues will not exhaust it, if you
> > > don't know how many issues are found?
> > >
> > > Take the time and look over the past 10 years and get an idea of what
> > > you are dealing with here please.
> > >
> > > Also note that "single identifiers for individual issues" do NOT work
> > > for kernel fixes (and arguably do not work for any other software
> > > project either) as they fail to properly describe things.
> > >
> > > Think about Meltdown, one "identifier" of a CVE, and hundreds of
> > > patches.  What if you happened to not backport one of them?
> > >
> > > Same goes for the issue reported last week or so, tens of fixes, over
> > > multiple stable kernel releases, for one "identifier", how would you
> > > have classified that?
> > >
> > > Anyway, I've been over this loads before, giving whole talks about this,
> > > there's a reason the kernel developers don't mess with CVEs (i.e.
> > > individual identifiers), they fail to work.
> >
> > There is no 'single identifier for individual issues' nor CVE involved
> > here. The purpose of the generation id (which is per EFI component,
> > not per bug) is to let the boot process know whether an EFI component
> > should be accepted or rejected, in a way that doesn't exhaust nvram.
> > Issues are not individually singled out, and there is no direct
> > correlation with CVEs. It doesn't matter how many fixes there are, or
> > how many bugs, if a generation of a component is vulnerable in any way
> > that matters, then it gets denied.
>
> What does "in any way that matters" mean exactly?

It means what it says. If you don't know what matters, then it won't
be you issuing revocations (and that's ok, it won't be me either,
thank goodness).

> And are you treating the whole kernel as an "EFI component" here?

Yes, that's the scope of this problem, again this is about having a
usable alternative to DBX, it concerns signed PE payloads, and the
kernel is one of them, as a single component.

> Who is going to be responsible for determining that this number needs to
> be updated?

Most likely those who understand the problem space - largely the group
of people maintaining the EFI stack, with various inputs, I imagine.
That's how it currently works for various bootloaders.

> How are they going to determine this?

Again, very coarsely: does the current generation allow a secure boot
bypass -> revoked, else -> no change

> What is their response time?
>
> Who will they be submitting the patch to this string in order to have it
> change?

A bit too soon for exact details on processes given where we are, I think.

> And how is any of this going to interact with stable kernel releases,
> long term kernel releases and end-of-life kernel releases?

As above: does the current generation allow a secure boot bypass ->
revoked, else -> no change

> How long will this feature have to be maintained?

Until something else supplants EFI, I'd imagine

> > The only thing that matters is, "if we had infinite space in DBX and
> > sensible ways to service it and nvram didn't wear down, would we
> > blocklist this component version" - if the answer is no, then nothing
> > happens. If the answer is yes, then the counter goes up.
>
> I suggest you all take a look at the past 10 years of kernel releases
> and changes (to pick a simple number) and determine what the number
> would be now if you were to start counting then.  Is it 10?  100?
> 10000?  What do you think it will be in the next 40 years?

What do you think that would look like if it was all individual hashes
blocklisted in DBX instead? Because this is what we are talking about.
And, for the nth time, this is not about identifying individual bugs.
You do what, 3 releases a year? So 10 years time 3, then assuming
every single release you have made is completely and hopelessly broken
in different ways, but each is only discovered one at a time exactly
once per release, then the generation counter would be 30. That's your
absolutely worst case scenario. Now try to think about how hash
entries we'd need in DBX for the exact same worst case scenario, and
the reason SBAT has been implemented should become very obvious, very
quickly.

> We have a plethora of kernel changes in our history to learn from here,
> please do so and show how this will affect us going forward based on our
> past, otherwise we have no way of knowing how any of this is going to
> work.

I am not aware of anything similar enough, but please do point those
out if you are.
  

On Wed, 12 Jul 2023 at 22:22, Willy Tarreau <w@1wt.eu> wrote:
>
> Hello,
>
> On Wed, Jul 12, 2023 at 09:41:23PM +0100, Luca Boccassi wrote:
> > > Also note that "single identifiers for individual issues" do NOT work
> > > for kernel fixes (and arguably do not work for any other software
> > > project either) as they fail to properly describe things.
> > >
> > > Think about Meltdown, one "identifier" of a CVE, and hundreds of
> > > patches.  What if you happened to not backport one of them?
> > >
> > > Same goes for the issue reported last week or so, tens of fixes, over
> > > multiple stable kernel releases, for one "identifier", how would you
> > > have classified that?
> > >
> > > Anyway, I've been over this loads before, giving whole talks about this,
> > > there's a reason the kernel developers don't mess with CVEs (i.e.
> > > individual identifiers), they fail to work.
> >
> > There is no 'single identifier for individual issues' nor CVE involved
> > here. The purpose of the generation id (which is per EFI component,
> > not per bug) is to let the boot process know whether an EFI component
> > should be accepted or rejected, in a way that doesn't exhaust nvram.
> > Issues are not individually singled out, and there is no direct
> > correlation with CVEs. It doesn't matter how many fixes there are, or
> > how many bugs, if a generation of a component is vulnerable in any way
> > that matters, then it gets denied.
>
> I refrained from chiming in but I'm really reading shocking stuff here,
> so please let me make a few comments based on some old experience.
>
> Several times in this thread you seemed to imply that there is "someone" or
> "something" that knows whether or not a kernel is absolutely vulnerable
> or absolutely trustable regarding a certain bug, when developers
> themselves only have an estimate about it, whose probability quickly
> fades away with the depth of backports.

There is no such implication. This is about _known_ good state,
nothing absolute about that.

> When I was in charge of extended 2.6.32 many years ago, the Debian kernel
> team helped me by occasionally sending me series of backports of fixes
> for issues I had missed, and fixes for backports I had failed. That's the
> principle of maintenance: adding incremental fixes that make the whole
> code better.
>
> With your process (OK you said it's not yours, but then why adopt it when
> it doesn't match the workflow of the software it tries to adapt to), how
> would we proceed ? "Let's bump this ID now that the new 2.6.32.233 has
> everything fixed". Or rather "let's *not* bump it because nobody knows
> how to backport this other stuff that's blocking the ID increment". Then
> once finally bumped, one month later we figure that the fixes were still
> incorrect due to important differences in the older branches, and have
> to be fixed again, so according to what I understand, we must then
> immediately revoke the current ID, that is also shared by upstream and
> all correctly fixed maintenance branches, and have to emit a new one
> for all branches at once even if the code didn't change, just because
> myself incompetent stable maintainer of the week-end failed to fix
> something non-obvious at once ? If so, I'm sorry but this is non-sense.
> There must be another approach to this or it was designed by someone
> having never met a bug in person!

The other approach is fine-grained revocations, but as already
explained that's the status quo and demonstrably cannot work for this
problem. Coarse-grained revocations have some drawbacks, and yes if
you screw up hard enough it might need a re-roll, and if the screw up
is really bad and in an upstream component, then everyone gets a
do-over. Though luck! Screw ups happen, but they are not the end of
the world. Guess what, that happened in Debian - the downstream Grub
generation id was bumped but due to tooling issues the actual binaries
did not have the required patches applied, so another bump was needed
immediately after. I can confirm that the sky did not fall as a
consequence of that. Besides, the vast majority of the work involved
here is with the people doing tracking and coordination, not with
kernel developers, that's the good news for you.

You could devise a scheme, still allowed by the protocol, where each
branch gets its own component name, so they all have separate
generation ids. Here's one of the problems with that: instead of being
(for all intents and purposes) fixed in size, the revocation list
would instead grow by (number of releases) * (number of distributions)
lines every year, forever. It would also require a lot more
coordination and tracking work. Is it possible? Yes. Is it worth it
just to answer a strawman case? No.

> What I'm also wondering is, if in the end it turns out that only the
> distro has the skills to decide which kernel version is fixed and which
> one isn't (after all, it's the distro who chooses the config and the
> compiler, both are as much involved in bugs as the code itself), then
> why not make sort of a wrapper or an envelope around an existing kernel
> image, which provides this ID that the distro can freely choose, then
> transfer the control to the embedded kernel image ? This might give
> the distro the freedom to proceed as it wants with no cross-dependency
> on kernel branches.

The issue there is tracking - revocations are global, not per-distro.
So you need to ensure that the upstream component generation id is the
same everywhere. What's the best way to ensure this coherency, if not
by storing it in the upstream component tree directly? Of course it
can be patched downstream, but that imposes a lot of busywork on
everyone since they'll need out-of-band management. While if you don't
care about security, secure boot and/or sbat upstream, it costs
nothing to have it, apart from applying patches when they are sent.

> > > Pointing to an external document that is thousands of lines long,
> > > talking about bootloaders, is NOT a good way to get people to want to
> > > accept a kernel patch :)
> >
> > Then how about just asking for that? "Hello submitter, please send a
> > v2 with a detailed summary of the problem being solved for those of us
> > who are not familiar with it, thank you"
>
> Probably that there was a problem with process in the first place by
> which someone asks some maintainers to accept to merge, maintain and
> become responsible for breaking changes they disagree with, without
> having even being presented to them before being developed ?

I don't think that's what [RFC] means.
  

On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > There is no 'single identifier for individual issues' nor CVE involved
> > > here. The purpose of the generation id (which is per EFI component,
> > > not per bug) is to let the boot process know whether an EFI component
> > > should be accepted or rejected, in a way that doesn't exhaust nvram.
> > > Issues are not individually singled out, and there is no direct
> > > correlation with CVEs. It doesn't matter how many fixes there are, or
> > > how many bugs, if a generation of a component is vulnerable in any way
> > > that matters, then it gets denied.
> >
> > What does "in any way that matters" mean exactly?
> 
> It means what it says. If you don't know what matters, then it won't
> be you issuing revocations (and that's ok, it won't be me either,
> thank goodness).

Then who will it be?

And we need to know exactly what this means before we can properly even
evaluate this patch, to think otherwise is odd.

> > And are you treating the whole kernel as an "EFI component" here?
> 
> Yes, that's the scope of this problem, again this is about having a
> usable alternative to DBX, it concerns signed PE payloads, and the
> kernel is one of them, as a single component.

Ok, a big component :)

> > Who is going to be responsible for determining that this number needs to
> > be updated?
> 
> Most likely those who understand the problem space - largely the group
> of people maintaining the EFI stack, with various inputs, I imagine.
> That's how it currently works for various bootloaders.

We need specifics and to have people agree to do this, otherwise, again,
this patch is useless.

> > How are they going to determine this?
> 
> Again, very coarsely: does the current generation allow a secure boot
> bypass -> revoked, else -> no change

And how are you going to do that testing?  Who is going to do that?
Does it happen today?

> > What is their response time?
> >
> > Who will they be submitting the patch to this string in order to have it
> > change?
> 
> A bit too soon for exact details on processes given where we are, I think.

Not at all, this is a proposal for a "security flag" for the kernel,
getting this all decided now is the only correct way to determine if
this is actually something that can work properly.

To just go "we are going to randomly add a number that will sometimes be
incremented in the future to determine the buggyness of the kernel
without saying who will control this, or how it will be done" is crazy.

Would other operating systems or projects accept such a change without
this information?

Would you take this patch if you were responsible for kernel releases?

> > And how is any of this going to interact with stable kernel releases,
> > long term kernel releases and end-of-life kernel releases?
> 
> As above: does the current generation allow a secure boot bypass ->
> revoked, else -> no change

For all stable releases?

> > How long will this feature have to be maintained?
> 
> Until something else supplants EFI, I'd imagine

So 40+ years, great, who is going to fund that?

> > > The only thing that matters is, "if we had infinite space in DBX and
> > > sensible ways to service it and nvram didn't wear down, would we
> > > blocklist this component version" - if the answer is no, then nothing
> > > happens. If the answer is yes, then the counter goes up.
> >
> > I suggest you all take a look at the past 10 years of kernel releases
> > and changes (to pick a simple number) and determine what the number
> > would be now if you were to start counting then.  Is it 10?  100?
> > 10000?  What do you think it will be in the next 40 years?
> 
> What do you think that would look like if it was all individual hashes
> blocklisted in DBX instead? Because this is what we are talking about.
> And, for the nth time, this is not about identifying individual bugs.
> You do what, 3 releases a year? So 10 years time 3,

I do a release or two a week across multiple stable kernel versions.
For you to not notice that means that either the process is working
really well, or that this type of function does not match how we do
development and releases at all.

> then assuming
> every single release you have made is completely and hopelessly broken
> in different ways, but each is only discovered one at a time exactly
> once per release, then the generation counter would be 30. That's your
> absolutely worst case scenario. Now try to think about how hash
> entries we'd need in DBX for the exact same worst case scenario, and
> the reason SBAT has been implemented should become very obvious, very
> quickly.

I'm not saying "individual hashes" anymore, sure, I'll give you your one
number, but even then, I don't see how it makes any sense at all in our
current ecosystem of releases.

So I need to see this documented very very well to even be able to
consider it.

> > We have a plethora of kernel changes in our history to learn from here,
> > please do so and show how this will affect us going forward based on our
> > past, otherwise we have no way of knowing how any of this is going to
> > work.
> 
> I am not aware of anything similar enough, but please do point those
> out if you are.

Audit our past history and document when the number would have changed
please.

thanks,

greg k-h
  

Greg KH <gregkh@linuxfoundation.org> writes:

> 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.
>> 
>> Right now an UKI is built with a .sbat section containing the
>> systemd-stub sbat string (upstream + vendor), we would like to add
>> also a per-component specific string (ie vmlinux has its own sbat,
>> again upstream + vendor, each signed add-on its own and so on).
>> In this way, if a specific kernel version has an issue, we can revoke
>> it without compromising all other UKIs that are using a different
>> kernel with the same stub/initrd/something else.
>> 
>> Issues with this patch:
>> * the string is added in a file but it is never deleted
>> * if the code is not modified but make is issued again, objcopy will
>>   be called again and will fail because .sbat exists already, making
>>   compilation fail
>> * minor display issue: objcopy command is printed in the make logs
>> 
>> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>> ---
>>  arch/x86/boot/Makefile | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>> index 9e38ffaadb5d..6982a50ba0c0 100644
>> --- a/arch/x86/boot/Makefile
>> +++ b/arch/x86/boot/Makefile
>> @@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
>>  
>>  $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
>>  	$(call if_changed,image)
>> +	@$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat
>> +	@$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat;
>
> Who controls "linux.org"?  Why are you thinking they have anything to do
> with kernel development?
>
> This shows a huge lack of understanding of loads of things, please go
> get other experienced Red Hat developers to sign off on the next version
> of your patch before you ask the community to review it.

FWIW,

this was an RFC to answer a fairly straitforward question: is upstream
Linux interested in / is a suitable place for having SBAT revocation
mechanism or not. We can, of course, iron out the details whether it
should be "linux.org"/"linux.com"/"lore.kernel.org/lkml/" or
"linux.onion" and where to put objcopy call, whether to silence its
output or not but these are rather implemntation details. I don't
particularly see why anyone would need to get additional sign-offs to
just ask a question (which I don actually think was asked before!) and
IMO an RFC/patch is usually the best way to do so.

Following the discussion, it seems that at least x86 maintainer[s] are
opposed to the very idea of having SBAT revocation mechanism integrated
upstream because it's hard to meaningfully define what epoch is. This is
OK (which doesn't mean we all agree to that) but as there's real need to
revoke "bad" (in UEFI SecureBoot sense) kernels, distros will likely
come up with their custom, downstream only ways to do it. Without an
upstream reference, however, they may come up with very differently
looking SBAT sections, this may or may not be problematic in the future,
who knows.
  

On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:

> this was an RFC to answer a fairly straitforward question: is upstream
> Linux interested in / is a suitable place for having SBAT revocation
> mechanism or not.

If only it would have actually had that question in :/ But then we
would've still had the whole WTF is a SBAT(SHIT) and why should we care
discussion.

Fundamentally, I don't think upstream can care; upstream doesn't have a
signing key, it will never be revoked, bumping the upstream number
doesn't make sense -- ever.

> We can, of course, iron out the details whether it
> should be "linux.org"/"linux.com"/"lore.kernel.org/lkml/" or
> "linux.onion" and where to put objcopy call, whether to silence its

Seriously ?!? kernel.org is the only sane option here, none of the
others make any damn sense.

> output or not but these are rather implemntation details. I don't
> particularly see why anyone would need to get additional sign-offs to
> just ask a question (which I don actually think was asked before!) and
> IMO an RFC/patch is usually the best way to do so.

But there wasn't no question, was there. There isn't a single '?' in
that thing. And it starts of with random implementation detail blabber.

> Following the discussion, it seems that at least x86 maintainer[s] are
> opposed to the very idea of having SBAT revocation mechanism integrated
> upstream because it's hard to meaningfully define what epoch is. This is
> OK (which doesn't mean we all agree to that) but as there's real need to
> revoke "bad" (in UEFI SecureBoot sense) kernels, distros will likely
> come up with their custom, downstream only ways to do it. Without an
> upstream reference, however, they may come up with very differently
> looking SBAT sections, this may or may not be problematic in the future,
> who knows.

Well, if the various stake-holders can't even agree on things, things
are very bleak indeed.

I just don't see why upstream would want/need to carry any of this
because it has no meaning to us, we don't play in the secure boot pen,
not haz key etc.. (for good reasons IIUC).
  

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.

Therefore, I don't think it makes sense for the upstream kernel source
to carry a revocation index. It is ultimately up to the owner of the
signing key to decide which value gets signed along with the image, and
this is fundamentally part of the configure/build/release workflow.  No
distro builds and signs the upstream sources unmodified, so each signed
release is a fork anyway, making a upstream revocation index almost
meaningless. Also, while backporting revocation index bumps to -stable
should not result in any issues, I don't think the associated
bookkeeping belongs in the hands of the stable tree maintainers. 

> 
> Right now an UKI is built with a .sbat section containing the
> systemd-stub sbat string (upstream + vendor), we would like to add
> also a per-component specific string (ie vmlinux has its own sbat,
> again upstream + vendor, each signed add-on its own and so on).
> In this way, if a specific kernel version has an issue, we can revoke
> it without compromising all other UKIs that are using a different
> kernel with the same stub/initrd/something else.
> 

Whoever builds *and signs* this kernel should be managing the revocation
metadata. Given that each vendor will have its own linux.<vendor>
revocation counter anyway, why is it necessary to have an upstream one
as well?

> Issues with this patch:
> * the string is added in a file but it is never deleted
> * if the code is not modified but make is issued again, objcopy will
>   be called again and will fail because .sbat exists already, making
>   compilation fail
> * minor display issue: objcopy command is printed in the make logs
> 
> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
> ---
>  arch/x86/boot/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
> index 9e38ffaadb5d..6982a50ba0c0 100644
> --- a/arch/x86/boot/Makefile
> +++ b/arch/x86/boot/Makefile
> @@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
>  
>  $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
>  	$(call if_changed,image)
> +	@$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat
> +	@$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat;
> +	$(OBJCOPY) --set-section-alignment '.sbat=512' --add-section .sbat=linux.sbat $@;
>  	@$(kecho) 'Kernel: $@ is ready' ' (#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
>  
>  OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
> -- 
> 2.39.1
>
  

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

On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:
> FWIW,
> 
> this was an RFC to answer a fairly straitforward question: is upstream
> Linux interested in / is a suitable place for having SBAT revocation
> mechanism or not.

As Peter said, there was no questions in this patch, so how were we to
know that this was something that you all were asking?

Also, you need to provide lots of information in the changelog itself
about whatever "SBAT" is, as that is not anything that anyone should be
forced to look up (links go dead over time.)

> We can, of course, iron out the details whether it
> should be "linux.org"/"linux.com"/"lore.kernel.org/lkml/" or
> "linux.onion" and where to put objcopy call, whether to silence its
> output or not but these are rather implemntation details.

It's a sign that this change was not thought out at all, as the
follow-up questions, and lack of answers, showed in detail.

> I don't
> particularly see why anyone would need to get additional sign-offs to
> just ask a question (which I don actually think was asked before!) and
> IMO an RFC/patch is usually the best way to do so.

Again, no questions were asked.

And when I asked questions, no one knowledgable answered them (hint, we
release more than 3 kernels a year...)

> Following the discussion, it seems that at least x86 maintainer[s] are
> opposed to the very idea of having SBAT revocation mechanism integrated
> upstream because it's hard to meaningfully define what epoch is.

You all did not even consider how this might work with our existing
release process OR how we handle security fixes today.  In fact, you
totally ignored it, and didn't even do some basic research into our past
history to see how this new feature would actually work had it been
present 10 years ago.

You need to convince us "of course we would be foolish to not accept
this patch because you properly researched it, documented it, and tied
it all into our existing release and security and other policies and
proceedures".  But none of that happened here, so we would be foolish to
ACCEPT this patch, right?

Turn it around, what would you do if you got this patch in your inbox to
review and you were responsible for doing kernel releases and security
fixes?

> This is
> OK (which doesn't mean we all agree to that) but as there's real need to
> revoke "bad" (in UEFI SecureBoot sense) kernels, distros will likely
> come up with their custom, downstream only ways to do it. Without an
> upstream reference, however, they may come up with very differently
> looking SBAT sections, this may or may not be problematic in the future,
> who knows.

You all haven't even properly defined what "bad" means!  Or who would
determine it!  Or how it would work with our decades-old release process
that has evolved over time.  Or how it would tie into our existing
security fixing policies and processes.

In fact, it is a complete end-run around all of that, with only a "trust
us, we will update the number when we want to" statement.  Also
without even defining who "us" is.

And if a security policy doesn't even define who is going to be
determining the security policy at all, is it a security policy you want
in Linux?

thanks,

greg k-h
  

Greg KH <gregkh@linuxfoundation.org> writes:

> On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:
>> FWIW,
>> 
>> this was an RFC to answer a fairly straitforward question: is upstream
>> Linux interested in / is a suitable place for having SBAT revocation
>> mechanism or not.
>
> As Peter said, there was no questions in this patch, so how were we to
> know that this was something that you all were asking?
>
> Also, you need to provide lots of information in the changelog itself
> about whatever "SBAT" is, as that is not anything that anyone should be
> forced to look up (links go dead over time.)
>

Very valid point, "SBAT" is certainly not something very standard. The
RFC should've contained the description and a clear question with a
question mark at the end.

>> We can, of course, iron out the details whether it
>> should be "linux.org"/"linux.com"/"lore.kernel.org/lkml/" or
>> "linux.onion" and where to put objcopy call, whether to silence its
>> output or not but these are rather implemntation details.
>
> It's a sign that this change was not thought out at all, as the
> follow-up questions, and lack of answers, showed in detail.

...

>
>> I don't
>> particularly see why anyone would need to get additional sign-offs to
>> just ask a question (which I don actually think was asked before!) and
>> IMO an RFC/patch is usually the best way to do so.
>
> Again, no questions were asked.
>
> And when I asked questions, no one knowledgable answered them (hint, we
> release more than 3 kernels a year...)
>

I think that getting these questions was actually the main reason to
send out the RFC. (Personally, I don't think that stable@ is an
insurmountable problem with an epoch-based revocation mechamism as we
can e.g. switch module name from "linux" to e.g. "linux-stable-5.14"
when screating a stable branch or do something like that but that's not
the main/only problem we see here).

>> Following the discussion, it seems that at least x86 maintainer[s] are
>> opposed to the very idea of having SBAT revocation mechanism integrated
>> upstream because it's hard to meaningfully define what epoch is.
>
> You all did not even consider how this might work with our existing
> release process OR how we handle security fixes today.  In fact, you
> totally ignored it, and didn't even do some basic research into our past
> history to see how this new feature would actually work had it been
> present 10 years ago.
>
> You need to convince us "of course we would be foolish to not accept
> this patch because you properly researched it, documented it, and tied
> it all into our existing release and security and other policies and
> proceedures".  But none of that happened here, so we would be foolish to
> ACCEPT this patch, right?
>
> Turn it around, what would you do if you got this patch in your inbox to
> review and you were responsible for doing kernel releases and security
> fixes?
>

I replied to the thread not to defend the idea as after the discussion
it is clear there's a lot to take into consideration if anyone decides
to pursue the SBAT idea ever again (and the discussion is now well
preserved in the archive!). I replied to disagree with "get sign-offs
from senior people before sending RFCs" idea, I believe that asking
questions by sending a not-fully-ready patch as "RFC" should not be
discouraged. 

>> This is
>> OK (which doesn't mean we all agree to that) but as there's real need to
>> revoke "bad" (in UEFI SecureBoot sense) kernels, distros will likely
>> come up with their custom, downstream only ways to do it. Without an
>> upstream reference, however, they may come up with very differently
>> looking SBAT sections, this may or may not be problematic in the future,
>> who knows.
>
> You all haven't even properly defined what "bad" means!  Or who would
> determine it!  Or how it would work with our decades-old release process
> that has evolved over time.  Or how it would tie into our existing
> security fixing policies and processes.
>
> In fact, it is a complete end-run around all of that, with only a "trust
> us, we will update the number when we want to" statement.  Also
> without even defining who "us" is.
>
> And if a security policy doesn't even define who is going to be
> determining the security policy at all, is it a security policy you want
> in Linux?

All these are very valid questions, of course, and in no way I'm trying
to say that they were answered in the RFC or in the following
discussion. The only thing I'm saying is that the upstream discussion
itself is valuable and should not be discouraged.
  

On Thu, Jul 13, 2023 at 05:51:57PM +0200, Vitaly Kuznetsov wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:
> >> I don't
> >> particularly see why anyone would need to get additional sign-offs to
> >> just ask a question (which I don actually think was asked before!) and
> >> IMO an RFC/patch is usually the best way to do so.
> >
> > Again, no questions were asked.
> >
> > And when I asked questions, no one knowledgable answered them (hint, we
> > release more than 3 kernels a year...)
> >
> 
> I think that getting these questions was actually the main reason to
> send out the RFC. (Personally, I don't think that stable@ is an
> insurmountable problem with an epoch-based revocation mechamism as we
> can e.g. switch module name from "linux" to e.g. "linux-stable-5.14"
> when screating a stable branch or do something like that but that's not
> the main/only problem we see here).

There was no "questions" asked about this RFC, so what should we respond
with except with what we did, "No way this is acceptable, as this was
not thought through at all"?

> > Turn it around, what would you do if you got this patch in your inbox to
> > review and you were responsible for doing kernel releases and security
> > fixes?
> >
> 
> I replied to the thread not to defend the idea as after the discussion
> it is clear there's a lot to take into consideration if anyone decides
> to pursue the SBAT idea ever again (and the discussion is now well
> preserved in the archive!). I replied to disagree with "get sign-offs
> from senior people before sending RFCs" idea, I believe that asking
> questions by sending a not-fully-ready patch as "RFC" should not be
> discouraged. 

On the contrary, this is EXACTLY what needs to happen here.

This developer (I'm not picking on them at all, it's not their fault),
should be taking advantage of the resources of their company when
dealing with core, critical, functionality of the kernel.

To just "throw them at the wolves" like Red Hat did, is a total
disservice to them, AND it wastes the time and resources of the
community, as it is not our job to train and teach them, it is the job
of the senior people at your company to do so.

We have a non-zero number of companies that right now who are in the
"penalty box" because their developers have had a history of throwing
crud over the wall, or having inexperienced developers submit changes
that are obviously wrong, which waste the time and energy of the kernel
community.  For companies that do this, we have instituted the
requirement that they get review and acceptance of kernel changes from
the experienced developers within the company BEFORE submitting their
changes to the community, for the basic fact that this actually saves
EVERYONE time and energy.

It allows the developer to grow and learn more quickly, it saves the
energy and time of the reviewers (which is our most valuable resource
right now) and it provides a solid path forward on the corporate ladder
of using mentors well, and lifting up your own employees.

I don't think you want us to put Red Hat into this type of policy at
this point in time, but if you all keep insisting that you can just "let
loose" inexperienced developers who wish to change the core
functionality of how we operate, that can easily change.

Remember, this proposed patch directly affects how the kernel is
released, how the security team works, and how the security of Linux is
viewed by the world.  Why would you NOT want your experienced developers
to review such a thing first?  To not want that, means that Red Hat just
doesn't care about their developers, nor the community, which I sure
hope is not the case.

So again, yes, I am INSISTING that the next version of this change be
properly reviewed, vetted, and signed-off-by, by the senior kernel
developers at your company BEFORE you submit it again for review by
anyone in the community.  Only that way can I hope that it will be
something that actually takes into account all of the questions we have
already had for this proposed 2 line change.

Funnily, I think this proposed patch takes the dubious record for "most
innocuous looking patch that will directly affect the development
procedures for the most people", an outstanding record that I hope never
gets broken :)

thanks,

greg k-h
  

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
  

Am 13/07/2023 um 18:58 schrieb Greg KH:
> On Thu, Jul 13, 2023 at 05:51:57PM +0200, Vitaly Kuznetsov wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>>> On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:
>>>> I don't
>>>> particularly see why anyone would need to get additional sign-offs to
>>>> just ask a question (which I don actually think was asked before!) and
>>>> IMO an RFC/patch is usually the best way to do so.
>>>
>>> Again, no questions were asked.
>>>
>>> And when I asked questions, no one knowledgable answered them (hint, we
>>> release more than 3 kernels a year...)
>>>
>>
>> I think that getting these questions was actually the main reason to
>> send out the RFC. (Personally, I don't think that stable@ is an
>> insurmountable problem with an epoch-based revocation mechamism as we
>> can e.g. switch module name from "linux" to e.g. "linux-stable-5.14"
>> when screating a stable branch or do something like that but that's not
>> the main/only problem we see here).
> 
> There was no "questions" asked about this RFC, so what should we respond
> with except with what we did, "No way this is acceptable, as this was
> not thought through at all"?


As I wrote you privately before, yeah I think there is a
misunderstanding here. I always thought that RFC stands for "hey I don't
know what I am doing, can you help me?". I apologize for the
misunderstanding.
Also other hints were "*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."
and "Issues with this patch:" section.

> 
>>> Turn it around, what would you do if you got this patch in your inbox to
>>> review and you were responsible for doing kernel releases and security
>>> fixes?
>>>
>>
>> I replied to the thread not to defend the idea as after the discussion
>> it is clear there's a lot to take into consideration if anyone decides
>> to pursue the SBAT idea ever again (and the discussion is now well
>> preserved in the archive!). I replied to disagree with "get sign-offs
>> from senior people before sending RFCs" idea, I believe that asking
>> questions by sending a not-fully-ready patch as "RFC" should not be
>> discouraged. 
> 
> On the contrary, this is EXACTLY what needs to happen here.
> 
> This developer (I'm not picking on them at all, it's not their fault),
> should be taking advantage of the resources of their company when
> dealing with core, critical, functionality of the kernel.
> 
> To just "throw them at the wolves" like Red Hat did, is a total
> disservice to them, AND it wastes the time and resources of the
> community, as it is not our job to train and teach them, it is the job
> of the senior people at your company to do so.
> 
> We have a non-zero number of companies that right now who are in the
> "penalty box" because their developers have had a history of throwing
> crud over the wall, or having inexperienced developers submit changes
> that are obviously wrong, which waste the time and energy of the kernel
> community.  For companies that do this, we have instituted the
> requirement that they get review and acceptance of kernel changes from
> the experienced developers within the company BEFORE submitting their
> changes to the community, for the basic fact that this actually saves
> EVERYONE time and energy.
> 
> It allows the developer to grow and learn more quickly, it saves the
> energy and time of the reviewers (which is our most valuable resource
> right now) and it provides a solid path forward on the corporate ladder
> of using mentors well, and lifting up your own employees.
> 
> I don't think you want us to put Red Hat into this type of policy at
> this point in time, but if you all keep insisting that you can just "let
> loose" inexperienced developers who wish to change the core
> functionality of how we operate, that can easily change.

Wow, I was not aware of these policies O.O.
What you say makes sense, but what about developers not working in a
company? Then they are completely ignored?
Otherwise a simple way to trick you is to actually use my gmail address
and you won't ever know that I work for RH.
Is this the policy of the community? If so, is it explained clearly
somewhere? Because I think a lot of people need to be aware of this, not
wait that this mess happens for every company employer submitting a
patch in the kernel.

> 
> Remember, this proposed patch directly affects how the kernel is
> released, how the security team works, and how the security of Linux is
> viewed by the world.  Why would you NOT want your experienced developers
> to review such a thing first?  To not want that, means that Red Hat just
> doesn't care about their developers, nor the community, which I sure
> hope is not the case.
> 
> So again, yes, I am INSISTING that the next version of this change be
> properly reviewed, vetted, and signed-off-by, by the senior kernel
> developers at your company BEFORE you submit it again for review by
> anyone in the community.  Only that way can I hope that it will be
> something that actually takes into account all of the questions we have
> already had for this proposed 2 line change.
> 
> Funnily, I think this proposed patch takes the dubious record for "most
> innocuous looking patch that will directly affect the development
> procedures for the most people", an outstanding record that I hope never
> gets broken :)

Glad to be the one that opened the pandora box for everyone :)

Thank you,
Emanuele
> 
> thanks,
> 
> greg k-h
>
  

On Thu, Jul 13, 2023 at 10:49:31PM +0200, Emanuele Giuseppe Esposito wrote:
> >> I replied to the thread not to defend the idea as after the discussion
> >> it is clear there's a lot to take into consideration if anyone decides
> >> to pursue the SBAT idea ever again (and the discussion is now well
> >> preserved in the archive!). I replied to disagree with "get sign-offs
> >> from senior people before sending RFCs" idea, I believe that asking
> >> questions by sending a not-fully-ready patch as "RFC" should not be
> >> discouraged. 
> > 
> > On the contrary, this is EXACTLY what needs to happen here.
> > 
> > This developer (I'm not picking on them at all, it's not their fault),
> > should be taking advantage of the resources of their company when
> > dealing with core, critical, functionality of the kernel.
> > 
> > To just "throw them at the wolves" like Red Hat did, is a total
> > disservice to them, AND it wastes the time and resources of the
> > community, as it is not our job to train and teach them, it is the job
> > of the senior people at your company to do so.
> > 
> > We have a non-zero number of companies that right now who are in the
> > "penalty box" because their developers have had a history of throwing
> > crud over the wall, or having inexperienced developers submit changes
> > that are obviously wrong, which waste the time and energy of the kernel
> > community.  For companies that do this, we have instituted the
> > requirement that they get review and acceptance of kernel changes from
> > the experienced developers within the company BEFORE submitting their
> > changes to the community, for the basic fact that this actually saves
> > EVERYONE time and energy.
> > 
> > It allows the developer to grow and learn more quickly, it saves the
> > energy and time of the reviewers (which is our most valuable resource
> > right now) and it provides a solid path forward on the corporate ladder
> > of using mentors well, and lifting up your own employees.
> > 
> > I don't think you want us to put Red Hat into this type of policy at
> > this point in time, but if you all keep insisting that you can just "let
> > loose" inexperienced developers who wish to change the core
> > functionality of how we operate, that can easily change.
> 
> Wow, I was not aware of these policies O.O.
> What you say makes sense, but what about developers not working in a
> company? Then they are completely ignored?

Not at all, they are not ignored and are treated as someone who probably
needs help.

> Otherwise a simple way to trick you is to actually use my gmail address
> and you won't ever know that I work for RH.

If RH finds out you are misrepresenting yourself like this, I don't
think it will go over very well :)

Also, we know who almost everyone works for, this isn't a secret.  And
it would turn out to be worse overall for that developer if they were to
attempt that.

Remember, kernel development works on trusting other people.  If someone
looses their trust in you, it's very hard to get it back.

thanks,

greg k-h
  

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.
  

On Thu, 13 Jul 2023 at 14:33, Ard Biesheuvel <ardb@kernel.org> 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.

I appreciate the attempt, but sorry, it's not cool to try and
both-side things here. The original submission was not aggressive,
insulting or in any way out of line, it's clearly marked as an RFC and
the FIRST LINE was:

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

which is as friendly and humble as one can be. And yet, not one, not
two, but three maintainers have decided that the best way to respond
to something like that is to spew bile, toxicity and aggressivity,
which was completely and utterly uncalled for. So, if you want to call
someone out (you should), please direct that towards your fellow
maintainers, who in theory should be setting a good example and
productively directing the discourse, but instead, once again, have
only succeeded in ensuring that the lkml lives up to its fame of being
an open sewer.

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

There is no other solution for the current revision of the spec (and
I'm pretty sure this aspect won't change in future ones either), for
'public' signing it's just Shim and the 3party CA. Of course for
individual/internal/scoped deployment there is self signing, but
that's out of scope of any of this and it couldn't be otherwise, and
that's ok. But it's not some obscure corner case: the default for
every generalist distro that boots on uefi machines is by using Shim.
If there's any use case that matters, it's this one. But even that's
not the main reason it's a good idea to store the generation id here.

> Therefore, I don't think it makes sense for the upstream kernel source
> to carry a revocation index. It is ultimately up to the owner of the
> signing key to decide which value gets signed along with the image, and
> this is fundamentally part of the configure/build/release workflow.  No
> distro builds and signs the upstream sources unmodified, so each signed
> release is a fork anyway, making a upstream revocation index almost
> meaningless. Also, while backporting revocation index bumps to -stable
> should not result in any issues, I don't think the associated
> bookkeeping belongs in the hands of the stable tree maintainers.

The reason it's a good idea to store it here is because otherwise
there would need to be another external "registry" that matches 1:1,
and that is maintained identical everywhere, perfectly in sync,
forever, and any 'new' distro and/or distro maintainer would have to
discover and use that registry, and would be completely oblivious to
it otherwise.

It would be much more work for those actually doing the work, and it
wouldn't make any meaningful differences to those who don't care about
the use case. AFAIK nobody has suggested that it's kernel maintainers
who need to worry about the generation id and do the bookkeeping, if
they don't care. I mean I'm pretty sure every help is welcome, but
that should be it.

The 'owner of the signing key' is not good enough, because there are
many of those - as you know, the kernel is signed by each distro. But
the key here is that the revocation is _global_ (again: global means
it applies to everyone using shim signed by 3rd party CA), so each
distro storing their own id defeats the purpose of that. There is
space in the spec for distro-specific revocations, but that's intended
for distro-specific _additions_, like for example a lot of the
mok/lockdown used to be - thankfully most of that is upstream now, so
it mostly applies to grub these days, which is the most
downstream-patched component in the stack from the point of view of
the boot chain.
  

On Thu, 13 Jul 2023 at 07:09, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > Who is going to be responsible for determining that this number needs to
> > > be updated?
> >
> > Most likely those who understand the problem space - largely the group
> > of people maintaining the EFI stack, with various inputs, I imagine.
> > That's how it currently works for various bootloaders.
>
> We need specifics and to have people agree to do this, otherwise, again,
> this patch is useless.

Not really, as this is about mechanism, not process.

> > > How are they going to determine this?
> >
> > Again, very coarsely: does the current generation allow a secure boot
> > bypass -> revoked, else -> no change
>
> And how are you going to do that testing?  Who is going to do that?
> Does it happen today?

Of course it happens today, it even gets fancy names - black lotus,
boot hole, etc. If you want to know how it happens, read some papers,
join a security team, or a university research group, or some other
place that works in the specific field.

> > > What is their response time?
> > >
> > > Who will they be submitting the patch to this string in order to have it
> > > change?
> >
> > A bit too soon for exact details on processes given where we are, I think.
>
> Not at all, this is a proposal for a "security flag" for the kernel,
> getting this all decided now is the only correct way to determine if
> this is actually something that can work properly.

No, the question here was about mechanism and storage. And it already
works btw, it's just the kernel that's lagging behind, as usual.

> To just go "we are going to randomly add a number that will sometimes be
> incremented in the future to determine the buggyness of the kernel
> without saying who will control this, or how it will be done" is crazy.
>
> Would other operating systems or projects accept such a change without
> this information?
>
> Would you take this patch if you were responsible for kernel releases?

I think you are still missing one tiny bit of information: it is
already used in other projects

$ sudo objcopy -O binary --only-section=.sbat
/boot/efi/EFI/Debian/grubx64.efi /dev/stdout
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,3,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2

> > > And how is any of this going to interact with stable kernel releases,
> > > long term kernel releases and end-of-life kernel releases?
> >
> > As above: does the current generation allow a secure boot bypass ->
> > revoked, else -> no change
>
> For all stable releases?

Doesn't matter how you call it, only if it's signed for the shim+3rd
party CA workflow

> > > How long will this feature have to be maintained?
> >
> > Until something else supplants EFI, I'd imagine
>
> So 40+ years, great, who is going to fund that?

Who funds EFI work?

> > > > The only thing that matters is, "if we had infinite space in DBX and
> > > > sensible ways to service it and nvram didn't wear down, would we
> > > > blocklist this component version" - if the answer is no, then nothing
> > > > happens. If the answer is yes, then the counter goes up.
> > >
> > > I suggest you all take a look at the past 10 years of kernel releases
> > > and changes (to pick a simple number) and determine what the number
> > > would be now if you were to start counting then.  Is it 10?  100?
> > > 10000?  What do you think it will be in the next 40 years?
> >
> > What do you think that would look like if it was all individual hashes
> > blocklisted in DBX instead? Because this is what we are talking about.
> > And, for the nth time, this is not about identifying individual bugs.
> > You do what, 3 releases a year? So 10 years time 3,
>
> I do a release or two a week across multiple stable kernel versions.
> For you to not notice that means that either the process is working
> really well, or that this type of function does not match how we do
> development and releases at all.

Or, third option, that's irrelevant for the case at hand.

> > then assuming
> > every single release you have made is completely and hopelessly broken
> > in different ways, but each is only discovered one at a time exactly
> > once per release, then the generation counter would be 30. That's your
> > absolutely worst case scenario. Now try to think about how hash
> > entries we'd need in DBX for the exact same worst case scenario, and
> > the reason SBAT has been implemented should become very obvious, very
> > quickly.
>
> I'm not saying "individual hashes" anymore, sure, I'll give you your one
> number, but even then, I don't see how it makes any sense at all in our
> current ecosystem of releases.
>
> So I need to see this documented very very well to even be able to
> consider it.

Well then, it's your lucky day! As it is documented, with examples and all:

https://github.com/rhboot/shim/blob/main/SBAT.example.md

the kernel is just one of many consumers of this protocol, so
obviously the documentation for it lives with the protocol owner,
which is Shim.

> > > We have a plethora of kernel changes in our history to learn from here,
> > > please do so and show how this will affect us going forward based on our
> > > past, otherwise we have no way of knowing how any of this is going to
> > > work.
> >
> > I am not aware of anything similar enough, but please do point those
> > out if you are.
>
> Audit our past history and document when the number would have changed
> please.

Sure, where do I send the invoice?
  

Am 14/07/2023 um 00:04 schrieb Greg KH:
> On Thu, Jul 13, 2023 at 10:49:31PM +0200, Emanuele Giuseppe Esposito wrote:
>>>> I replied to the thread not to defend the idea as after the discussion
>>>> it is clear there's a lot to take into consideration if anyone decides
>>>> to pursue the SBAT idea ever again (and the discussion is now well
>>>> preserved in the archive!). I replied to disagree with "get sign-offs
>>>> from senior people before sending RFCs" idea, I believe that asking
>>>> questions by sending a not-fully-ready patch as "RFC" should not be
>>>> discouraged. 
>>>
>>> On the contrary, this is EXACTLY what needs to happen here.
>>>
>>> This developer (I'm not picking on them at all, it's not their fault),
>>> should be taking advantage of the resources of their company when
>>> dealing with core, critical, functionality of the kernel.
>>>
>>> To just "throw them at the wolves" like Red Hat did, is a total
>>> disservice to them, AND it wastes the time and resources of the
>>> community, as it is not our job to train and teach them, it is the job
>>> of the senior people at your company to do so.
>>>
>>> We have a non-zero number of companies that right now who are in the
>>> "penalty box" because their developers have had a history of throwing
>>> crud over the wall, or having inexperienced developers submit changes
>>> that are obviously wrong, which waste the time and energy of the kernel
>>> community.  For companies that do this, we have instituted the
>>> requirement that they get review and acceptance of kernel changes from
>>> the experienced developers within the company BEFORE submitting their
>>> changes to the community, for the basic fact that this actually saves
>>> EVERYONE time and energy.
>>>
>>> It allows the developer to grow and learn more quickly, it saves the
>>> energy and time of the reviewers (which is our most valuable resource
>>> right now) and it provides a solid path forward on the corporate ladder
>>> of using mentors well, and lifting up your own employees.
>>>
>>> I don't think you want us to put Red Hat into this type of policy at
>>> this point in time, but if you all keep insisting that you can just "let
>>> loose" inexperienced developers who wish to change the core
>>> functionality of how we operate, that can easily change.
>>
>> Wow, I was not aware of these policies O.O.
>> What you say makes sense, but what about developers not working in a
>> company? Then they are completely ignored?
> 
> Not at all, they are not ignored and are treated as someone who probably
> needs help.
> 
>> Otherwise a simple way to trick you is to actually use my gmail address
>> and you won't ever know that I work for RH.
> 
> If RH finds out you are misrepresenting yourself like this, I don't
> think it will go over very well :)

By "my gmail address" I mean any potential employee of any company
reading this thread of course. I think after this you'll remember my
name for a while ;) So no way to hide for me. Also my private email
address has my name and surname in it, so it won't be hard to identify me.

Anyways, I think you need to clarify better what you mean with
"inexperienced developers submit changes that are obviously wrong", more
specifically the "obviously wrong" part.
If you refer to the commit message wrongly made, ok you have a point. I
take responsibility on this, it already happened that I wrote non clear
commits and I am working on this. Working on different communities that
have less commit rules and rarely sending stuff to kernel doesn't help
though (my only excuse). If it's that, the issue can be closed here and
I will definitely be more careful in the future, as well as all I work with.

If you refer to the fact that the patch is wrong technically, 1) as I
wrote it is indeed not working properly, I have clearly documented in
the commit message that if you run make twice with this patch it won't
work, and 2) the aim of this patch that we thought was clear with RFC
and "Important:..." was to ask opinions because we don't have experts on
this matter, the technology is new and would like to hear opinions from
outside. You gave the opinion we were looking for, it's just that the
whole thing escalated dramatically because IMHO intentions were
misunderstood and again IMHO the wrong tones and wordings were used.

Thank you,
Emanuele
> 
> Also, we know who almost everyone works for, this isn't a secret.  And
> it would turn out to be worse overall for that developer if they were to
> attempt that.
> 
> Remember, kernel development works on trusting other people.  If someone
> looses their trust in you, it's very hard to get it back.
> 
> thanks,
> 
> greg k-h
>
  

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

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
  

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?
  

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.
  

On Fri, 14 Jul 2023 at 01:13, Luca Boccassi <bluca@debian.org> wrote:
>
> On Thu, 13 Jul 2023 at 14:33, Ard Biesheuvel <ardb@kernel.org> 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.
>
> I appreciate the attempt, but sorry, it's not cool to try and
> both-side things here. The original submission was not aggressive,
> insulting or in any way out of line, it's clearly marked as an RFC and
> the FIRST LINE was:
>
> "*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."
>
> which is as friendly and humble as one can be. And yet, not one, not
> two, but three maintainers have decided that the best way to respond
> to something like that is to spew bile, toxicity and aggressivity,
> which was completely and utterly uncalled for.

I completely agree.

> So, if you want to call
> someone out (you should), please direct that towards your fellow
> maintainers, who in theory should be setting a good example and
> productively directing the discourse, but instead, once again, have
> only succeeded in ensuring that the lkml lives up to its fame of being
> an open sewer.
>

While I understand your frustration, the tone of your replies is not
helping either, so I am directing this to you as well. Let's be the
adults in the room, shall we?

> > 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.
>
> There is no other solution for the current revision of the spec (and
> I'm pretty sure this aspect won't change in future ones either), for
> 'public' signing it's just Shim and the 3party CA. Of course for
> individual/internal/scoped deployment there is self signing, but
> that's out of scope of any of this and it couldn't be otherwise, and
> that's ok. But it's not some obscure corner case: the default for
> every generalist distro that boots on uefi machines is by using Shim.
> If there's any use case that matters, it's this one. But even that's
> not the main reason it's a good idea to store the generation id here.
>
> > Therefore, I don't think it makes sense for the upstream kernel source
> > to carry a revocation index. It is ultimately up to the owner of the
> > signing key to decide which value gets signed along with the image, and
> > this is fundamentally part of the configure/build/release workflow.  No
> > distro builds and signs the upstream sources unmodified, so each signed
> > release is a fork anyway, making a upstream revocation index almost
> > meaningless. Also, while backporting revocation index bumps to -stable
> > should not result in any issues, I don't think the associated
> > bookkeeping belongs in the hands of the stable tree maintainers.
>
> The reason it's a good idea to store it here is because otherwise
> there would need to be another external "registry" that matches 1:1,
> and that is maintained identical everywhere, perfectly in sync,
> forever, and any 'new' distro and/or distro maintainer would have to
> discover and use that registry, and would be completely oblivious to
> it otherwise.
>

But why does there need to be a single, shared upstream 'generation
id' in the first place? The upstream is just a bunch of source files
that can be built in a million different ways, including for different
architectures that can all boot via EFI.

To me, being able to revoke a signed release by means of a revocation
counter makes perfect sense. What doesn't make sense is the need for
two or more counters to describe the same entity.

> It would be much more work for those actually doing the work, and it
> wouldn't make any meaningful differences to those who don't care about
> the use case. AFAIK nobody has suggested that it's kernel maintainers
> who need to worry about the generation id and do the bookkeeping, if
> they don't care. I mean I'm pretty sure every help is welcome, but
> that should be it.
>
> The 'owner of the signing key' is not good enough, because there are
> many of those - as you know, the kernel is signed by each distro. But
> the key here is that the revocation is _global_ (again: global means
> it applies to everyone using shim signed by 3rd party CA), so each
> distro storing their own id defeats the purpose of that.

But this kernel is never signed by the key that signs shim. Each
distro has its own set of keys to sign releases of their kernel forks.
So what is the relevance of shim being signed by the MS 3rd party UEFI
CA certificate here?

In fact, it would make me *much* happier if shim was not mentioned at
all, and someone could explain why this facility has value if you are
not using shim in the first place. I'd much prefer to, e.g., have a
Debian top-level cert in KEK, so it could store its per-release
signing keys in db, and revoke those (if needed) via dbx. Could SBAT
play a role in such a context as well?

shim and its GRUB integration have been an endless source of problems
with EFI boot on non-x86 architectures, so arguing that something is
needed by shim is not very convincing to me, and generally implies
that the distros should be owning it instead.

> There is
> space in the spec for distro-specific revocations, but that's intended
> for distro-specific _additions_, like for example a lot of the
> mok/lockdown used to be - thankfully most of that is upstream now, so
> it mostly applies to grub these days, which is the most
> downstream-patched component in the stack from the point of view of
> the boot chain.

I think those distro-specific revocation counters are the right place for this.
  

On Fri, Jul 14, 2023 at 11:33:44AM +0200, Ard Biesheuvel wrote:
> On Fri, 14 Jul 2023 at 01:13, Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Thu, 13 Jul 2023 at 14:33, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > Therefore, I don't think it makes sense for the upstream kernel source
> > > to carry a revocation index. It is ultimately up to the owner of the
> > > signing key to decide which value gets signed along with the image, and
> > > this is fundamentally part of the configure/build/release workflow.  No
> > > distro builds and signs the upstream sources unmodified, so each signed
> > > release is a fork anyway, making a upstream revocation index almost
> > > meaningless. Also, while backporting revocation index bumps to -stable
> > > should not result in any issues, I don't think the associated
> > > bookkeeping belongs in the hands of the stable tree maintainers.
> >
> > The reason it's a good idea to store it here is because otherwise
> > there would need to be another external "registry" that matches 1:1,
> > and that is maintained identical everywhere, perfectly in sync,
> > forever, and any 'new' distro and/or distro maintainer would have to
> > discover and use that registry, and would be completely oblivious to
> > it otherwise.
> >
> 
> But why does there need to be a single, shared upstream 'generation
> id' in the first place? The upstream is just a bunch of source files
> that can be built in a million different ways, including for different
> architectures that can all boot via EFI.

To be clear, having an upstream SBAT component & generation id is
not a hard requirement.

It was/is just a best practice, based on the general OSS principal that
if every downstream consumer ends up mostly duplicating each others'
work, then it is usually a better idea to collaborate in the upstream
context and thus do it only once.

This is likely to be less error prone, because while some downstreams
may be informed enough to keep track of everythying an do updates at
the right time, others may not be.

That does put some of the burden onto the upstream maintainer instead,
but that may be tempered by the downstream maintainers responding to a
security issue doing the triage & submitting the needed change (if any)
back to upstream.

If the ultimate outcome of the discussion is that the kernel rejects
the idea of maintaining this info upstream, then downstreams will just
have to do the work individually & try to collaborate in other contexts
to get consistency in their approach. I think that'd be disappointing,
but it wouldn't be show-stopper.


The generation ID is intentionally coarse/crude, because its hard the
requirement of minimizing NVRAM storage over time. So it doesn't try
to distinguish amongst scenarios where some compilation configurations
are vulnerable and some are not. If one scenario needs revoking then
every scenario gets revoked. That's an unfortunate tradeoff, but one
that was / is not easy to avoid given the EFI NVRAM limitations.

It could be possible to have a distinct SBAT component ID per kernel
architecture, if it is anticipated that SecureBoot related flaws might
commonly only affect 1 arch, not all. Separate SBAT component per
arch shouldn't negatively impact NVRAM usage, as any deployment only
needs to deal with its own native arch.

With regards,
Daniel
  

On Fri, 14 Jul 2023 at 10:34, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 14 Jul 2023 at 01:13, Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Thu, 13 Jul 2023 at 14:33, Ard Biesheuvel <ardb@kernel.org> 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.
> >
> > I appreciate the attempt, but sorry, it's not cool to try and
> > both-side things here. The original submission was not aggressive,
> > insulting or in any way out of line, it's clearly marked as an RFC and
> > the FIRST LINE was:
> >
> > "*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."
> >
> > which is as friendly and humble as one can be. And yet, not one, not
> > two, but three maintainers have decided that the best way to respond
> > to something like that is to spew bile, toxicity and aggressivity,
> > which was completely and utterly uncalled for.
>
> I completely agree.
>
> > So, if you want to call
> > someone out (you should), please direct that towards your fellow
> > maintainers, who in theory should be setting a good example and
> > productively directing the discourse, but instead, once again, have
> > only succeeded in ensuring that the lkml lives up to its fame of being
> > an open sewer.
> >
>
> While I understand your frustration, the tone of your replies is not
> helping either, so I am directing this to you as well. Let's be the
> adults in the room, shall we?

I fully accept that I have been unfriendly to some maintainers, and
I'll try to do better.

> > > 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.
> >
> > There is no other solution for the current revision of the spec (and
> > I'm pretty sure this aspect won't change in future ones either), for
> > 'public' signing it's just Shim and the 3party CA. Of course for
> > individual/internal/scoped deployment there is self signing, but
> > that's out of scope of any of this and it couldn't be otherwise, and
> > that's ok. But it's not some obscure corner case: the default for
> > every generalist distro that boots on uefi machines is by using Shim.
> > If there's any use case that matters, it's this one. But even that's
> > not the main reason it's a good idea to store the generation id here.
> >
> > > Therefore, I don't think it makes sense for the upstream kernel source
> > > to carry a revocation index. It is ultimately up to the owner of the
> > > signing key to decide which value gets signed along with the image, and
> > > this is fundamentally part of the configure/build/release workflow.  No
> > > distro builds and signs the upstream sources unmodified, so each signed
> > > release is a fork anyway, making a upstream revocation index almost
> > > meaningless. Also, while backporting revocation index bumps to -stable
> > > should not result in any issues, I don't think the associated
> > > bookkeeping belongs in the hands of the stable tree maintainers.
> >
> > The reason it's a good idea to store it here is because otherwise
> > there would need to be another external "registry" that matches 1:1,
> > and that is maintained identical everywhere, perfectly in sync,
> > forever, and any 'new' distro and/or distro maintainer would have to
> > discover and use that registry, and would be completely oblivious to
> > it otherwise.
> >
>
> But why does there need to be a single, shared upstream 'generation
> id' in the first place? The upstream is just a bunch of source files
> that can be built in a million different ways, including for different
> architectures that can all boot via EFI.
>
> To me, being able to revoke a signed release by means of a revocation
> counter makes perfect sense. What doesn't make sense is the need for
> two or more counters to describe the same entity.

For coordination. There used to be significant downstream delta, but
AFAIK nowadays the vast, vast majority of code is all upstream (I mean
specifically for things relevant to the shim+3rd party CA secure boot
flow here, like EFI stub/lockdown/mok/etc), so the reasonable
assumption is that in most cases everyone will have to revoke exactly
the same generations, so that's what it's being optimized for. And
remember that the revocation is one, unique and global and applies to
everybody, so everybody needs to use the same generation id - this is
not optional, so it requires coordination, and having an out-of-band
coordination mechanism that associates a bunch of kernel versions to a
bunch of generation ids, that everyone needs to find, agree on, and
keep an eye on, makes things significantly harder.

The other side of the coin is that, for those that don't participate
in such use cases (again, shim+3rd party CA), it's all a no-op. AFAIK
the only hard requirement that would be asked for kernel maintainers
is to every now and then review and merge a patch acked by the usual
suspects that says something like:

-SBAT_GENERATION_ID = 123
+SBAT_GENERATION_ID = 124

and they can otherwise be completely oblivious to any of this, and it
shouldn't affect them or their use cases in any way.

So on one side of the scale there's saving significant time and effort
to pretty much all distribution kernel maintainers, and on the other
side there's reviewing a one-liner every now and then for upstream
maintainers. Unless there is something I am missing, it seems like a
good tradeoff, no? Given that distribution kernel maintainers' time is
a finite resource, any time spent maintaining an out-of-band mechanism
for this - and let's be clear, they _will_ have to in order to
participate in shim+3rd party CA - is time not spent working on more
interesting and useful maintenance tasks for the betterment of the
kernel as a whole.

> > It would be much more work for those actually doing the work, and it
> > wouldn't make any meaningful differences to those who don't care about
> > the use case. AFAIK nobody has suggested that it's kernel maintainers
> > who need to worry about the generation id and do the bookkeeping, if
> > they don't care. I mean I'm pretty sure every help is welcome, but
> > that should be it.
> >
> > The 'owner of the signing key' is not good enough, because there are
> > many of those - as you know, the kernel is signed by each distro. But
> > the key here is that the revocation is _global_ (again: global means
> > it applies to everyone using shim signed by 3rd party CA), so each
> > distro storing their own id defeats the purpose of that.
>
> But this kernel is never signed by the key that signs shim. Each
> distro has its own set of keys to sign releases of their kernel forks.
> So what is the relevance of shim being signed by the MS 3rd party UEFI
> CA certificate here?
>
> In fact, it would make me *much* happier if shim was not mentioned at
> all, and someone could explain why this facility has value if you are
> not using shim in the first place. I'd much prefer to, e.g., have a
> Debian top-level cert in KEK, so it could store its per-release
> signing keys in db, and revoke those (if needed) via dbx. Could SBAT
> play a role in such a context as well?
>
> shim and its GRUB integration have been an endless source of problems
> with EFI boot on non-x86 architectures, so arguing that something is
> needed by shim is not very convincing to me, and generally implies
> that the distros should be owning it instead.

Revoking via DBX does not scale in practice, because revoking by hash
is a non-starter, and revoking certificates is such an horrendous pain
in the backside that de-facto the only reason somebody would go
through that is in case the private keys are lost/stolen, or they
expire. The MSFT db/KEK certs are about to expire, and they'll need
rotating soon-ish. The amount of resources and effort and time this
requires is simply astonishing. I am just observing from the sidelines
and even that gives me fatigue. Nobody will want to do that yearly.

Also, even assuming having distro certs in KEK and rotate them yearly
was possible, there is no way to have that and have it work by default
on consumer PCs. The P0 goal for generalist distributions is that the
user plugs in a USB stick, boots the machine and everything works, out
of the box, without having to mess with bios settings or any of that.
This cannot possibly be achieved if first you have to enroll new
certificates in KEK, because it means you need to go into setup mode
by hand and enroll your own PK, which you need to have prepared
off-box, because OEMs are not going to add 20 random distros KEKs at
factory. Especially if they get revoked yearly or more often due to
bugs, it would essentially require new firmware updates to be pushed,
which wouldn't be installed on machines sitting on a shelf, even
assuming OEMs actually ship firmware updates for old products.

So the value prop of shim+3rd party CA is that you get something that
"just works" out of the box, that doesn't put speedbumps in front of
users. And as it turns out, we need a better revocation mechanism than
what is available to make it all work sensibly and securely, hence why
the people involved in this space have been working on SBAT for the
past couple of years.

Of course one can always self-enroll, and then none of this matters.
This is not aimed at that use case.

Now there's an argument for having the UEFI spec itself mandate a
better, generation-based revocation mechanism, other than what DBX
currently provides. This is being thought about, but we need a
solution that works today and with hardware that has been sold in the
past decade or so and will be sold until such a hypothetical new spec
version is available and implemented and on the market, because the
bad guys won't be waiting patiently for that.
  

On Fri, Jul 14, 2023 at 01:29:20AM +0100, Luca Boccassi wrote:
> On Thu, 13 Jul 2023 at 07:09, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > > Who is going to be responsible for determining that this number needs to
> > > > be updated?
> > >
> > > Most likely those who understand the problem space - largely the group
> > > of people maintaining the EFI stack, with various inputs, I imagine.
> > > That's how it currently works for various bootloaders.
> >
> > We need specifics and to have people agree to do this, otherwise, again,
> > this patch is useless.
> 
> Not really, as this is about mechanism, not process.

And this right here is why everyone is both so mad at this patch from
our side, and so confused about patch from the developer's side.

To think that "let's add a security canary to the kernel image" is
anything other than a process issue, shows a lack of understanding about
exactly how the kernel is released, how the existing kernel security
response team works, and who does any of this work.  To ignore that
means that there is no way in the world this can ever be accepted.

> > > > What is their response time?
> > > >
> > > > Who will they be submitting the patch to this string in order to have it
> > > > change?
> > >
> > > A bit too soon for exact details on processes given where we are, I think.
> >
> > Not at all, this is a proposal for a "security flag" for the kernel,
> > getting this all decided now is the only correct way to determine if
> > this is actually something that can work properly.
> 
> No, the question here was about mechanism and storage. And it already
> works btw, it's just the kernel that's lagging behind, as usual.

Perhaps this is on purpose as many of us consider this type of thing
nothing more than "security theatre" that will not work for a project
like ours?

> > To just go "we are going to randomly add a number that will sometimes be
> > incremented in the future to determine the buggyness of the kernel
> > without saying who will control this, or how it will be done" is crazy.
> >
> > Would other operating systems or projects accept such a change without
> > this information?
> >
> > Would you take this patch if you were responsible for kernel releases?
> 
> I think you are still missing one tiny bit of information: it is
> already used in other projects
> 
> $ sudo objcopy -O binary --only-section=.sbat
> /boot/efi/EFI/Debian/grubx64.efi /dev/stdout
> sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> grub,3,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
> grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2

Nice, and what describes the process that the grub team uses to set that
number?  Where is that document and team that does this work?

And frankly, grub is nothing more than a tiny project compared to the
kernel, with the huge majority of the world's users of Linux not even
using grub at all.  So of course the use of grub for this might just be
a bit different as to how Linux should be using it.

> > > > How long will this feature have to be maintained?
> > >
> > > Until something else supplants EFI, I'd imagine
> >
> > So 40+ years, great, who is going to fund that?
> 
> Who funds EFI work?

UEFI the spec is funded by various companies (Intel, et-all).  So you
are saying that these companies also need to do this development too?
Have you got them to agree to this?  If so, great, let's get their
signed-off-by on it please.

Otherwise you all are saying "someone else will do all of this process
work", which frankly, is totally insulting to those of us who _do_ do
all of the process work for security issues and kernel releases.

> > > > We have a plethora of kernel changes in our history to learn from here,
> > > > please do so and show how this will affect us going forward based on our
> > > > past, otherwise we have no way of knowing how any of this is going to
> > > > work.
> > >
> > > I am not aware of anything similar enough, but please do point those
> > > out if you are.
> >
> > Audit our past history and document when the number would have changed
> > please.
> 
> Sure, where do I send the invoice?

If you are not willing to take the time to determine how this proposed
change will affect the kernel developers and infrastructure by doing
some modeling based on our past history, then we have no reason to even
consider accepting this change as you are stating that you have no idea
how it will affect us.

sorry,

greg k-h
  

On Fri, Jul 14, 2023 at 08:57:03AM +0200, Emanuele Giuseppe Esposito wrote:
> Am 14/07/2023 um 00:04 schrieb Greg KH:
> > On Thu, Jul 13, 2023 at 10:49:31PM +0200, Emanuele Giuseppe Esposito wrote:
> >>>> I replied to the thread not to defend the idea as after the discussion
> >>>> it is clear there's a lot to take into consideration if anyone decides
> >>>> to pursue the SBAT idea ever again (and the discussion is now well
> >>>> preserved in the archive!). I replied to disagree with "get sign-offs
> >>>> from senior people before sending RFCs" idea, I believe that asking
> >>>> questions by sending a not-fully-ready patch as "RFC" should not be
> >>>> discouraged. 
> >>>
> >>> On the contrary, this is EXACTLY what needs to happen here.
> >>>
> >>> This developer (I'm not picking on them at all, it's not their fault),
> >>> should be taking advantage of the resources of their company when
> >>> dealing with core, critical, functionality of the kernel.
> >>>
> >>> To just "throw them at the wolves" like Red Hat did, is a total
> >>> disservice to them, AND it wastes the time and resources of the
> >>> community, as it is not our job to train and teach them, it is the job
> >>> of the senior people at your company to do so.
> >>>
> >>> We have a non-zero number of companies that right now who are in the
> >>> "penalty box" because their developers have had a history of throwing
> >>> crud over the wall, or having inexperienced developers submit changes
> >>> that are obviously wrong, which waste the time and energy of the kernel
> >>> community.  For companies that do this, we have instituted the
> >>> requirement that they get review and acceptance of kernel changes from
> >>> the experienced developers within the company BEFORE submitting their
> >>> changes to the community, for the basic fact that this actually saves
> >>> EVERYONE time and energy.
> >>>
> >>> It allows the developer to grow and learn more quickly, it saves the
> >>> energy and time of the reviewers (which is our most valuable resource
> >>> right now) and it provides a solid path forward on the corporate ladder
> >>> of using mentors well, and lifting up your own employees.
> >>>
> >>> I don't think you want us to put Red Hat into this type of policy at
> >>> this point in time, but if you all keep insisting that you can just "let
> >>> loose" inexperienced developers who wish to change the core
> >>> functionality of how we operate, that can easily change.
> >>
> >> Wow, I was not aware of these policies O.O.
> >> What you say makes sense, but what about developers not working in a
> >> company? Then they are completely ignored?
> > 
> > Not at all, they are not ignored and are treated as someone who probably
> > needs help.
> > 
> >> Otherwise a simple way to trick you is to actually use my gmail address
> >> and you won't ever know that I work for RH.
> > 
> > If RH finds out you are misrepresenting yourself like this, I don't
> > think it will go over very well :)
> 
> By "my gmail address" I mean any potential employee of any company
> reading this thread of course. I think after this you'll remember my
> name for a while ;) So no way to hide for me. Also my private email
> address has my name and surname in it, so it won't be hard to identify me.
> 
> Anyways, I think you need to clarify better what you mean with
> "inexperienced developers submit changes that are obviously wrong", more
> specifically the "obviously wrong" part.
> If you refer to the commit message wrongly made, ok you have a point. I
> take responsibility on this, it already happened that I wrote non clear
> commits and I am working on this. Working on different communities that
> have less commit rules and rarely sending stuff to kernel doesn't help
> though (my only excuse). If it's that, the issue can be closed here and
> I will definitely be more careful in the future, as well as all I work with.
> 
> If you refer to the fact that the patch is wrong technically, 1) as I
> wrote it is indeed not working properly, I have clearly documented in
> the commit message that if you run make twice with this patch it won't
> work, and 2) the aim of this patch that we thought was clear with RFC
> and "Important:..." was to ask opinions because we don't have experts on
> this matter, the technology is new and would like to hear opinions from
> outside. You gave the opinion we were looking for, it's just that the
> whole thing escalated dramatically because IMHO intentions were
> misunderstood and again IMHO the wrong tones and wordings were used.

The main disconnect here is that you are confusing "technical" from
"process".  This small "technical change" has a HUGE influence on our
processes and procedures.

The people responsible for those processes and procedures are the ones
going "oh hell no!" right now, and they are correct to do so as you are
saying "we don't care about the process" which can be considered as both
a "there is no need for process" naive idea, or a "we are going to be
expecting you to do more work for us without even asking", both of which
are being extremely rude to those of us responsible for ensuring that
process works for every user of Linux.

This doesn't always come up in kernel patches, so I can understand your
confusion when it happened.  But the fact that "adding a security bit"
was not at documented for the potential workflow changes is not
acceptable for any group/developer who would propose such a thing.

Maintainers always are right to say "no" when patches are proposed if
the acceptance of that patch is going to cause them extra work, as
maintainer's time is our most precious resource.  Normally that extra
work is "just" additional code to maintain, but sometimes it involves
workflow changes, as you are proposing here.

So again, please work with the more experienced developers at your
company to come up with just how this workflow changes are going to be
accommodated if you wish for this change to be accepted.

thanks,

greg k-h
  

On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 14, 2023 at 01:29:20AM +0100, Luca Boccassi wrote:
> > On Thu, 13 Jul 2023 at 07:09, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > > > Who is going to be responsible for determining that this number needs to
> > > > > be updated?
> > > >
> > > > Most likely those who understand the problem space - largely the group
> > > > of people maintaining the EFI stack, with various inputs, I imagine.
> > > > That's how it currently works for various bootloaders.
> > >
> > > We need specifics and to have people agree to do this, otherwise, again,
> > > this patch is useless.
> >
> > Not really, as this is about mechanism, not process.
>
> And this right here is why everyone is both so mad at this patch from
> our side, and so confused about patch from the developer's side.
>
> To think that "let's add a security canary to the kernel image" is
> anything other than a process issue, shows a lack of understanding about
> exactly how the kernel is released, how the existing kernel security
> response team works, and who does any of this work.  To ignore that
> means that there is no way in the world this can ever be accepted.

This _question_ was about mechanism, not process. As already
mentioned, nobody asked you to sign up for any extra work.

> > > > > What is their response time?
> > > > >
> > > > > Who will they be submitting the patch to this string in order to have it
> > > > > change?
> > > >
> > > > A bit too soon for exact details on processes given where we are, I think.
> > >
> > > Not at all, this is a proposal for a "security flag" for the kernel,
> > > getting this all decided now is the only correct way to determine if
> > > this is actually something that can work properly.
> >
> > No, the question here was about mechanism and storage. And it already
> > works btw, it's just the kernel that's lagging behind, as usual.
>
> Perhaps this is on purpose as many of us consider this type of thing
> nothing more than "security theatre" that will not work for a project
> like ours?

Yep, blacklotus and boothole were just security theatre, sounds about right.

> > > To just go "we are going to randomly add a number that will sometimes be
> > > incremented in the future to determine the buggyness of the kernel
> > > without saying who will control this, or how it will be done" is crazy.
> > >
> > > Would other operating systems or projects accept such a change without
> > > this information?
> > >
> > > Would you take this patch if you were responsible for kernel releases?
> >
> > I think you are still missing one tiny bit of information: it is
> > already used in other projects
> >
> > $ sudo objcopy -O binary --only-section=.sbat
> > /boot/efi/EFI/Debian/grubx64.efi /dev/stdout
> > sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > grub,3,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
> > grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2
>
> Nice, and what describes the process that the grub team uses to set that
> number?  Where is that document and team that does this work?

At the link that was pasted dozens of times already, including in that output:

https://github.com/rhboot/shim/blob/main/SBAT.md

> And frankly, grub is nothing more than a tiny project compared to the
> kernel, with the huge majority of the world's users of Linux not even
> using grub at all.  So of course the use of grub for this might just be
> a bit different as to how Linux should be using it.

No, it's identical, because as it was already said a million times
this is about the 3rd party CA + Shim flow (which is the only flow
that works by default on consumer grade x86 machines and thus it's
what all the major distributions use), and in that flow there is
always Shim, and there is always Grub, and there is always Linux, so
the ratio is 1:1:1.
Outside of this use case, this doesn't apply and doesn't affect
anything, it's a no-op.

> > > > > How long will this feature have to be maintained?
> > > >
> > > > Until something else supplants EFI, I'd imagine
> > >
> > > So 40+ years, great, who is going to fund that?
> >
> > Who funds EFI work?
>
> UEFI the spec is funded by various companies (Intel, et-all).  So you
> are saying that these companies also need to do this development too?
> Have you got them to agree to this?  If so, great, let's get their
> signed-off-by on it please.
>
> Otherwise you all are saying "someone else will do all of this process
> work", which frankly, is totally insulting to those of us who _do_ do
> all of the process work for security issues and kernel releases.

Nobody asked you to do any process work.

> > > > > We have a plethora of kernel changes in our history to learn from here,
> > > > > please do so and show how this will affect us going forward based on our
> > > > > past, otherwise we have no way of knowing how any of this is going to
> > > > > work.
> > > >
> > > > I am not aware of anything similar enough, but please do point those
> > > > out if you are.
> > >
> > > Audit our past history and document when the number would have changed
> > > please.
> >
> > Sure, where do I send the invoice?
>
> If you are not willing to take the time to determine how this proposed
> change will affect the kernel developers and infrastructure by doing
> some modeling based on our past history, then we have no reason to even
> consider accepting this change as you are stating that you have no idea
> how it will affect us.

There's no need for that to tell you how this will affect you: it will
not. Every now and then you'll receive a one-liner patch to apply.
What's so terrible about that?
  

On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jul 14, 2023 at 01:29:20AM +0100, Luca Boccassi wrote:
> > > On Thu, 13 Jul 2023 at 07:09, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > > > > Who is going to be responsible for determining that this number needs to
> > > > > > be updated?
> > > > >
> > > > > Most likely those who understand the problem space - largely the group
> > > > > of people maintaining the EFI stack, with various inputs, I imagine.
> > > > > That's how it currently works for various bootloaders.
> > > >
> > > > We need specifics and to have people agree to do this, otherwise, again,
> > > > this patch is useless.
> > >
> > > Not really, as this is about mechanism, not process.
> >
> > And this right here is why everyone is both so mad at this patch from
> > our side, and so confused about patch from the developer's side.
> >
> > To think that "let's add a security canary to the kernel image" is
> > anything other than a process issue, shows a lack of understanding about
> > exactly how the kernel is released, how the existing kernel security
> > response team works, and who does any of this work.  To ignore that
> > means that there is no way in the world this can ever be accepted.
> 
> This _question_ was about mechanism, not process. As already
> mentioned, nobody asked you to sign up for any extra work.

And that is the disconnect.  To think that this magic "security canary
number" is somehow not going to affect my work is not correct.  See
below for details...

> > > > > > How long will this feature have to be maintained?
> > > > >
> > > > > Until something else supplants EFI, I'd imagine
> > > >
> > > > So 40+ years, great, who is going to fund that?
> > >
> > > Who funds EFI work?
> >
> > UEFI the spec is funded by various companies (Intel, et-all).  So you
> > are saying that these companies also need to do this development too?
> > Have you got them to agree to this?  If so, great, let's get their
> > signed-off-by on it please.
> >
> > Otherwise you all are saying "someone else will do all of this process
> > work", which frankly, is totally insulting to those of us who _do_ do
> > all of the process work for security issues and kernel releases.
> 
> Nobody asked you to do any process work.

Great, so who will be doing this process work?

Seriously, we have to know this before we could accept this type of
thing.  To not do so would mean this value means nothing.

> > > > > > We have a plethora of kernel changes in our history to learn from here,
> > > > > > please do so and show how this will affect us going forward based on our
> > > > > > past, otherwise we have no way of knowing how any of this is going to
> > > > > > work.
> > > > >
> > > > > I am not aware of anything similar enough, but please do point those
> > > > > out if you are.
> > > >
> > > > Audit our past history and document when the number would have changed
> > > > please.
> > >
> > > Sure, where do I send the invoice?
> >
> > If you are not willing to take the time to determine how this proposed
> > change will affect the kernel developers and infrastructure by doing
> > some modeling based on our past history, then we have no reason to even
> > consider accepting this change as you are stating that you have no idea
> > how it will affect us.
> 
> There's no need for that to tell you how this will affect you: it will
> not. Every now and then you'll receive a one-liner patch to apply.
> What's so terrible about that?

And who will be sending that to me?  For what releases?  For how long
will they be agreeing to do this work for?  How will it be tracked?
What will they be using to determine when the number will be changed?
How will they know it should be changed?

None of this has been answered, and that's the real issue here.  This
"magic number" is saying it is going to reflect some specific "security
issue" yet no one is saying how those issues are going to be determined,
or anything else about it.

Again, as I've repeated numerous times, tell us how often this number
would have changed in the past X years to give us an idea of how you
will be changing it going forward.  To not provide any of this means
this patch adding this magic number means nothing as no one knows what
it actually means.

thanks,

greg k-h
  

On Sun, Jul 16, 2023 at 08:28:10PM +0200, Greg KH wrote:
> On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> > On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > If you are not willing to take the time to determine how this proposed
> > > change will affect the kernel developers and infrastructure by doing
> > > some modeling based on our past history, then we have no reason to even
> > > consider accepting this change as you are stating that you have no idea
> > > how it will affect us.
> > 
> > There's no need for that to tell you how this will affect you: it will
> > not. Every now and then you'll receive a one-liner patch to apply.
> > What's so terrible about that?

I think that's not entirely accurate, as this *will* have an impact on
anyone involved in backporting fixes for the kernel stable trees, when
they need to resolve conflicts on the SBAT file. It shouldn't have a
big impact, but we should be honest that it will be a non-zero impact.

Lets say mainline branch has had 2 security vulnerabilities A and B,
each of which was associated with an increment of the SBAT version
number. The first flaw A changed SBAT from 7 to 8,and then the second
flaw B changed SBAT from 8 to 9.

If someone wants to backport the fix for bug "B" they will get a
conflict on the SBAT file when cherry-picking the patch. When that
happens they must decide:

  * It is acceptable to ignore issue A, because it didn't affect
    that branch. The conflict is resolved by having the backported
    patch increase SBAT version from 7 to 9 directly.

  * It is required to first backport issue A, because that also
    affects that branch. The conflict is resolved by first backporting
    the code fix & SBAT change for A, and then backporting the code
    fix and SBAT change for B. SBAT changes from 7 to 8 to 9 just
    like on master.

IOW whomever is doing backport patches for stable needs to understand
the semantics of SBAT and how to resolve conflicts on it. If they get
this wrong, then it breaks the protection offered by SBAT, which would
then require a 3rd SBAT change to fix the mistake.

This likely means that stable tree maintainers themselves need to
understand the SBAT change rules, so they can review conflict resolution
for any proposed changes, to sanity check what is being proposed.

> And who will be sending that to me?  For what releases?  For how long
> will they be agreeing to do this work for?  How will it be tracked?
> What will they be using to determine when the number will be changed?
> How will they know it should be changed?

Before we consider SBAT, there is the code bug & its patch.

Someone finds bug in the early boot process on EFI systems and cooks up
a patch for it. This is work that is already done today, whether entirely
upstream in the normal context of day-to-day kernel development, or
downstream with a vendor receiving a bug report and triaging a response
to it which eventually turns into an upstream submission.

Today there is the question of whether to assign a CVE to such fixes.

If upstream doesn't have an associated CVE identified when merging the
code patch, the downstream vendors act as a backstop and can decide to
assign a CVE after the fact. This is relatively easy as assigning a
CVE doesn't result in any code patches, it is just paperwork and does
not really impact upstream at that point.

In terms of triage, deciding to increment SBAT is little different
from deciding to assign a CVE. The analysis & decision can be done
upstream, but if not, downstream vendors can act as a backstop to
do the analysis after a code patch is already in upstream. I would
probably assume that any flaw serious enough to break SecureBoot
is likely going to arrive via an embargoed security report involving
downstream vendors, so SBT changes would be co-ordinated via the
vendor triage & response.

The key difference with SBAT is that if a downstream vendor identifies
needs for an SBAT version change, after a  patch is already merged in
upstream, this would typically trigger a 2nd followup patch to be sent
upstream from the vendor.

In terms of who will be sending SBAT changes. It could be the person
who first writes & submits the patch that addresses a EFI boot process
vulnerability. If not, it would likely be one of the various downstream
vendors, with their security/kernel team sending a change after the fact.


In terms of what branches would be impacted. The minimum bar would be
to only make SBAT changes in master. If that is all that is ever done
upstream, the mechanism would work as intended. There will inevitably
be backports to stable trees though, and people involved in this will
need to understand the rules for resolving conflicts when backporting
fixes that change SBAT as mentioned earlier.

I think the assumption would have to be that any stable branch is a
possible candidate for receiving backports that imply SBAT changes,
just like any stable branch might receive a backport for a regular
CVE fix. Whomever is interested in submitting changes to a particular
branch decides which particular patches get backported. The precense
of SBAT does constrain ordering of backports though, in the (hopefull)
unlikely case where multiple SBAT changes arrive close together

> None of this has been answered, and that's the real issue here.  This
> "magic number" is saying it is going to reflect some specific "security
> issue" yet no one is saying how those issues are going to be determined,
> or anything else about it.

Luca gave a (non-exhaustive) list of examples of areas of the code
which are most relevant earlier in the thread

[quote]
Kernel module signature enforcement, Lockdown LSM, ensuring
ExitBootServices is called at the right time, etc.
[/quote]

IIUC, your request here could potentially be satisfied if there was
first a patch that added a file 'Documentation/security/sbat.rst'
explaining in much more detail which set of kernel features are
relevant when considering SBAT, and how to evaluate bugs to decide
whether a SBAT change is justified or not.

That docs file also needs to explain the implications and criteria
for backporting patches to stable branches, and how to deal with SBAT
if upstream didn't make a change to it and it needs changing after
the fact.

> Again, as I've repeated numerous times, tell us how often this number
> would have changed in the past X years to give us an idea of how you
> will be changing it going forward.  To not provide any of this means
> this patch adding this magic number means nothing as no one knows what
> it actually means.

The SBAT concept was introduced after discussions with Microsoft
after the Grub BootHole[1] vulnerability was identified in 2021.

I'm not aware of any kernel CVEs since that point in time that
would have implied SBAT changes, but admittedly I've not paid
close enough attention to be entirely confident. Is going back
through 2 years of kernel CVEs (to the point where SBAT was
invented) a long enough timeframe to satisfy this request for
info on the frequency of changes ?

With regards,
Daniel

[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00007.html
    https://eclypsium.com/research/theres-a-hole-in-the-boot/
  

On Mon, Jul 17, 2023 at 10:22:51AM +0100, Daniel P. Berrangé wrote:
> I'm not aware of any kernel CVEs since that point in time that
> would have implied SBAT changes, but admittedly I've not paid
> close enough attention to be entirely confident. Is going back
> through 2 years of kernel CVEs (to the point where SBAT was
> invented) a long enough timeframe to satisfy this request for
> info on the frequency of changes ?

Many *MANY* security bugs never get a CVE. CVE is meaningless when it
comes to kernel bugs. Why does it make sense to review CVEs ?
  

On Mon, 17 Jul 2023 at 10:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Sun, Jul 16, 2023 at 08:28:10PM +0200, Greg KH wrote:
> > On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> > > On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > If you are not willing to take the time to determine how this proposed
> > > > change will affect the kernel developers and infrastructure by doing
> > > > some modeling based on our past history, then we have no reason to even
> > > > consider accepting this change as you are stating that you have no idea
> > > > how it will affect us.
> > >
> > > There's no need for that to tell you how this will affect you: it will
> > > not. Every now and then you'll receive a one-liner patch to apply.
> > > What's so terrible about that?
>
> I think that's not entirely accurate, as this *will* have an impact on
> anyone involved in backporting fixes for the kernel stable trees, when
> they need to resolve conflicts on the SBAT file. It shouldn't have a
> big impact, but we should be honest that it will be a non-zero impact.
>
> Lets say mainline branch has had 2 security vulnerabilities A and B,
> each of which was associated with an increment of the SBAT version
> number. The first flaw A changed SBAT from 7 to 8,and then the second
> flaw B changed SBAT from 8 to 9.
>
> If someone wants to backport the fix for bug "B" they will get a
> conflict on the SBAT file when cherry-picking the patch. When that
> happens they must decide:
>
>   * It is acceptable to ignore issue A, because it didn't affect
>     that branch. The conflict is resolved by having the backported
>     patch increase SBAT version from 7 to 9 directly.
>
>   * It is required to first backport issue A, because that also
>     affects that branch. The conflict is resolved by first backporting
>     the code fix & SBAT change for A, and then backporting the code
>     fix and SBAT change for B. SBAT changes from 7 to 8 to 9 just
>     like on master.
>
> IOW whomever is doing backport patches for stable needs to understand
> the semantics of SBAT and how to resolve conflicts on it. If they get
> this wrong, then it breaks the protection offered by SBAT, which would
> then require a 3rd SBAT change to fix the mistake.
>
> This likely means that stable tree maintainers themselves need to
> understand the SBAT change rules, so they can review conflict resolution
> for any proposed changes, to sanity check what is being proposed.

This can be solved by just not changing the generation id in the same
patch that fixes a bug, but as the last step in a series, which
doesn't add the cc: stable nor the other tags. If we want to bump the
generation id in a stable branch, we'll then have to send an
appropriately crafted patch targeted at the right place. That way even
if the fixes get backported, there is no additional burden on any
kernel maintainer.
  

On Mon, Jul 17, 2023 at 01:06:31PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 17, 2023 at 10:22:51AM +0100, Daniel P. Berrangé wrote:
> > I'm not aware of any kernel CVEs since that point in time that
> > would have implied SBAT changes, but admittedly I've not paid
> > close enough attention to be entirely confident. Is going back
> > through 2 years of kernel CVEs (to the point where SBAT was
> > invented) a long enough timeframe to satisfy this request for
> > info on the frequency of changes ?
> 
> Many *MANY* security bugs never get a CVE. CVE is meaningless when it
> comes to kernel bugs. Why does it make sense to review CVEs ?

Yes, I know many security bugs gets fixed without a CVE being
assigned, but in the context of the question that doesn't
matter.

The SBAT version number will be incremented in response to an
identified security bug. Even if upstream has not assigned a
CVE to an issue, downstream vendors are likely to have done
so *if* they identified the security issue.

If neither upstream, nor downstream, publically identified a
fix as a security issue, then by extension they would also
not have identified a need to change to the SBAT version info
either.

Thus looking at publically identified security issues via
CVEs is a reasonable proxy to guage how many times SBAT
would have been incremented, which is what Greg asked for.

With regards,
Daniel
  

On Mon, Jul 17, 2023 at 10:22:51AM +0100, Daniel P. Berrangé wrote:
> On Sun, Jul 16, 2023 at 08:28:10PM +0200, Greg KH wrote:
> > On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> > > On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > If you are not willing to take the time to determine how this proposed
> > > > change will affect the kernel developers and infrastructure by doing
> > > > some modeling based on our past history, then we have no reason to even
> > > > consider accepting this change as you are stating that you have no idea
> > > > how it will affect us.
> > > 
> > > There's no need for that to tell you how this will affect you: it will
> > > not. Every now and then you'll receive a one-liner patch to apply.
> > > What's so terrible about that?
> 
> I think that's not entirely accurate, as this *will* have an impact on
> anyone involved in backporting fixes for the kernel stable trees, when
> they need to resolve conflicts on the SBAT file. It shouldn't have a
> big impact, but we should be honest that it will be a non-zero impact.
> 
> Lets say mainline branch has had 2 security vulnerabilities A and B,
> each of which was associated with an increment of the SBAT version
> number. The first flaw A changed SBAT from 7 to 8,and then the second
> flaw B changed SBAT from 8 to 9.
> 
> If someone wants to backport the fix for bug "B" they will get a
> conflict on the SBAT file when cherry-picking the patch. When that
> happens they must decide:
> 
>   * It is acceptable to ignore issue A, because it didn't affect
>     that branch. The conflict is resolved by having the backported
>     patch increase SBAT version from 7 to 9 directly.
> 
>   * It is required to first backport issue A, because that also
>     affects that branch. The conflict is resolved by first backporting
>     the code fix & SBAT change for A, and then backporting the code
>     fix and SBAT change for B. SBAT changes from 7 to 8 to 9 just
>     like on master.
> 
> IOW whomever is doing backport patches for stable needs to understand
> the semantics of SBAT and how to resolve conflicts on it. If they get
> this wrong, then it breaks the protection offered by SBAT, which would
> then require a 3rd SBAT change to fix the mistake.
> 
> This likely means that stable tree maintainers themselves need to
> understand the SBAT change rules, so they can review conflict resolution
> for any proposed changes, to sanity check what is being proposed.

Exactly, and this also shows how a single "number" means nothing when it
comes to stable trees, as it can never properly convey what got fixed,
and what did not get fixed.

> > And who will be sending that to me?  For what releases?  For how long
> > will they be agreeing to do this work for?  How will it be tracked?
> > What will they be using to determine when the number will be changed?
> > How will they know it should be changed?
> 
> Before we consider SBAT, there is the code bug & its patch.
> 
> Someone finds bug in the early boot process on EFI systems and cooks up
> a patch for it. This is work that is already done today, whether entirely
> upstream in the normal context of day-to-day kernel development, or
> downstream with a vendor receiving a bug report and triaging a response
> to it which eventually turns into an upstream submission.
> 
> Today there is the question of whether to assign a CVE to such fixes.

No there is not any such question.  The kernel security team explicitly
does NOT deal with CVEs, and MITRE refuses to give me any new ones even
when I ask.

So we just aren't even going to play that game of security theatre,
sorry.

We fix hundreds, if not thousands, of bugs a month that could be
considered "CVE worthy" if we wanted to play that game, so we don't.

> If upstream doesn't have an associated CVE identified when merging the
> code patch, the downstream vendors act as a backstop and can decide to
> assign a CVE after the fact. This is relatively easy as assigning a
> CVE doesn't result in any code patches, it is just paperwork and does
> not really impact upstream at that point.

Again, upstream does not do anything with CVEs except recommend staying
away from them entirely as they do nothing except grease the wheels of
companies that have broken engineering processes (i.e. RH.)

> In terms of triage, deciding to increment SBAT is little different
> from deciding to assign a CVE. The analysis & decision can be done
> upstream, but if not, downstream vendors can act as a backstop to
> do the analysis after a code patch is already in upstream. I would
> probably assume that any flaw serious enough to break SecureBoot
> is likely going to arrive via an embargoed security report involving
> downstream vendors, so SBT changes would be co-ordinated via the
> vendor triage & response.

I can think of at least a dozen fixes we have done in the past year that
could have been considered "seriously enough to break secure boot" that
never got a CVE as we just did our job and fixed the issue and moved on
to the next problem.

So this is where your whole idea of "tracking breakages" breaks down.
You all don't know how to track this because no one is doing it.  And
when we have had people try to audit all fixes we backport for something
potentially like this, they gave up after a few months as they could not
keep up with the huge flow.

In short, we fix so many things, and any kernel change could possibly be
a security issue, that trying to enumerate them all and classify them is
almost impossible, even when someone is paying a team of people to do
that.  And now, no one is paying anyone, so again, who is going to
realistically do this work?

And even better yet, if you were to attempt to increment this number as
part of a patch that was submitted, that throws up a HUGE red flag to
the world that "hey, this was a serious fix, let's go attack
everything!" before it gets a chance to be rolled out to everywhere.

So by design, your "increment the number" process would HAVE TO lag the
acceptance of any potential patch that fixes a security issue, otherwise
you are making systems LESS secure, instead of more secure by the very
nature of the information being given to the world at large.

> The key difference with SBAT is that if a downstream vendor identifies
> needs for an SBAT version change, after a  patch is already merged in
> upstream, this would typically trigger a 2nd followup patch to be sent
> upstream from the vendor.

So you will always lag.  So how will you "match" the SBAT version change
with the actual patch?

Why not just increment the SBAT version at every kernel version change
to be sure you got it right that the fixes in this version actually
resolve real issues?

> In terms of what branches would be impacted. The minimum bar would be
> to only make SBAT changes in master. If that is all that is ever done
> upstream, the mechanism would work as intended.

Ah, but kernels are NOT used in devices from Linus's tree (i.e. master),
but rather, the world runs off of the stable kernel releases.

> There will inevitably
> be backports to stable trees though, and people involved in this will
> need to understand the rules for resolving conflicts when backporting
> fixes that change SBAT as mentioned earlier.

And as the person running the stable releases, you BETTER be working
with me to try to figure this all out.  Which goes back to my original
point, to ignore the fact that this whole thing really is a process
issue, and NOT a technical issue, is naive and shortsighted by everyone
involved.

So work on the process issues first please, and then come back and talk
to us and we will be glad to discuss if your proposed changes are
actually doable or not.

> > None of this has been answered, and that's the real issue here.  This
> > "magic number" is saying it is going to reflect some specific "security
> > issue" yet no one is saying how those issues are going to be determined,
> > or anything else about it.
> 
> Luca gave a (non-exhaustive) list of examples of areas of the code
> which are most relevant earlier in the thread
> 
> [quote]
> Kernel module signature enforcement, Lockdown LSM, ensuring
> ExitBootServices is called at the right time, etc.
> [/quote]

I can say for certain that this is NOT a correct summary of what you
need to be auditing.  Heck, you forgot "kernel configuration
dependencies" which I know in the past have been real issues and caused
systems that previously were thought to be "secure" to be able to be
trivially bypassed.  Would you all even have listed that as a potential
thing to audit if I hadn't mentioned it?

Which goes back to my original statement above, who is going to be doing
this auditing and who is going to fund and support it and how exactly
are you going to do it?  Have you learned nothing from prior efforts
here?  If so, what are you going to do differently than those who
attempted this before?

> IIUC, your request here could potentially be satisfied if there was
> first a patch that added a file 'Documentation/security/sbat.rst'
> explaining in much more detail which set of kernel features are
> relevant when considering SBAT, and how to evaluate bugs to decide
> whether a SBAT change is justified or not.

That would be a good start, but really, I could sum that up with "any
kernel bug" as remember, a bug is a bug is a bug at this layer in the
stack.

> That docs file also needs to explain the implications and criteria
> for backporting patches to stable branches, and how to deal with SBAT
> if upstream didn't make a change to it and it needs changing after
> the fact.

Good luck with the documentation!  We can't get people to read our
simple "add a cc: stable@vger.kernel.org to your bugfix to have it
automatically backported" document, I can't wait to see just how the
process for sbat is going to look like and who is going to audit the
kernel submissions to determine if people are properly doing this or
not.

> The SBAT concept was introduced after discussions with Microsoft
> after the Grub BootHole[1] vulnerability was identified in 2021.

Great, so it is for grub, why does anyone think it can work with a
kernel that moves at the speed of Linux?

> I'm not aware of any kernel CVEs since that point in time that
> would have implied SBAT changes, but admittedly I've not paid
> close enough attention to be entirely confident. Is going back
> through 2 years of kernel CVEs (to the point where SBAT was
> invented) a long enough timeframe to satisfy this request for
> info on the frequency of changes ?

CVEs mean nothing, and in fact, many of them recently mean worse than
nothing, they are actually wrong!  So no, don't look at CVEs, instead,
look at all fixes that are going into the stable kernel trees.  That
should give you a better idea.

Oh, and you all forgot, how are you going to deal with fixes for issues
that cross multiple kernel patches, and even multiple kernel releases,
in order to properly resolve the issue?  And multiple implementations?
Think about Spectre/Meltdown, how would you all have classified that as
the fixes flowed into the releases over a 6 month period?  Would you
have just bumped the number each patch?  Or waited until "yes, we
finally got it right this time, we swear!" and then bumped the value?

Anyway, you all have a ton of real work to do, before any of us can
actually consider this as anything we should even consider doing.  Best
of luck, the 2 line kernel patch will be the most simple part of this
whole thing, that's not the real issue here at all.

thanks,

greg k-h
  

On Mon, Jul 17, 2023 at 12:47:21PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 17, 2023 at 01:06:31PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 17, 2023 at 10:22:51AM +0100, Daniel P. Berrangé wrote:
> > > I'm not aware of any kernel CVEs since that point in time that
> > > would have implied SBAT changes, but admittedly I've not paid
> > > close enough attention to be entirely confident. Is going back
> > > through 2 years of kernel CVEs (to the point where SBAT was
> > > invented) a long enough timeframe to satisfy this request for
> > > info on the frequency of changes ?
> > 
> > Many *MANY* security bugs never get a CVE. CVE is meaningless when it
> > comes to kernel bugs. Why does it make sense to review CVEs ?
> 
> Yes, I know many security bugs gets fixed without a CVE being
> assigned, but in the context of the question that doesn't
> matter.

"most" security bugs never get a CVE, and by "most" I mean "almost all".

> The SBAT version number will be incremented in response to an
> identified security bug. Even if upstream has not assigned a
> CVE to an issue, downstream vendors are likely to have done
> so *if* they identified the security issue.

So this is yet-another-pointless number that only would kick in if
someone took the time to fill out a form and bump the number because
they either wanted to pad their CV, or they wanted to grease the wheels
of a broken engineering process.

This is going to ensure that actual bugs that do fix issues that should
have "bumped" this number, never cause it to actually be changed, so
people will have a total false sense of security, which is EXACTLY what
is wrong with CVEs today (among many other things as mentionted.)

If you do this this way, you will be signalling to people the exact
oposite thing you want to signal, namely "don't update this kernel
because no real problem has been found in it", which is NOT the real
thing to be saying as we have documented numberous times in the past.

> If neither upstream, nor downstream, publically identified a
> fix as a security issue, then by extension they would also
> not have identified a need to change to the SBAT version info
> either.

So all the known security bugs that we fix on a weekly basis and get
merged into the kernel trees and stable updates and pushed out to
people's machines would never actually bump this number, which means
that this number is meaningless.

Great, so we don't need it at all then :)

> Thus looking at publically identified security issues via
> CVEs is a reasonable proxy to guage how many times SBAT
> would have been incremented, which is what Greg asked for.

Again, not at all given my previous responses.  If you actually think
that CVEs represent ANYTHING regarding security fixes or not for the
kernel, I have a bridge to sell you :)

thanks,

greg k-h
  

On Mon, Jul 17, 2023 at 12:12:18PM +0100, Luca Boccassi wrote:
> On Mon, 17 Jul 2023 at 10:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Sun, Jul 16, 2023 at 08:28:10PM +0200, Greg KH wrote:
> > > On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> > > > On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > If you are not willing to take the time to determine how this proposed
> > > > > change will affect the kernel developers and infrastructure by doing
> > > > > some modeling based on our past history, then we have no reason to even
> > > > > consider accepting this change as you are stating that you have no idea
> > > > > how it will affect us.
> > > >
> > > > There's no need for that to tell you how this will affect you: it will
> > > > not. Every now and then you'll receive a one-liner patch to apply.
> > > > What's so terrible about that?
> >
> > I think that's not entirely accurate, as this *will* have an impact on
> > anyone involved in backporting fixes for the kernel stable trees, when
> > they need to resolve conflicts on the SBAT file. It shouldn't have a
> > big impact, but we should be honest that it will be a non-zero impact.
> >
> > Lets say mainline branch has had 2 security vulnerabilities A and B,
> > each of which was associated with an increment of the SBAT version
> > number. The first flaw A changed SBAT from 7 to 8,and then the second
> > flaw B changed SBAT from 8 to 9.
> >
> > If someone wants to backport the fix for bug "B" they will get a
> > conflict on the SBAT file when cherry-picking the patch. When that
> > happens they must decide:
> >
> >   * It is acceptable to ignore issue A, because it didn't affect
> >     that branch. The conflict is resolved by having the backported
> >     patch increase SBAT version from 7 to 9 directly.
> >
> >   * It is required to first backport issue A, because that also
> >     affects that branch. The conflict is resolved by first backporting
> >     the code fix & SBAT change for A, and then backporting the code
> >     fix and SBAT change for B. SBAT changes from 7 to 8 to 9 just
> >     like on master.
> >
> > IOW whomever is doing backport patches for stable needs to understand
> > the semantics of SBAT and how to resolve conflicts on it. If they get
> > this wrong, then it breaks the protection offered by SBAT, which would
> > then require a 3rd SBAT change to fix the mistake.
> >
> > This likely means that stable tree maintainers themselves need to
> > understand the SBAT change rules, so they can review conflict resolution
> > for any proposed changes, to sanity check what is being proposed.
> 
> This can be solved by just not changing the generation id in the same
> patch that fixes a bug, but as the last step in a series, which
> doesn't add the cc: stable nor the other tags. If we want to bump the
> generation id in a stable branch, we'll then have to send an
> appropriately crafted patch targeted at the right place. That way even
> if the fixes get backported, there is no additional burden on any
> kernel maintainer.

Who exactly will be "we" in this process and who will be funding this
effort to ensure that they keep doing this work for the next 20+ years?

thanks,

greg k-h
  

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
  

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
  

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
  

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
  

[note: while there is some overlap between the developers and Red Hat 
employees that are involved in KVM, I was not involved in this work and 
only learnt about it last Friday]

On 7/13/23 15:33, Ard Biesheuvel wrote:
>> 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.
>>
> 
> 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.

I am not sure about this.  I think that a revocation index could _in 
theory_ make sense as a way to double check that you have backported all 
the relevant bugfixes.  If you backport the patch that changes the index 
from 2 to 3 but your tree has index=1, it will conflict and hopefully 
fix it or lead you to document why that is happening.

But I'm saying "in theory", because I'm not sure it makes sense to apply 
the concept to an OS kernel.  A revocation index makes sense for boot 
loaders, whose purpose is to check something about the next stage and 
then get out of the way.  When using a bootloader for secure boot there 
is a limited amount of parsing and basically no user interaction.  With 
some handwaving, that makes it is possible to say things like "oh no I 
found the 234th bug in my codebase, let's bump the revocation index to 235".

If you try to do this for the OS, however, Linux's "vulnerabilities are 
just bugs" mantra hits hard---more specifically the reverse: all bugs 
are potential vulnerabilities.  Sure you can hope for the best, which is 
what we do with module signing and with the (non-upstream) secure boot 
lockdown patches.  In the end, however, an unpatched code execution or 
memory write vulnerability is always a potential rootkit.  While we 
don't have _too_ many of those, there are enough that the idea of a 
revocation index becomes completely unfeasible, not too mention those 
that are fixed silently not because "that's the way Linus does it" but 
rather because we genuinely didn't think of them as security fixes.

So perhaps there could be some kind of protocol that would let a new 
kernel tell the bootloader "don't boot an older kernel than me in the 
future".  It could even be an extension to the SBAT spec itself.  I 
haven't really thought much about it, tbh.  However, I'm quite positive 
that a revocation index attached to the kernel image cannot really work 
as a concept, not even if it is managed by the distro.

Paolo
  

On Tue, 18 Jul 2023 at 14:35, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> [note: while there is some overlap between the developers and Red Hat
> employees that are involved in KVM, I was not involved in this work and
> only learnt about it last Friday]
>
> On 7/13/23 15:33, Ard Biesheuvel wrote:
> >> 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.
> >>
> >
> > 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.
>
> I am not sure about this.  I think that a revocation index could _in
> theory_ make sense as a way to double check that you have backported all
> the relevant bugfixes.  If you backport the patch that changes the index
> from 2 to 3 but your tree has index=1, it will conflict and hopefully
> fix it or lead you to document why that is happening.
>
> But I'm saying "in theory", because I'm not sure it makes sense to apply
> the concept to an OS kernel.  A revocation index makes sense for boot
> loaders, whose purpose is to check something about the next stage and
> then get out of the way.  When using a bootloader for secure boot there
> is a limited amount of parsing and basically no user interaction.  With
> some handwaving, that makes it is possible to say things like "oh no I
> found the 234th bug in my codebase, let's bump the revocation index to 235".
>
> If you try to do this for the OS, however, Linux's "vulnerabilities are
> just bugs" mantra hits hard---more specifically the reverse: all bugs
> are potential vulnerabilities.  Sure you can hope for the best, which is
> what we do with module signing and with the (non-upstream) secure boot
> lockdown patches.  In the end, however, an unpatched code execution or
> memory write vulnerability is always a potential rootkit.  While we
> don't have _too_ many of those, there are enough that the idea of a
> revocation index becomes completely unfeasible, not too mention those
> that are fixed silently not because "that's the way Linus does it" but
> rather because we genuinely didn't think of them as security fixes.

Lockdown is upstream and has been for several years. Apart from that,
I'm not sure why there is this idea that the kernel is somehow
'special', but it is not grounded in reality. If you ask the owners of
any components, 9 times out of 10 they'll tell you their project is
absolutely unique and special and could not possibly be bundled
together with <those other things over there>, but it's just
exceptionalism.
Grub also gets plenty of bug fixes that are not classed as security
fixes, and so does Shim, and so does everything else. And they both
have plenty of user interaction, and plenty of variability. Heck, Grub
has its own complex configuration language that can take live input at
boot, _and_ reimplements most of the kernel filesystems!

But anyway, from the point of view of the 3rd party CA plus Shim
workflow, they are the same, and can be treated the same - sorry, but
the kernel is not special in any way. The only thing that matters is
if, given a bug, somebody either observed it being used as a secure
boot bypass by bad actors in the wild, or was bothered enough to write
down a self-contained, real and fully working proof of concept for
secure boot bypass. If yes, then somebody will send the one-liner to
bump the generation id, and a new sbat policy will be deployed. If no,
then most likely nobody will care, and that's fine, and I expect
that's what will happen most of the time.

> So perhaps there could be some kind of protocol that would let a new
> kernel tell the bootloader "don't boot an older kernel than me in the
> future".  It could even be an extension to the SBAT spec itself.  I
> haven't really thought much about it, tbh.  However, I'm quite positive
> that a revocation index attached to the kernel image cannot really work
> as a concept, not even if it is managed by the distro.

You are pretty much describing SBAT there. Except for the detail that
it can't be the component that can be compromised that tells you
whether it's compromised and you should trust it... A system's SBAT
policy is a single entity, managed centrally, and deployed everywhere.
  

On Tue, Jul 18, 2023 at 4:03 PM Luca Boccassi <bluca@debian.org> wrote:
>> If you try to do this for the OS, however, Linux's "vulnerabilities are
>> just bugs" mantra hits hard---more specifically the reverse: all bugs
>> are potential vulnerabilities.  Sure you can hope for the best, which is
>> what we do with module signing and with the (non-upstream) secure boot
>> lockdown patches.  In the end, however, an unpatched code execution or
>> memory write vulnerability is always a potential rootkit.  While we
>> don't have _too_ many of those, there are enough that the idea of a
>> revocation index becomes completely unfeasible, not too mention those
>> that are fixed silently not because "that's the way Linus does it" but
>> rather because we genuinely didn't think of them as security fixes.
>
> Lockdown is upstream and has been for several years.

Almost (the missing part is automatically locking down the kernel if
running under secure boot, which is what I referred to).

> Grub also gets plenty of bug fixes that are not classed as security
> fixes, and so does Shim, and so does everything else. And they both
> have plenty of user interaction, and plenty of variability. Heck, Grub
> has its own complex configuration language that can take live input at
> boot, _and_ reimplements most of the kernel filesystems!
>
> But anyway, from the point of view of the 3rd party CA plus Shim
> workflow, they are the same, and can be treated the same - sorry, but
> the kernel is not special in any way. The only thing that matters is
> if, given a bug, somebody either observed it being used as a secure
> boot bypass by bad actors in the wild, or was bothered enough to write
> down a self-contained, real and fully working proof of concept for
> secure boot bypass.

Maybe I'm misunderstanding but this makes no sense to me. Any code
execution vulnerability by definition lets the attacker run unsigned
code in the kernel, which is a secure boot bypass. Linux is indeed not
special in this respect; "wait for someone to exploit it and then bump
the number" is at least dubious for Grub as well.

In my opinion there is still a difference though, in that the amount
of untrusted/unsigned userspace code that the kernel is exposed to,
absolutely dwarfs the amount of code and data that a bootloader is
exposed to. For the case of filesystems, for example, Linux is a lot
more optimized, it's multithreaded, it's read/write. Grub is a lot
simpler.

> > So perhaps there could be some kind of protocol that would let a new
> > kernel tell the bootloader "don't boot an older kernel than me in the
> > future".  It could even be an extension to the SBAT spec itself.  I
> > haven't really thought much about it, tbh.  However, I'm quite positive
> > that a revocation index attached to the kernel image cannot really work
> > as a concept, not even if it is managed by the distro.
>
> You are pretty much describing SBAT there. Except for the detail that
> it can't be the component that can be compromised that tells you
> whether it's compromised and you should trust it... A system's SBAT
> policy is a single entity, managed centrally, and deployed everywhere.

Fine, so can the SBAT spec be extended to have some kind of version
that is not a single number? If that is provided, Linux could have the
mechanism to place the kernel version in the .sbat section. But I
agree with Borislav, Greg and others that a single revocation index
simply doesn't cut it.

Paolo
  

On Tue, Jul 18, 2023 at 05:51:56PM +0200, Paolo Bonzini wrote:
> On Tue, Jul 18, 2023 at 4:03 PM Luca Boccassi <bluca@debian.org> wrote:
> > > So perhaps there could be some kind of protocol that would let a new
> > > kernel tell the bootloader "don't boot an older kernel than me in the
> > > future".  It could even be an extension to the SBAT spec itself.  I
> > > haven't really thought much about it, tbh.  However, I'm quite positive
> > > that a revocation index attached to the kernel image cannot really work
> > > as a concept, not even if it is managed by the distro.
> >
> > You are pretty much describing SBAT there. Except for the detail that
> > it can't be the component that can be compromised that tells you
> > whether it's compromised and you should trust it... A system's SBAT
> > policy is a single entity, managed centrally, and deployed everywhere.
> 
> Fine, so can the SBAT spec be extended to have some kind of version
> that is not a single number? If that is provided, Linux could have the
> mechanism to place the kernel version in the .sbat section. But I
> agree with Borislav, Greg and others that a single revocation index
> simply doesn't cut it.

In theory it could already be treated as being a version if you were
to just encode the 3 version number components into an integer.

There's a slight caveat that when parsing sbat shim currently appears
to store the generation number in a uint16, so the size is somewhat
limited. Probably still just enough bits to encode a kernel version,
though changing shim code to uint32 looks easy enough too.

Directly encoding the version number though has implications for
revokation wrt stable branches though. My impression is that the
generation number was intentionally separate from a version number,
so that people could backport particular fixes to a stable branch
and then declare it to be the same "generation" as the latest
devel branch, or other stable branches which also included the
equiv fixes.

Obviously that presumes that an old branch can be made secure by
selectively backporting patches. That is a view which is obviously
not universally accepted, especially in upstream context, as clearly
expressed in several mails in this thread. It is what distros would
typically claim to achieve though. I'm not sure it is possible to
satisfy both those differing views.

With regards,
Daniel
  

On Tue, Jul 18, 2023 at 6:35 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> There's a slight caveat that when parsing sbat shim currently appears
> to store the generation number in a uint16, so the size is somewhat
> limited. Probably still just enough bits to encode a kernel version,
> though changing shim code to uint32 looks easy enough too.

Encoding a kernel version needs a uint32 if you want to make it human
readable; you need at least 10^6 (9.99.999) for the upstream version.

However a SBAT policy based on kernel versions will not allow stable
versions, so it's basically unusable.

One possibility would be to encode the major and minor versions as
different products, so a Fedora package for Linux 6.1.137 would have:

linux.6,1,Linux,https://kernel.org/
linux.6.1,137,Linux 6.1.y,6.1.137,https://kernel.org/
linux.6.1.fc38,302,Fedora,6.1.137-302.fc38,https://koji.fedoraproject.org/koji/packageinfo?packageID=8

where old kernel versions can be "prohibited" without consuming too
much space in the policy, for example

linux.5,255       # block all 5.x kernels.
linux.6.1,138    # oh no, 6.1.137 had a *really* bad vulnerability

The questions then are

1) if this satisfies the requirements

2) if upstream people accept to expose the version in this format in
the upstream kernel

> Directly encoding the version number though has implications for
> revokation wrt stable branches though. My impression is that the
> generation number was intentionally separate from a version number,
> so that people could backport particular fixes to a stable branch
> and then declare it to be the same "generation" as the latest
> devel branch, or other stable branches which also included the
> equiv fixes.

Right, but that also requires a central authority that makes up these
revocation indices. This is unlikely to happen for Linux. :)

Paolo

> Obviously that presumes that an old branch can be made secure by
> selectively backporting patches. That is a view which is obviously
> not universally accepted, especially in upstream context, as clearly
> expressed in several mails in this thread. It is what distros would
> typically claim to achieve though. I'm not sure it is possible to
> satisfy both those differing views.
>
> 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 :|
>
  

On Wed, 19 Jul 2023 at 14:22, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On Tue, Jul 18, 2023 at 6:35 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > There's a slight caveat that when parsing sbat shim currently appears
> > to store the generation number in a uint16, so the size is somewhat
> > limited. Probably still just enough bits to encode a kernel version,
> > though changing shim code to uint32 looks easy enough too.
>
> Encoding a kernel version needs a uint32 if you want to make it human
> readable; you need at least 10^6 (9.99.999) for the upstream version.
>
> However a SBAT policy based on kernel versions will not allow stable
> versions, so it's basically unusable.
>
> One possibility would be to encode the major and minor versions as
> different products, so a Fedora package for Linux 6.1.137 would have:
>
> linux.6,1,Linux,https://kernel.org/
> linux.6.1,137,Linux 6.1.y,6.1.137,https://kernel.org/
> linux.6.1.fc38,302,Fedora,6.1.137-302.fc38,https://koji.fedoraproject.org/koji/packageinfo?packageID=8
>
> where old kernel versions can be "prohibited" without consuming too
> much space in the policy, for example
>
> linux.5,255       # block all 5.x kernels.
> linux.6.1,138    # oh no, 6.1.137 had a *really* bad vulnerability
>
> The questions then are
>
> 1) if this satisfies the requirements
>
> 2) if upstream people accept to expose the version in this format in
> the upstream kernel

That doesn't work, because it requires a new line for each new
release, which means the sbat revocation variable and payload have
unbounded growth, and the number one goal of this mechanism was to
avoid exactly that. That's why it's a generation id, and that's why
it's per-product.

Once again: this is not some generic, multi-purpose tracking. This is
not for human consumption. This is not a substitute for a version, or
a bug tracker, or whatever else. This does not inform users of
anything.
This is a machine-targeted mechanism to allow centrally-managed
revocations for the UEFI 3rd party CA + Shim flow in a way that works
for the constrained EFI environment w.r.t size, wear and tear, in
substitution of DBX which is not fit for this purpose.

> > Directly encoding the version number though has implications for
> > revokation wrt stable branches though. My impression is that the
> > generation number was intentionally separate from a version number,
> > so that people could backport particular fixes to a stable branch
> > and then declare it to be the same "generation" as the latest
> > devel branch, or other stable branches which also included the
> > equiv fixes.
>
> Right, but that also requires a central authority that makes up these
> revocation indices. This is unlikely to happen for Linux. :)

It will happen, the only question is how painful it is going to be to
maintain it. The revocation payload is unique and global, and it could
not be otherwise. Just like DBX is published centrally, and just like
Shim signing is done centrally.
  

On Wed, Jul 19, 2023 at 3:34 PM Luca Boccassi <bluca@debian.org> wrote:
> > Right, but that also requires a central authority that makes up these
> > revocation indices. This is unlikely to happen for Linux. :)
>
> It will happen, the only question is how painful it is going to be to
> maintain it. The revocation payload is unique and global, and it could
> not be otherwise. Just like DBX is published centrally, and just like
> Shim signing is done centrally.

If you are intending to go with the generation number, that
essentially means tracking vulnerabilities and that's a business that
Linux developers don't want to be in. And in fact, neither DBX nor
shim signing is managed by (upstream) open source projects. That
raises many other questions:

- What is the right place for that generation number authority and for
the registry of vulnerable kernel versions? Is it shim/mokutil, and if
so are the developers on board with doing that? How are SBAT updates
currently distributed?

- Distros will have to be the ones setting the SBAT policy. If the
central authority will use the "exploit in active use" policy (which
IMNSHO is nothing but security theater), are all distros that consume
ukify fine with that or do they want to actually start tracking kernel
vulnerabilities?

- Sorry for beating on the "Linux is different" dead horse, but what
happens if people for whatever reason don't want to run the latest
kernel? If a stable kernel update breaks hotplugging of external
displays and fixes a code execution vulnerability in a weird device
driver, do I have to fiddle with mokutil in order to keep my external
display working? Or replace "breaks hotplugging of external displays"
with "breaks the NVIDIA driver".

In any case, I think there's agreement that it's not a Linux developer
problem, so the discussion can continue elsewhere.

Paolo
  

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

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
  

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

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.
  

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

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.
  

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
  

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.
  

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
  

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

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
  

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.
  

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.
  

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