[WIP WIP WIP] Allow loading images that were embedded as sections inside a previously verified image

[kukrimate]

I have realised that the hashes cannot be stored inside loaded images because it would break old grubs that call shim_lock->verify() on a UKI and run it without loader proto.

Instead I create a global list of hashes of all sections of all images that were verified.

Then if someone tries to later verify an image that was previously hashed as a section, they get to pass.

Please note that this is WIP, and untested code, and was written in 30 minutes, but it should be a starting point.

[kukrimate]

WARNING: this is likely not secure.

The attack I have in mind is:

• I load UKI in GRUB, but not run it. This will add the embedded kernel to allowlist.
• Then I load embedded kernel separately in GRUB, and I can lunch it with an arbitrary command line and initrd, defeating the purpose of the UKI.

Only way to fix this would be to restrict the allowlist to current running image's sections, but that wouldn't work with existing GRUBs that don't use the loader protocol.

So I believe the only way to solve the regression with existing artefacts is to not hook the system table after all.

[bluca]

So I believe the only way to solve the regression with existing artefacts is to not hook the system table after all.

But that's still affected by the same case though? Because it would mean having to sign the inner kernel. But that means you can also just extract it and run it with an arbitrary initrd/cmdline combination.

[ardbiesheuvel]

WARNING: this is likely not secure.

The attack I have in mind is:

• I load UKI in GRUB, but not run it. This will add the embedded kernel to allowlist.

That just means that the allowlist should be augmented at StartImage() time, not before, and wiped again when the image returns.

[kukrimate]

@ardbiesheuvel

That just means that the allowlist should be augmented at StartImage() time, not before, and wiped again when the image returns.

I don't think that will work, because existing artifacts that only call into shim to do verify(), and start the image using their own mechanism, which means shim doesnt really know which image is really running

[bluca]

That's not the case? StartImage is used. There is a corner case with old kernels where the old efi handover protocol is used instead, but that's very much on the way out

[ardbiesheuvel]

@ardbiesheuvel

That just means that the allowlist should be augmented at StartImage() time, not before, and wiped again when the image returns.

I don't think that will work, because existing artifacts that only call into shim to do verify(), and start the image using their own mechanism, which means shim doesnt really know which image is really running

If shim's startimage is not used, we don't need this trick, right? And if it is used, it will be exposed via the loader protocol and hooked into the system table, and starting the uki image should always return via startimage, even when doing a longjmp from the exit boot service.

[ardbiesheuvel]

And if UKI currently passes the parent image handle correctly when loading the inner kernel, we could limit this to sections of the direct parent, rather than have a global view to which hashes are added and removed.

[kukrimate]

That's not the case? StartImage is used. There is a corner case with old kernels where the old efi handover protocol is used instead, but that's very much on the way out

@bluca Yes the stub itself does that, but if the loader that loaded the stub, didnt call StartImage() when starting it, shim simply does not know the stub is running.
This is the case for our current use case with GRUB+peimage in ubuntu.

If shim's startimage is not used, we don't need this trick, right? And if it is used, it will be exposed via the loader protocol and hooked into the system table, and starting the uki image should always return via startimage, even when doing a longjmp from the exit boot service.

@ardbiesheuvel well the problem is it's sort of used, the stub uses start image, but some bootloaders that start the stub itself (such as grub) might not, which means shim does not always know when the stub is started, even if it was used to verify it.