ARM Pointer Authentication [2017] | Hacker News Reader

ARM Pointer Authentication [2017]

lwn.net

62 pointssacheendra14 comments

Protection was partially hacked with: https://pacmanattack.com

That is Apple silicon specific (at least for now?) as it isn’t a behaviour inherent to the ISA but rather it is yet another cache related side channel. It is of course entirely possible that other vendors will have the same info leak, but that particular paper seemed to be only interested in Apple hardware - I’m unsure how widely deployed PAC is in other vendor hardware so don’t know how feasible testing is.

[edit: this is also a 2017 article (I hadn't realized originally, cheers @dmytrish) so the gcc, etc support comments are presumably outdated]

If I recall that paper properly, they chose to do their work on the M1 because it was the only available chip with PAC at the time.

They could have tried SPARC ADI instead.

only available _ARM_ chip with PAC.

PAC has been a total pain in the ass for iOS exploit devs. Seems to be working pretty well there.

Please add [2017]

Why just use separate stacks for code and data if you can engineer a more complicated solution with higher overhead?

The "SafeStack" [1] scheme is probably the most well-known that does that. The "safe" stack is the normal stack, and the "unsafe" stack contains all automatic variables that could get dereferenced - including arrays that could overflow. The security of the scheme depends on keeping the location of the safe stack secret, which for one thing means that all code in the program needs to use the SafeStack ABI. It is used more or less in several BSD Unices (most notably HardenedBSD), and it is the default in Fuchsia (except when the program was written in Go).

CPU architectures that have register windows [2] tend to spill shifted-out registers onto a separate stack lazily, and those registers could contain the return pointer.

[1] <https://clang.llvm.org/docs/SafeStack.html>

[2] <https://en.wikipedia.org/wiki/Register_window>

An interesting trick pioneered I think on OpenBSD was to encrypt the spilled stack. Even simple XOR was enough to prevent easy manipulation of stack by malware.

How do register windows differ from register renaming? https://en.m.wikipedia.org/wiki/Register_renaming

Register renaming is a microarchitecture feature; your OS can be completely oblivious to them because it has no way of using (or even knowing in many cases) them. Register windows, OTOH, require the OS to be aware of the “spill stack”. The difference is also in their purpose: register renaming is for OOO superscalar execution pipes to allow multiple operations at once; register windows are an attempt to avoid pushing “clobbered” registers to the stack when calling functions.

Nothing precludes an architecture from having both: register windows to avoid register clobbering and register renaming to allow dozens/hundreds of micro-ops “in flight” at the same time.

ARM pointer authentication can be used for all pointers. Shadow stacks only protect against overwriting the return pointer.

> For the time being, the feature is only provided for user space; it is not yet used within the kernel itself

Does anyone know if that is still the case?

Reply on news.ycombinator.com