Re: [PATCH 0/2] Sign the Image which is zboot's payload

[Jan Hendrik Farr <kernel@jfarr.cc>]

On 25 08:55:46, Ard Biesheuvel wrote:
> On Mon, 25 Sept 2023 at 03:01, Pingfan Liu <piliu@redhat.com> wrote:
>
> [...]
>
> > > 4. How can we debug the stubs that are being invoked?
> > > 5. Can we let the EFI binary know that this is a kexec and not a normal
> > > bootup. Potentially systemd-stub would want to change how/if it does TPM
> > > PCR measurements.
> > > ...
> > >
> >
> 
> Not sure whether this matters. The TPM logic is exposed via EFI
> protocols, and the kernel could either expose them or not. If it does,
> and we execute the EFI stub (sytemd-stub) code all the way through to
> ExitBootServices() while executing in the old kernel, we could even
> take PCR measurements and display them, giving us secure and measured
> boot for kexec.
> 

I think we should definitely delay any of the measurements until
ExitBootServices(). We don't wan't measurements of a kernel that is not
running and might even get unloaded before being kexec'ed to make their
way into the TPM.

> > Besides these questions, I wonder whether a highly configured EDK2 can
> > be used as the stub (ArmVirtQemuKernel.dsc can be the start point).
> > But there should be efforts to exclude the drivers which have the MMIO
> > access. I saw Ard is active in EDK2, maybe that is the reason why he
> > did not pick up EDK2 to serve the stub.
> >
> 
> I don't think EDK2 is suitable for this - the code style is different,
> the license is different and it is simply a lot of code.
> 
> What I would prefer is to define a subset of the EFI boot services
> that we actually rely on, and perhaps even introduce some other
> constraints on the EFI code, e.g., allow it to run unprivileged.
> 
> That way, kexec could execute the EFI stub as an ordinary user process
> (to some extent), including allocations for the decompressed kernel,
> initrd, etc. Finally, the only thing purgatory would need to do is
> linearize the populated regions in the VA space and copy them to
> physical memory.
> 
> This all sounds very high-level, and there may be some difficulties
> down the road, but I think this deserves a proper look because it is
> an appealing way to make EFI execution idempotent in the context of
> kexec, and also reduces the arch-specific logic substantially.

I just started work on a proof-of-concept implementation of this [1]. It's
kinda unorganized and early right now though. Currently just testing with
executing a bzimage with the normal EFI stub on x86. At this point it starts
executing the EFI stub which checks efi_system_table->hdr.signature for the
correct signature (which I have not set yet). That causes the EFI stub to
exit. It does correctly call the exit function from my provided boot services
table and the correct ExitStatus gets logged in dmesg. So it's able to call
into my boot services correctly.

This is definitly the most low level code I've ever written though, so
I'm just learning this stuff.

Next I'll work on setting up a proper memory mapping for the EFI
application.

After that I'll work on implementing the needed boot services and
protocols.

[1] https://github.com/Cydox/linux/commits/kexec-uefi

--

Jan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel