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