The 11/17/2020 10:17, Peter Collingbourne via Libc-alpha wrote: > On Tue, Nov 17, 2020 at 9:48 AM Florian Weimer <fw@xxxxxxxxxxxxx> wrote: > > > > * Peter Collingbourne: > > > > > This prctl allows the user program to control which PAC keys are enabled > > > in a particular task. The main reason why this is useful is to enable a > > > userspace ABI that uses PAC to sign and authenticate function pointers > > > and other pointers exposed outside of the function, while still allowing > > > binaries conforming to the ABI to interoperate with legacy binaries that > > > do not sign or authenticate pointers. > > > > > > The idea is that a dynamic loader or early startup code would issue > > > this prctl very early after establishing that a process may load legacy > > > binaries, but before executing any PAC instructions. > > > > I thought that the silicon did not support this? > > See e.g. the documentation for SCTLR_EL1.EnIA [1] for details. There > are also enable bits for the other three keys. i think it was insufficiently clear in the architecture spec how that can be context switched. (but it probably changed) > If you can avoid creating function pointers before the loader has > finished recursively scanning all libraries, and the ABI uses > different keys for function pointers and return addresses, you may be > able to get away with making the decision in the loader. The idea is glibc currently only supports pac-ret, so if we enable or disable pac keys it would be for pac-ret. (i.e. we would need to do the enable/disable logic in the dynamic linker entry code before c code is executed) > that you would disable the function pointer key and leave the return > address key enabled. This would also have the advantage of at least > providing return address protection for some libraries if function > pointer protection can't be enabled. > > > There is also an issue with LD_AUDIT, where we run user-supplied code > > (which might be PAC-compatible) before loading code that is not. I > > guess we could disable PAC by default in LD_AUDIT mode (which is > > unusual, no relation to the kernel audit subsystem). > > Yes, LD_AUDIT may be difficult to deal with if it can influence which > libraries are loaded at startup. I agree that LD_AUDIT should disable > PAC by default. > > Peter > > [1] https://developer.arm.com/docs/ddi0601/d/aarch64-system-registers/sctlr_el1#EnIA_31
