|
|
Subscribe / Log in / New account

Some near-term arm64 hardening patches

Some near-term arm64 hardening patches

Posted Nov 19, 2019 13:28 UTC (Tue) by xnox (guest, #63320)
Parent article: Some near-term arm64 hardening patches

About Return address signing, can an attacker not like request to sign all possible pointer addresses and store all of them on disk, then corrupt return address and the load the matching signature from disk?

What is used to sign the pointers?


to post comments

Some near-term arm64 hardening patches

Posted Nov 19, 2019 14:30 UTC (Tue) by Paf (subscriber, #91811) [Link] (3 responses)

“All possible pointer addresses and store them on disk”
No, since that’s some pretty large fraction of 2^64.

The question of what’s used for signing and where it’s kept is still interesting, though.

Some near-term arm64 hardening patches

Posted Nov 19, 2019 17:53 UTC (Tue) by brouhaha (subscriber, #1698) [Link] (2 responses)

Since the 64 bits of a pointer is being partitioned into some upper bits for the signature, and the remaining lower bits for the virtual address, if you know the virtual address you're interested in you only have to try 2^(signature_width) possibilities. So if the split is e.g. 16 bits for the signature and 48 bits for the virtual address (a common virtual address size on 64-bit processors), that will only require on average 32768 attempts to brute-force the right signature for a given address.

Despite 2^64 being a rather big number (over 18 million TiB), I am still reminded of all the times that people have in the past abused the high bits of addresses thinking that they will never be needed for actual addresses. Two notable examples are IBM mainframes and the Motorola MC68000, both of which originally only used the low 24 bits of addresses, so the high parts were often used for other stuff, which caused huge problems when they expanded the address size (to 31 bits for System/370-XA and MC68012, 32 bits for MC68020).

Some near-term arm64 hardening patches

Posted Nov 20, 2019 1:01 UTC (Wed) by Paf (subscriber, #91811) [Link]

Ah, I misunderstood - I (incorrectly) read this as pointer encryption, but this is just signing with something stuck in the upper bits. (Clearly described in the article, in some lines I clearly skipped.)

Then, yes, you’re absolutely right, it’s not that large a space at all.

Some near-term arm64 hardening patches

Posted Nov 20, 2019 11:31 UTC (Wed) by james (subscriber, #1325) [Link]

I am still reminded of all the times that people have in the past abused the high bits of addresses thinking that they will never be needed for actual addresses. Two notable examples are IBM mainframes and the Motorola MC68000 [...]
You're missing a much more up-to-date example, ARM64 itself, which has had pointer tagging built in from the beginning.
The kernel configures the translation tables so that translations made via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of the virtual address ignored by the translation hardware. This frees up this byte for application use.
-- https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt

(Also, early ARM used the top six bits of the program counter for status flags and the bottom two bits for mode flags, making it faster to save state when handling interrupts.)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds