Conversation

Mar 18, 2021

Interesting thread on trade-offs for ARM64 memory mappings with security mitigations. I personally also like PAC (CC

) because of the potential to protect much more than the stack and return pointers. usenix.org/conference/use is an excellent step towards that (

Quote Tweet

Linux on 64-bit ARM is most commonly used with 4k pages and 3-level page tables. This results in a 39-bit address space rather than the full 64-bit address space. It's possible to use 4-level page tables and then you get a 48-bit address space like you typically have on x86_64.

Show this thread

Replying to

and

Detecting memory corruption of data directly with memory tagging goes a long way and overall I'd rather have more memory tagging bits and more address space for shadow regions, quarantines, etc. Deterministic memory tagging can't be bypassed by information leaks or brute force.

Replying to

So, for example, you can reserve tags for marking free data, shadow stacks or other internal metadata, 16 byte granularity hardware canaries rather than 4k pages and other memory. Can either use hardware canaries or guarantee adjacent allocations have different tags, and so on.

Replying to

39-bit address is already very inadequate for GrapheneOS due to using strict partitions for different size classes in hardened_malloc along with quarantining the address space for large allocations. This is already going to be impractical to keep doing without more address space.

Replying to

39-bit address space is 512GiB with 256GiB for userspace. 48-bit address space is 256TiB with 128TiB for userspace. It's quite the difference. Consider having 100 classes of data where you want to reserve enough address to avoid ever mixing it between them. 39-bit isn't enough.

Replying to

So, even aside from growing memory usage of applications, there are many other uses for more address space such as dividing up the allocations for data with function pointers and data without them. Splitting things up this way isn't only a probabilistic mitigation either.

Replying to

I find it frustrating to have a security feature that's heavily in conflict with other security features. Using pointer authentication properly on GrapheneOS will probably mean needing to give up on current security properties. Larger pages aren't an option without app support.

Replying to

256GiB is a much smaller amount of address space than it might seem and I fully expect that other use cases beyond security are going to start finding it an annoying limit. So, we'll probably make sacrifices to keep 39-bit address space viable but it eventually won't be anyway.

10:23 AM · Mar 18, 2021Twitter Web App