Re: shim 16 breaking systemd stub and next steps

[Ard Biesheuvel <ardb@xxxxxxxxxx>]

On Fri, 21 Mar 2025 at 09:22, Alexander Graf <graf@xxxxxxxxxx> wrote:
>
>
> On 21.03.25 09:12, Ard Biesheuvel wrote:
> > On Fri, 21 Mar 2025 at 09:05, Alexander Graf <graf@xxxxxxxxxx> wrote:
> >>
> >> On 21.03.25 01:26, Luca Boccassi wrote:
> >>> On Thu, 20 Mar 2025 at 22:43, Alexander Graf <graf@xxxxxxxxxx> wrote:
> >>>> Let's first figure out how all of this works without shim. Then we can
> >>>> look at whether we need to and how we can extend the shim/sd-boot
> >>>> interface to make that case work as well. Please don't start off
> >>>> assuming everyone runs shim in secure boot environments.
> >>> But that's a bit off topic, though - the issue Mate brought up with
> >>> this thread is specifically with shim/16 + sd-boot + sd-stub, which is
> >>> a bit time pressing as both Plucky and Trixie are about to go out with
> >>> this combination that used to work, but doesn't anymore.
> >>> Without shim there's no new issue, everything works as it always did.
> >>
> >> If you read through Heinrich's reply once more, you can clearly see that
> >> it does not. We have 2 broken cases: new shim (change of contract) and
> >> U-Boot (dependency on PI internals).
> >>
> >> You could - as Ard suggested - introduce a new "prevalidated image load"
> >> protocol in shim to solve the shim case. But that will continue to leave
> >> U-Boot broken. To solve U-Boot, you would basically need to implement
> >> the same "prevalidated image load" in sd-boot. And once you have that,
> >> why would you duplicate it in shim?
> >>
> > So the fundamental problem is that LoadImage() is being used with
> > unsigned images, right?
> >
> > As I have proposed in the past, what we really need in UEFI is the
> > notion of ephemeral certs/hashes that are loaded from authenticated
> > images and can be used to authenticate subsequent ones. That would
> > reduce shim to a UEFI app with an embedded cert that simply loads the
> > next stage, and it would permit sd-stub to include SHA hashes of the
> > embedded images in a cert table that would automatically be picked up
> > by the loader (i.e., no need for signing the embedded images, taking
> > the SHA digest would be sufficient)
>
>
> Oh, that would be so much more reasonable than what happens today, yes!
> It could even be its own standardized PE section, so the code in the
> loader doesn't need to perform any stunts.
>
>
> >
> > I am well aware that this is entirely irrelevant in Trixie timeframe,
> > but perhaps the irritation level all around has been raised
> > sufficiently now for us sit down together and finally fix this shim
> > crap for good?
>
>
> I would love to get to the above scenario. However, I do not know how.

We could add this to the shim loader protocol today, and contribute it
to the UEFI spec later.

> As Luca mentioned earlier, the typical user of shim is an
> unsophisticated desktop user that wants to install Fedora on their 10
> year old laptop that happens to be locked down against the Microsoft keys.
>
> How do we get ourselves into a world where we can address that persona
> but still have a sensible technological solution?
>

We'd still need shim for such systems, but only to pivot to the distro cert.