(add linux-efi@ cc) On Thu, Jul 13, 2023 at 03:33:38PM +0200, Ard Biesheuvel wrote: > Hello Emanuele, > > Please cc the linux-efi@ mailing list and myself on EFI related patches. > > First of all, I think the tone of the discussion is way out of hand on > both sides of the debate. Please keep it civil and courteous. > > On Tue, Jul 11, 2023 at 11:44:49AM -0400, Emanuele Giuseppe Esposito wrote: > > *Important*: this is just an RFC, as I am not expert in this area and > > I don't know what's the best way to achieve this. > > > > v2: > > * add standard "sbat,1,SBAT Version,..." header string > > > > The aim of this patch is to add a .sbat section to the linux binary > > (https://github.com/rhboot/shim/blob/main/SBAT.md). > > We mainly need SBAT in UKIs (Unified Kernel Images), as we might want > > to revoke authorizations to specific signed PEs that were initially > > considered as trusted. The reason might be for example a security issue > > related to a specific linux release. > > > > 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. > > > > Most people will not known what OVMF_VARS is or a PE. > > 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. Even > if the distros appear to have decided that it is a reasonable choice to > deploy the MicroSoft signed shim and the associated components on other > systems than Windows-crippled x86 PCs, this is not universally true, and > UEFI secure boot can be (and is) deployed in sane ways as well. > Note that by Windows-crippled, I mean x86 PCs built by OEMs who care about nothing other than the Windows logo sticker. These PCs often don't allow secure boot keys to be modified by the owner of the machine, or secure boot to be disabled at all. This is why shim exists, not because UEFI secure boot is broken by design.
