On Tue, Jun 30, 2026 at 06:05:57AM -0400, Neal Gompa wrote: > On Tue, Jun 30, 2026 at 5:44 AM Zbigniew Jędrzejewski-Szmek > <[email protected]> wrote: > > - The intermediate kernel creates a problem for PCR prediction and > > everything that depends on this: automatic decryption of disks, > > distribution of encrypted secrets, etc. If we use kexec to enter the final > > kernel, everything that the intermediate kernel measured into PCRs is part > > of the state and the policies must deal with the explosion of possible > > combinations. > > My personal experience is that any wide-ranging attempt of using the > PCR stuff is doomed to failure. Watching Aeon try to use it in the > real world and now deciding to rip it out because it's too broken > reinforced my view that we are probably never going to use it anytime > soon. So the PCR tradeoff pretty much doesn't matter.
A lot of people are trying to make this work. It _is_ hard, but considering how much effort is being put into this, I'm pretty sure we'll get it done. It is very early to build a general-purpose distro with this. But more specialized cases are much easier, and I expect that this will become standard for VMs in fixed environments very soon. And sooner or later it'll also be extended to real hardware. Even if this is not something that we want to do now, we need to keep the possibility open for the future. > > - The intermediate kernel makes it harder to build policies which only > > allow access to tpm-bound secrets in early boot. For example, we'd > > like to use a policy where the secret used to automatically decrypt > > the root disk is only accessible in the initrd. If the first kernel > > sets up the root disk, then what to we need the second kernel for? > > If the second kernel sets up the disk, then we need to give it > > access to secrets and we can't build those policies. > > > > - A simplified kernel is still a complex beast. And the more we lean on > > minimization, the more that kernel diverges from the "normal" one. So > > the maintenance and testing burder is bigger. > > > > - We rely on kexec. Unfortunately there are many drivers where kexec > > is not realiable. So in particular if we start some graphics or sound, > > e.g. to show/play the menu, we risk the final system not working properly. > > > > This is ultimately the biggest problem. Kexec is so brittle that it's > effectively not reliable for the wide range of systems we support. > > > Whether those tradeoffs are worth the trouble is the million dollar > > question. > > > > I don't think it ever will be. Zbyszek -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
