On Tue, 22 Aug 2023 at 09:53, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Tue, 22 Aug 2023 at 04:01, Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > > > Hi Ard, > > > > On Fri, Aug 18, 2023 at 01:37:13PM +0200, Ard Biesheuvel wrote: > > > > <snip> > > > > > Ard Biesheuvel (11): > > > efi/x86: Move EFI runtime call setup/teardown helpers out of line > > > efi/arm64: Move EFI runtime call setup/teardown helpers out of line > > > efi/riscv: Move EFI runtime call setup/teardown helpers out of line > > > efi/runtime-wrappers: Use type safe encapsulation of call arguments > > > efi/runtime-wrapper: Move workqueue manipulation out of line > > > efi/runtime-wrappers: Remove duplicated macro for service returning > > > void > > > efi/runtime-wrappers: Don't duplicate setup/teardown code > > > acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers > > > efi/runtime-wrappers: Clean up white space and add __init annotation > > > efi/x86: Realign EFI runtime stack > > > efi/x86: Rely on compiler to emit MS ABI calls > > > > I took this series for a spin on my arm64 and x86_64 systems that boot > > under EFI. I noticed two issues for x86_64, none for arm64. I was hoping > > to have a little more information by this point but I had some personal > > stuff to deal with today but I figured I would report this initially > > and if you want to continue on the ClangBuiltLinux issue tracker, we > > certainly can. > > > > 1. I see some kCFI failures with this series on x86_64. The fact that > > the target is not a symbol makes me think that a function defined in a > > .S file is being called indirectly? The following stacktrace is repeated > > over and over on all my machines. > > > > This has to do with the indirect calls being made by the EFI code to > the firmware services, which are not part of the kernel build. > > Before, those indirect calls were hidden from the compiler, as they > were made from assembler, but now they are generated by the compiler, > and so we have to inform it that those functions do not have kCFI > metadata. > > The below should have fixed it, but I am getting lots of build errors > along the lines of > > error: '__no_sanitize__' attribute only applies to functions, > Objective-C methods, and global variables > > when I add this. Suggestions welcome on how to inform the compiler > that calls via those function pointers should have __nocfi semantics. > OK, so it is a property of the caller, not the callee. So it is simply a matter of marking every user of the EFI runtime services with __nocfi. So basically, every routine marked __efi_realign_stack should be marked __nocfi as well.
