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

[Paolo Bonzini]

On Wed, Jul 19, 2023 at 3:34 PM Luca Boccassi <bluca@xxxxxxxxxx> wrote:
> > Right, but that also requires a central authority that makes up these
> > revocation indices. This is unlikely to happen for Linux. :)
>
> It will happen, the only question is how painful it is going to be to
> maintain it. The revocation payload is unique and global, and it could
> not be otherwise. Just like DBX is published centrally, and just like
> Shim signing is done centrally.

If you are intending to go with the generation number, that
essentially means tracking vulnerabilities and that's a business that
Linux developers don't want to be in. And in fact, neither DBX nor
shim signing is managed by (upstream) open source projects. That
raises many other questions:

- What is the right place for that generation number authority and for
the registry of vulnerable kernel versions? Is it shim/mokutil, and if
so are the developers on board with doing that? How are SBAT updates
currently distributed?

- Distros will have to be the ones setting the SBAT policy. If the
central authority will use the "exploit in active use" policy (which
IMNSHO is nothing but security theater), are all distros that consume
ukify fine with that or do they want to actually start tracking kernel
vulnerabilities?

- Sorry for beating on the "Linux is different" dead horse, but what
happens if people for whatever reason don't want to run the latest
kernel? If a stable kernel update breaks hotplugging of external
displays and fixes a code execution vulnerability in a weird device
driver, do I have to fiddle with mokutil in order to keep my external
display working? Or replace "breaks hotplugging of external displays"
with "breaks the NVIDIA driver".

In any case, I think there's agreement that it's not a Linux developer
problem, so the discussion can continue elsewhere.

Paolo