Message-ID: <ba2354dc63fd741d2d351b18d4312d0771c0935d.camel@HansenPartnership.com>
Date:   Mon, 17 Jul 2023 12:08:26 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Ard Biesheuvel <ardb@...nel.org>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>
Cc:     x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        bluca@...ian.org, lennart@...ttering.net,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "Daniel P ." Berrangé <berrange@...hat.com>,
        linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

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

Powered by blists - more mailing lists