Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pointer Authentication

github.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Pointer Authentication

#41

Post by geocar »

yuubi wrote: post #32
zozbot234 wrote: post #23

Earlier quoted context omitted.

This is a whole-program transformation though, it doesn't seem to be possible to make it modular. Unless you manage to map some module-specific dispatch table whenever you're running code from that module - in a way that cannot easily be subverted by exploit code! Not sure how to do this however.

Have a section of callback pointers and check against the bounds of the section? G++ uses this mechanism for static constructors, but it's general purpose (Linux uses it to collect lists of drivers to initialize, for instance, with macros like IRQCHIP_DECLARE that populate a section for each type of entity, which then gets scanned at boot time). You would need a linker script to collect the callbacks into a section a…

gcc (ld actually) makes __start_sort_callbacks and __end_sort_callbacks for you, so you shouldn't need a custom linker script.

Re: Pointer Authentication

#42

Post by ComputerGuru »

loeg wrote: post #19
ChrisSD wrote: post #15

Earlier quoted context omitted.

SHA-2 isn't outdated if used correctly (e.g. combine with HMAC if length extension attacks are a threat to your protocol). SHA-3 is the "break glass in case of emergency" hash.

Doesn't even need HMAC to break length extension. You can just truncate the result ("SHA-512/256"), or use SHA_d(x) = SHA(SHA(x)) or SHA(0^B || SHA(x)). (Although SHA_d starts to look a lot like HMAC.)

Absolutely but it’s all besides the point for this particular application, anyway. If you fix the pointer size (e.g. payload (i.e. both the secure and raw pointers) must be 64 bits, no less, no more) then length extension is a non-issue.

(Rebuttal: Some languages have fat pointers or maybe some architectures support 32-bit binaries.. I think having the key tied to the payload size would address the theoretical weakness there? In practice signed pointers are already fat pointers and the contents of fat pointers are not actually addresses in the first place, and neither are supported in the current implementation.)

Re: Pointer Authentication

#43

Post by rurban »

SAI_Peregrinus wrote: post #40
rurban wrote: post #38

Earlier quoted context omitted.

Nope. ptrauth needs a good hash in Hardware. There's only crc32c, aes, sha1 (-160) and sha256 (i.e. sha2-256). Of these crc32c is entirely insecure, aes not applicable, so we are left with AMD, Intel laptops (Goldmont), armv8 and Power8. For sure we don't care about any SHA vulnerabilities here, only about speed. Blake2 is about a factor of 1000 slower. Secure hashes are not really applicable for pointer hashing (i.e…

SHA3 is designed to be quite fast in hardware, there just isn't much hardware that accelerates it yet. Blake2 is faster in software, but that software is (as you note) much slower than SHA2's hardware implementations. So for existing systems SHA2 is the best option. Eventually SHA3 will probably be widespread and SHAKE128 with appropriately chosen output size will be the best choice.

SHA2 is by far not the best option for ptrauth. The best option is HW and API dependant. There are dozens of better options. I recently included most secure hashes with tons of variants into https://github.com/rurban/smhasher/blob/master/README.md#smh... SHA3 would be atrocious. Something like fletcher2 or wyhash seem to be best.

Re: Pointer Authentication

#44

Post by kjs3 »

EddieCPU wrote: post #7

Is it technically possible to design a MMU that prevents a process reading or writing to a region of memory that don't belong to it?

Yes; you're looking for 'capability based MMU'. The Intel i960MX/MC MMU had one, and development tools to support it (mostly in Ada). Unfortunately, Intel stripped/disabled the MMU in the vast majority of i960s it shipped and really only sold the MMU version in the military market.

Re: Pointer Authentication

#45

Post by rjmccall »

saagarjha wrote: post #39
rjmccall wrote: post #29

Earlier quoted context omitted.

They can be compatible. Memory tagging does use the TBI bits. Pointer authentication uses an arbitrary number of bits, and the kernel configures the width and whether the TBI bits are preserved. So you can use both, it just costs you 8 bits of signature. Moreover, this can be configured independently for code and data pointers. iOS turns off TBI on code pointers to get 8 more bits of signature. That's not a problem f…

> Moreover, this can be configured independently for code and data pointers. iOS turns off TBI on code pointers to get 8 more bits of signature. Ooh, this is cool. Does iOS currently use different signature sizes? Can I write an application that uses the top bits of data pointers?

> Does iOS currently use different signature sizes?

Code and data live in the same address space, and the address-space needs of the system are the main input to the basic signature width, so the basic signatures widths are currently the same, and the only difference is TBI.

You could imagine a system where code was always loaded into a restricted subset of the address space and so code pointers could use wider signatures.

> Can I write an application that uses the top bits of data pointers?

Apple's ABIs actually consider the top 8 bits of data pointers to be outside the addressable range on all its 64-bit targets, including x86_64. ARM64 TBI just means that you don't need to explicitly mask off those bits before doing loads and stores. But there are caveats:

- ARMv8.5 memory tagging uses bits 56-59, so you should probably stick to just the top four bits in case Apple ever uses memory tagging.

- IIRC the first ARM64 iOS release didn't enable TBI, so if your deployment target goes really far back, you do still need to mask.

- The ABI for pointers expects those bits to be clear on normal ABI boundaries. This means you need to mask before handing pointers off to other code; on the upside, however, you don't need to worry about those bits being set when you receive a pointer.

Post reply on HN