On 26.11.2021 17:38, Andrew Cooper wrote: > --- a/xen/arch/x86/efi/stub.c > +++ b/xen/arch/x86/efi/stub.c > @@ -11,6 +11,8 @@ > #include <efi/efidevp.h> > #include <efi/efiapi.h> > > +bool __initdata efi_no_cet_ibt;
I'm having trouble seeing what this is needed for - when this file gets built, neither boot.c nor runtime.c will get compiled, and hence there should not be any reference to the symbol that needs satisfying. > @@ -735,6 +736,14 @@ static void __init efi_init(EFI_HANDLE ImageHandle, > EFI_SYSTEM_TABLE *SystemTabl > > StdOut = SystemTable->ConOut; > StdErr = SystemTable->StdErr ?: StdOut; > + > +#ifdef CONFIG_X86 CONFIG_XEN_IBT? > + /* > + * Heuristic. Look under an arbitrary function pointer to see if UEFI > was > + * compiled with CET-IBT support. Experimentally some are not. > + */ > + efi_no_cet_ibt = !is_endbr64(efi_rs->GetTime); I'm afraid I consider this insufficient. Even if the core EFI was built with IBT support, some driver may not have been. Hence I think there needs to be a command line control to force turning off IBT. The only question is whether we want to also honor its positive form - that would, afaict, be a recipe for a guaranteed crash if used wrongly (and it would be meaningless when used on IBT-aware firmware). Not only in context of such a command line option I'm also inclined to suggest to invert the polarity of the variable, naming it "efi_cet_ibt" (and the command line sub-option "no-ibt" or "no-cet-ibt"). Jan
