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

[Alexander Graf]

On 20.03.25 11:59, Lennart Poettering wrote:
> On Do, 20.03.25 09:38, Mate Kukri (mate.kukri at canonical.com) wrote:
>
>> Hello,
>>
>> A new version of the rhboot secure boot shim was released yesterday
>> https://github.com/rhboot/shim/releases/tag/16.0.
>>
>> This version contains an implementation of the
>> LoadImage/StartImage/Exit/etc API set, which is exposed both via
>> SystemTable hooks, and a new protocol called the shim loader protocol.
>> This allows second stage bootloaders to load and execute shim signed
>> PE binaries the same way as ones signed by firmware keys.
>>
>> Unfortunately this also means that systemd-stub will no longer be able
>> to load its embedded kernel due to relying on overriding the non-UEFI
>> standard SECURITY2_ARCH_PROTOCOL to avoid verification which the shim
>> LoadImage implementation of course does not consult.
>>
>> I really hope the solution to this won't be another copy pasted PE
>> loader inside the stub (as one of the big goals of the loader protocol
>> work was to avoid the multiplication of PE loaders...)
>> One possible solution is to add a new API to shim to allow loading
>> previously verified images such as the embedded kernel without further
>> verification.
>>
>> I am looking to hear your thoughts on how to fix this issue.
>
> Alex Graf suggested to me that we really should not go through UEFI at
> all for jumping into the inner image, already. The stuff we currently
> do is just too brittle: we use BS->LoadImage() and then patch around
> the protocols to turn off the security stuff around it, because we
> don't want another authentication, and another measurement. It's
> horrible if you ask me.

I agree, it is horrible :)

> We have the inner image in memory anyway, we might as well jump
> directly into it, bypassing BS->LoadImage(). it doesn't need to know
> about how we arrange our images. We do not want the stuff it provides
> to us mostly anyway.

I would phrase it even more extremely: The semantic of the LoadImage() 
call is "Use the system's security policies and load a new, potentially 
untrusted UEFI binary from this source". But in the case of systemd 
stub, you don't want that semantic. Your binary was already loaded. You 
already know exactly that you're fine, you just need to run a bit of 
code ahead of the inner payload.

The conclusion is the same: Instead of loading another binary, you want 
to just jump into the one that's already loaded.

> I think that would both result in a more robust system (no more
> interfering with firmware PE loader mechanisms), and would address
> this shim mess too.
>
> There is prior art around. Most importantly this:
>
> https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_image_loader.c
>
> It was written 10y ago by Alex. We'd need a dumbed down version of that,
> i.e. without the Authenticode/pkcs7 stuff. And our inner image is
> already in memory, hence we don't need that either.
>
> We already have PE parsers in our EFI code, we use it to find the UKI
> sections after all, hence this wouldn't even add completely new PE
> logic to our tree. It would just have to do the section relocation,
> and then jump to the PE entrypoint of the inner image.
>
> Would love a patch for that!

+1

Alex