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

From: Paolo Bonzini
Date: Tue Jul 18 2023 - 09:35:47 EST


[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