On Fri, 21 Mar 2025 at 14:37, Lennart Poettering <lenn...@poettering.net> wrote: > > On Do, 20.03.25 22:36, Luca Boccassi (luca.bocca...@gmail.com) wrote: > > > > > so I think your suggestion of adding a new API to shim is the best > > > > solution. Once a formal API is established, we remove the chances of > > > > accidental/unaware breakages going forward, which would be a very > > > > positive outcome. > > > > > > > > And I share your sentiments w.r.t adding yet another NIH > > > > reimplementation. It would be really strange if the addition of a > > > > protocol results in grub shedding code and removing a local > > > > reimplementation and using a common protocol instead, and sd-boot > > > > doing the exact opposite... > > > > > > I disagree. Grub and sd-boot have fundamentally different goals. Grub > > > wants to load arbitrary code and needs to ask the system to validate it. > > > So it really wants to go through as many authentication and validation > > > dances as possible: It effectively wants the LoadImage() call, just that > > > because the world with shim is so messed up that it can't actually use it. > > > > We want to use the protocols to avoid having to maintain yet another > > implementation of the same thing. What matters for distributions is > > minimizing the amount of duplication, so that you don't have to > > maintain multiple copies of the same thing, that get the same hardware > > bugs to work around, the same security vulnerabilities, and the same > > issues in general, multiple times. > > For historic reasons, grub is what always had the greatest amount of > > duplication - cryptography, encryption, filesystems, drivers, fonts, > > you name it and it's got it. sd-boot's philosophy was the opposite, > > don't be a boot loader, don't be a loader, just be a dumb menu > > displayer, and let uefi handle the nitty-gritty. This has worked well > > for us so far. > > > > The shim maintainers have expressed interest in providing a protocol > > that allows us to correctly configure loadimage so that it doesn't > > check the signature and it doesn't measure, which is what we need. > > I'll provide further updates once there is something more concrete. > > Sorry, I think we should reduce the reliance on shim for stuff we > really don't need it for, not increase it. > > I *really* don't get why we should talk to shim if we want *no* > *validation* *at* *all*. What is shim supposed to be? I though it was > about authenticating PE resources? But now you want us to call it even > if we explicitly don't want authentication of PE resources? Seems > totally backwards to me?
Aside from what was already mentioned, there are also a few more advantages. I know you don't care about these use cases and that's perfectly fine, but distributions and others do: by having a protocol that lets shim validate the embedded image, you can ensure it checks the hash of the kernel itself against dbx/mokx, and the sbat entry of the kernel itself for revocations. So for example if a kernel is known bad, it is possible to revoke its individual hash, and any number of UKIs from any number of origins embedding it will still comply with the revocation.
