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

[Paolo Bonzini]

On Tue, Jul 18, 2023 at 4:03 PM Luca Boccassi <bluca@xxxxxxxxxx> 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