On 09/05/2025 4:04 pm, Andrew Cooper wrote: > 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?
Sorry, one extra thing. By doing the digest check in machine_kexec(), we can also inform the user that the kexec kernel looks corrupt, and we won't be entering it. (And probably try to reboot rather than hanging too.) ~Andrew
