[HN Gopher] ARM Pointer Authentication [2017]
       ___________________________________________________________________
        
       ARM Pointer Authentication [2017]
        
       Author : sacheendra
       Score  : 48 points
       Date   : 2022-08-30 14:51 UTC (8 hours ago)
        
 (HTM) web link (lwn.net)
 (TXT) w3m dump (lwn.net)
        
       | alain94040 wrote:
       | Protection was partially hacked with: https://pacmanattack.com
        
         | olliej wrote:
         | 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]
        
           | Syonyk wrote:
           | 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.
        
             | pjmlp wrote:
             | They could have tried SPARC ADI instead.
        
               | AceJohnny2 wrote:
               | only available _ARM_ chip with PAC.
        
       | wyager wrote:
       | PAC has been a total pain in the ass for iOS exploit devs. Seems
       | to be working pretty well there.
        
       | conradev wrote:
       | > 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 wrote:
       | Why just use separate stacks for code and data if you can
       | engineer a more complicated solution with higher overhead?
        
         | chc4 wrote:
         | ARM pointer authentication can be used for all pointers. Shadow
         | stacks only protect against overwriting the return pointer.
        
         | Findecanor wrote:
         | 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>
        
       | dmytrish wrote:
       | Please add [2017]
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2022-08-30 23:01 UTC)