Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230711154449.1378385-1-eesposit@redhat.com> <ZK/9MlTh435FP5Ji@gambale.home>
 <df7941b9-11ea-9abd-e070-4e9926aecdc3@redhat.com>
In-Reply-To: <df7941b9-11ea-9abd-e070-4e9926aecdc3@redhat.com>
From:   Luca Boccassi <bluca@debian.org>
Date:   Tue, 18 Jul 2023 15:02:55 +0100
Message-ID: <CAMw=ZnTSyeL4x1o_GVKNsZdCUe2D2H53quK-TSFhOkuONjC73A@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        lennart@poettering.net, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Alexander Potapenko <glider@google.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.