6 ms·
ARM Pointer Authentication [2017]
- alain94040 4y agoProtection was partially hacked with: https://pacmanattack.com https://pacmanattack.com
- olliej 4y agoThat 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]
- Syonyk 4y agoIf 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.
- pjmlp 4y agoThey could have tried SPARC ADI instead.
- AceJohnny2 4y agoonly available _ARM_ chip with PAC.
- wyager 4y agoPAC has been a total pain in the ass for iOS exploit devs. Seems to be working pretty well there.
- dmytrish 4y agoPlease add [2017]
- deleted 4y ago[deleted]
- conradev 4y ago> 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?
- mike_hock 4y agoWhy just use separate stacks for code and data if you can engineer a more complicated solution with higher overhead?
- chc4 4y agoARM pointer authentication can be used for all pointers. Shadow stacks only protect against overwriting the return pointer.
- Findecanor 4y agoThe "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 https://clang.llvm.org/docs/SafeStack.html> [2] <https://en.wikipedia.org/wiki/Register_window https://en.wikipedia.org/wiki/Register_window>
- chowyuncat 4y agoHow do register windows differ from register renaming? https://en.m.wikipedia.org/wiki/Register_renaming https://en.m.wikipedia.org/wiki/Register_renaming
- colejohnson66 4y agoRegister 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.