Re: [PATCH v2 0/4] Allows Secure Boot for Kexec

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/05/2025 10:42 am, Frediano Ziglio wrote:
> Ross Lagerwall (4):
>   xen/lib: Export additional sha256 functions
>   kexec: Include purgatory in Xen
>   kexec: Implement new EFI load types
>   kexec: Support non-page-aligned kexec segments

I realise a lot of this is coming from kexec-tools and/or Linux, but it
looks very very mad.

>From patch 1, we're embedding this in Xen:

xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
-rw-r--r-- 1 andrew andrew 30K May  9 15:24 purgatory.ro

yet -Wa,--strip-local-absolute alone halves the size:

xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
-rw-r--r-- 1 andrew andrew 17K May  9 15:25 purgatory.ro

Looking at purgatory itself, we enter at purgatory_start, load a local
GDT, set up a local stack, call into C for the hashing (and nothing
else), then jmp to entry64...

... which loads a (different) local GDT, (different) local stack, loads
the GPRs and then jumps into the new kernel.

Combined with kexec_reloc(), that's 3x we change GDT and stack in
several hundred instructions.


Looking further at patch 2, we only set up 3 GPRs; %rip, %rsp and %rdi
pointing the parameter block.

Patch 2 also contains an a large amount of EFI-editing logic (all
vulnerable to XSA-25), which AFAICT exists only because purgatory is
built non-PIC and wants relocating.  I can't see any external
references, or anything that couldn't be resolved at link time for a PIC
build.


There are two things which purgatory does which Xen doesn't currently
cater for:

1) Setting up the GPRs in that manner
2) The digest checks

#1 is very easy to fix and can probably even be done on the current ABI
(older Kexecs using purgatory won't care), and #2 ought to be easy too
by extending machine_kexec().  We can do the digest checks
unconditionally (it's a sensible check irrespective).

I think that removes the majority of this series, with no loss in
functionality?

Given that we're leaving the signature check to the dom0 kernel (which
is TCB and therefore can in the UEFI-SB model), we just might be able to
get away without any hypercall changes at all?

Thoughts?

~Andrew