[systemd-devel] shim 16 breaking systemd stub and next steps

[Alexander Graf]

On 21.03.25 09:12, Ard Biesheuvel wrote:
> On Fri, 21 Mar 2025 at 09:05, Alexander Graf <graf at amazon.com> wrote:
>>
>> On 21.03.25 01:26, Luca Boccassi wrote:
>>> On Thu, 20 Mar 2025 at 22:43, Alexander Graf <graf at amazon.com> 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. 
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?


Alex