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.

9:53 AM · Mar 18, 2021Twitter Web App

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.

Show replies