[PATCH] D85649: [AArch64] PAC/BTI code generation for LLVM generated functions

Thu Sep 24 06:00:00 PDT 2020

chill marked an inline comment as done.
chill added a comment.

In D85649#2282286 <https://reviews.llvm.org/D85649#2282286>, @nickdesaulniers wrote:

> Thanks @tejohnson for the feedback.  Error sounds fine. The only other question I have is that a common pattern in the Linux kernel for progressive support of the ARM ISA extensions is to build isolated translation units that either use those features unconditionally but wont call into those translation units at runtime if the extensions are not present, or the kernel will live patch itself (ie. "alternatives" patching).  Maybe @mrutland has thoughts; with BTI be runtime-patchable or otherwise enable-able at runtime.  ie. one kernel image that runs on hardware both with and without BTI ISA extensions?
>
> If the plan is to have isolated TUs built with BTI, then the "Error" policy sounds like this would be incompatible; but I don't think the point of BTI is to have some small portion of the code built with it.  IIRC, doesn't BTI uses the no-op encoding space? So I guess one image could run on hardware regardless of actual BTI hardware support.  So it wouldn't be patched in at runtime either.  In that case, via kernel config I guess we'd build everything with BTI, and have build time errors for translation units that accidentally dropped KBUILD_CFLAGS, which happens a lot, but is fixable in kernel's build system sources.
>
> The final piece of food for thought is ensuring that we can LTO C code built with BTI can link with out of line asm; Clang usually needs the assembler directives in place in the source being assembled to enable architectural extensions.  If "Error" policy is used, can we still LTO C and asm sources?  I assume we "should" be able to, but it might save trouble down the road to test that locally.  Particularly, having C code that calls asm routines and the visibility of those routines during LTO has given us trouble in the past, when enabling CFI (control flow integrity; which I believe has some overlap with BTI but some subtle differences as well; I wouldn't call them perfect substitutes).

Yes, PAC/BTI can be done entirely in NOP-space, controlled by `-march=...` - if the architecture revision does not have an instruction, a NOP-space equivalent is used.
For the C/ASM link  I couldn't see any issues with my basic testing with `lld`.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85649/new/

https://reviews.llvm.org/D85649