Date:   Tue, 18 Jul 2023 15:34:52 +0200
From:   Paolo Bonzini <pbonzini@...hat.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
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[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

Powered by blists - more mailing lists