On 3/20/25 17:36, Luca Boccassi wrote:
On Thu, 20 Mar 2025 at 14:46, Alexander Graf <graf@xxxxxxxxxx> wrote:
On 20.03.25 13:08, Luca Boccassi wrote:
On Thu, 20 Mar 2025 at 11:00, Mate Kukri <mate.kukri@xxxxxxxxxxxxx> 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.
+1. The growth future of any distro depends on __ at least the
installer images __ 'just working the first time' whether the laptop,
desktop or widget has secure boot on or off.
Afterward, once installed, methods used by that installed code can vary,
and have the advantage of being configured by the installer that has
data about the instance. I advise forcing the average desktop/laptop
user to deal with the bios at any point in the process puts that distro
on a path to exclusion from being tried at all by the general user --
who in the years that follows becomes the developer, specifier in their
organization, etc. Nagging the user that 'it would be better if the bios
were set to X' is ok. But __installer images__ have to 'just work out
of the box'.
