LWN: Comments on "Some near-term arm64 hardening patches"

Some near-term arm64 hardening patches

mwsealey — Mon, 06 Apr 2020 17:50:07 +0000

Speculative accesses aren't permitted to cause exceptions, so constant time or not to cause a 'level 0 fault' makes no difference.

Some near-term arm64 hardening patches

rgmoore — Wed, 20 Nov 2019 17:15:39 +0000

hardening helps cloud-provider megacorps while the latter would help average people avoid get their passwords guessed/phished all around the world.

This is a nonsensical distinction. One of the things those "cloud-provider megacorps" are doing is handling data that affects millions of "average people". That makes them an incredibly tempting target for hackers, because it means they can steal information wholesale instead of retail. I very much want those big companies to put serious effort into protecting their data.

Some near-term arm64 hardening patches

roc — Wed, 20 Nov 2019 11:47:31 +0000

To be clear: hardening Linux, Android and client software in general against exploitation definitely helps block attacks against the cheap phones of "average people" all around the world, and it also helps block attacks against the services those people depend on (whether they know it or not).

And FWIW, the "cloud provider megacorps" have a keen interest in improving security UI/UX just as much as preventing software exploitation. AWS lets me use my phishing-proof Yubikey for authentication, but my bank doesn't yet :-(.

Some near-term arm64 hardening patches

roc — Wed, 20 Nov 2019 11:41:13 +0000

A lot of energy is going into password managers (e.g. Firefox Lockwise), security keys (Yubikey etc), FIDO/WebAuthn, etc etc, and efforts to promote the deployment of that tech, to bypass the password problem. None of that is worth much if the users' software is easily hijacked by malicious input.

We have to solve the UX issues *and* we have to solve the fragile software issues. The resources to address the latter (e.g. kernel developers) aren't easily repurposed to tackle the former, and even if they were, where's your *proof* that that would be the right thing to do? Postulating a conspiracy theory isn't proof.

Some near-term arm64 hardening patches

james — Wed, 20 Nov 2019 11:31:29 +0000

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.)

Some near-term arm64 hardening patches

nhippi — Wed, 20 Nov 2019 09:03:29 +0000

Imagine if most of the energy spent in low-level hardening would be put in improving usability of password managers 2fa and other security UI/UX issues? Of course that isn't happening, because hardening helps cloud-provider megacorps while the latter would help average people avoid get their passwords guessed/phished all around the world.

Some near-term arm64 hardening patches

Paf — Wed, 20 Nov 2019 01:01:16 +0000

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

brouhaha — Tue, 19 Nov 2019 17:53:52 +0000

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

Paf — Tue, 19 Nov 2019 14:30:40 +0000

“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

xnox — Tue, 19 Nov 2019 13:28:25 +0000

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?

Some near-term arm64 hardening patches

SethT — Tue, 19 Nov 2019 00:04:53 +0000

Tolvanen's cover letter quote (and this article) doesn't explicitly define PAC which is Pointer Authentication Code which was outlined but not named by abbreviation in the Return-address signing section

Some near-term arm64 hardening patches

nivedita76 — Mon, 18 Nov 2019 23:58:36 +0000

The documentation and the commit message should probably make that first bit more explicit -- i.e. that /speculative/ accesses are indeed prevented.

Reading the commit message as it stands doesn't give any indication as to why E0PD would prevent Meltdown, as it only mentions constant-time faulting.

Some near-term arm64 hardening patches

roc — Mon, 18 Nov 2019 21:49:52 +0000

That's true. I had assumed return-address-signing was going to take care of ROP.

Some near-term arm64 hardening patches

mjg59 — Mon, 18 Nov 2019 21:35:17 +0000

Phew, I'll let our security monitoring teams know that none of the attacks they see actually exist.

Some near-term arm64 hardening patches

luto — Mon, 18 Nov 2019 21:22:44 +0000

A sufficiently strong shadow stack implementation also makes ROP nearly impossible, and doing *something* to protect return addresses is an important part of CFI.

Some near-term arm64 hardening patches

dvdeug — Mon, 18 Nov 2019 21:02:59 +0000

In 2019 BC, robbers would kick down doors to enter houses or rob people at knife point. In 2019 AD, they still do. In 2014, the security on the Nintendo 3DS was broken because the Cube Ninja game didn't bounds check data downloaded from the Net. In 2019, Exim had a remotely exploitable buffer overflow (CVE-2019-16928). There may be fancy new hacks, but people will use whatever works, be it old or new.

Some near-term arm64 hardening patches

roc — Mon, 18 Nov 2019 20:53:24 +0000

Exploiting memory safety bugs is a huge business. Other kinds of security bugs may or may not be more numerous, but that has no impact on the cost/benefit analysis of these mitigations.

It is true that stack buffer overflows are quite uncommon these days, so you could argue that shadow stacks aren't worth the complexity.

Some near-term arm64 hardening patches

MarkRutland — Mon, 18 Nov 2019 20:35:10 +0000

The latest ARMv8-A manual describes E0PD in the section titled "Preventing EL0 access to halves of the address map", which summarises the feature:

If ARMv8.5-E0PD is implemented and enabled, the TCR_ELx.{E0PD0, E0PD1} fields can prevent unprivileged access to the addresses translated by TTBR0_ELx or TTBR1_ELx. If access is prevented, the fault is reported as a level 0 fault, and should take the same time to generate, whether the address is present in the TLB or not, to mitigate attacks that use fault timing.

Setting TCR_ELx.E0PD0 should prevent userspace (EL0) accesses to the kernel half of the address space (which is mapped via TTBR1_ELx), speculative or otherwise. The constant-time faulting behaviour should prevent page table depth probing attacks that can be used against KASLR.

Some near-term arm64 hardening patches

rweikusat2 — Mon, 18 Nov 2019 20:15:33 +0000

A message from 2019 to 1988: Real world security issues usually involve getting access to some entities customer database by breaking into web site. The mad effort to blast the body of already completely dead Morris worm into subatomic particles can thus be halted as "no value for money".