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

[Alexander Graf]

On 20.03.25 23:36, Luca Boccassi wrote:
> On Thu, 20 Mar 2025 at 14:46, Alexander Graf <graf at amazon.com> wrote:
>> On 20.03.25 13:08, Luca Boccassi wrote:
>>> On Thu, 20 Mar 2025 at 11:00, 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.
>>> Thanks for the heads-up - the reason we ended up in this situation is
>>> ultimately because we didn't coordinate with shim for this workaround,
>> Let's align on the fact that shim is a giant hack that should not exist
>> in the first place :). The only reason we have it is because for some
>> reason, people believe that having the same secure boot key for every
>> application in the world is a sensible security posture.
> I'm afraid we are not aligned on that - shim exists because hardware
> exists, non-tech-savvy users exist, and distributions exist, and the
> intersection of all three matters. I understand you focus on the VM
> case, which is very important and deserves its time and space, but
> it's only one part of the whole story. The solution for VMs and the
> solution for generalist distributions on end-user consumer hardware do
> not have to be the same, if there are reasons to diverge.
> The overwhelming feedback we got over the years in distros is that if
> users have to go mess with firmware settings in order to run Linux,
> they either give up or just disable secure boot and leave it off
> permanently, neither of which are desirable outcomes for us, hence the
> need for shim.


I don't dispute the need for shim, even though I would prefer a world 
where adding a distro key is as easy as running shim instead.

What I am challenging is that we need to always think of the "normal" 
case first, then shim comes as a second thought to work around the fact 
that "normal" is twisted on some systems. Anything we build in sd-boot 
must work with normal UEFI compliant environments, without shim.


>
>>> 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.


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.


Alex