Much ado about SBAT

Posted Jul 21, 2023 9:12 UTC (Fri) by bluca (subscriber, #118303)
In reply to: Much ado about SBAT by NYKevin
Parent article: Much ado about SBAT

No, there would still be a global gen id, it would just be much more painful to maintain. I'll let you figure out how pleased distribution maintainers would be with upstream maintainers if that were to happen - not that I am under any illusion they care one bit.

Much ado about SBAT

Posted Jul 22, 2023 3:16 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (2 responses)

Well, in this hypothetical (which I should stress has not actually happened (yet)), it would be a discussion between the distros and whoever is pro-SBAT. Frankly, I'm having a hard time imagining, say, Debian wanting to spend a lot of time on something like this, so it's possible they give SBAT a "no" as well. I suppose it's possible that the SBAT people try to write off the "uncooperative" distros, but I should like to think that there is enough Debian in datacenters to give hardware manufacturers pause about that course of action.

Ultimately, the problem here is that somebody has to bell the cat, and at least historically in the FOSS community, things usually work out best if the person belling the cat is the person who actually wants the cat to wear a bell in the first place. The alternative just leads to the Nebraska problem,[1] which would be very bad in this case as it could leave a large amount of hardware suddenly unbootable.

[1]: https://xkcd.com/2347/

Much ado about SBAT

Posted Jul 22, 2023 4:59 UTC (Sat) by plugwash (subscriber, #29694) [Link]

I'm no expert, but my understanding is that the underlying issues are.

1. If we want our Linux distros to keep booting out of the box on new computers, then we have to play along with the secure boot "ecosystem", which is ultimately controlled by Microsoft.
2. UEFI has very limited space for storing revocations, a single revocation incident consumed around half the availble revocation space. It's not at all clear to me what MS would do if revocation space ran out, but it may well not be nice for Linux.

So it was determined that a more efficient revocation scheme was needed, one that could basically say "any version of software package "x" that is older (in security fix terms) than "y" is vulnerable rather than having to revoke images individually.

Much ado about SBAT

Posted Jul 22, 2023 10:44 UTC (Sat) by bluca (subscriber, #118303) [Link]

> I'm having a hard time imagining, say, Debian wanting to spend a lot of time on something like this, so it's possible they give SBAT a "no" as well.

No, Debian is involved too. Not only myself, but the maintainers of the bootloader stack are not only fully aware but also actively working on this, both downstream and upstream in the Shim community.