I can’t make it today Aug 14th, but should be able to next week. In the meantime I’m on discord as my real name, feel free to ping me there!
Glad you were able to join Discord. Do you have anything to add to today’s pauth meeting? Any progress on frontend / midend patches?
Thanks!
Dear All,
We are happy to provide the very first proof-of-concept branch of LLVM+clang+runtime libraries that includes pointer authentication support for ELF targets.
Everything is based on top of downstream branch by @ahmedbougacha with ELF support patches on top as well as some bug fixes.
There is also a patch for MUSL that adds support for pauth ELF relocations: [AArch64] Add initial support for PAC relocs by eleviant · Pull Request #1 · access-softek/musl · GitHub
We verified that LLVM testsuite compiled with pauth successfully passes on pauth-enabled AArch64 board.
Notes and known issues:
- There is some code generation instability (different, albeit correct, code is generation on Linux and Mac hosts)
- Complete LLDB support is currently WIP. For now stack tracing, etc. only works until the first signed pointers
- Some things are not yet decided / implemented (e.g. emission of
.notesections, when / how one would check them inside dynamic loader, etc.). - Relocation numbers are used from the still unmerged AArch64 ELF ABI pull request: [AAELF64][PAUTHABI64] Assign PAuthABI relocation codes. by smithp35 · Pull Request #227 · ARM-software/abi-aa · GitHub
Eventually all patches will be a part of LLVM mainline, however, there are some roadblocks that need to be broken. Please let us know if there are any issues, etc. with the code provided.
1 Like
I’m a bit surprised by this because we do support unwinding on Linux when mbranch-protection is used (https://github.com/llvm/llvm-project/tree/main/lldb/test/API/functionalities/unwind/aarch64_unwind_pac). I assume there’s more to this than just that.
This was added back in ⚙ D99944 [LLDB] AArch64 Linux and elf-core PAC stack unwinder support and there’s been a whole bunch of other fixes for stuff like memory reading (I did a roundup for it here).
Also since then we moved the AArch64 lldb buildbot to Pointer Auth enabled hardware, so if you add a test case it is being checked regularly.
Let me know if you need any help with it and of course I can review any patches.
@akorobeynikov Does this implementation require hardware support or is there a fallback software implementation?
Thanks, David!
We are checking all the bits here and there. Sometimes there are just some corner cases that needs to be fixed after the main functionality is there.
Certainly the fixes (if any) will be submitted to the LLVM / LLDB mainline.
Stay tuned!
1 Like
Currently it definitely assumes there is a hardware support for this. However, there is a pass that lowers corresponding intrinsics to the runtime function calls. It is not currently hooked to anything though 
I tried using QEMU (both full-system and user-mode emulation) on x86_64 host and it looks usable, at least for quick local experiments. I use CPU model/settings max,pauth=on,pauth-impdef=on. In my setup, enabling PAuth with the default QARMA5 algorithm (such as if switching from CPU model cortex-a72 to max) makes execution several times slower and using not secure pauth-impdef algorithm instead (as explained in QEMU documentation) only slows things down by about 30% (compared to disabled PAuth) while still inserting some PAC values.