Hacker News Reader

Comment by uniqueuid | Hacker News Reader

I'd be interested to hear from someone with deep security knowledge:

Some people have dismissed OpenBSD's mitigations as overhyped (i.e. - things like W^X are not the main problem, linux has long caught up, etc).

But now we see Apple adding precisely some of these mitigations.

Where does this leave such architectural countermeasures? Are there real gains from investing in such low-level things? Are they irrelevant in an age where many laptops still have ports that give direct DMA access, users are not savvy and sandboxes incomplete?

View on HN

W^X is a good mitigation to prevent attackers from just spraying shellcode into a RWX heap. This is how most JIT engines used to be attacked, and many exploits continue to include WebAssembly just because Chrome will create a RWX arena for this. Many of the OpenBSD mitigations are actually a good idea, but some are fanciful junk. The posture that the team has towards pushing those latter ones is what generally makes people unhappy.

Also, do note that Apple silicon puts everything behind a DART (essentially an IOMMU). This is noted in the article:

> Device isolation was another M1-only feature, that uses the more powerful IOMMU of that platform to make sure hardware devices can only share memory with the operating system and not with each other. Cross-device memory sharing is a historical custom, based on a blind, unfounded trust in hardware.

>The posture that the team has towards pushing those latter ones is what generally makes people unhappy.

Well, pledge and unveil work fine.

Obviously those two fall in the former.

So what mitigations are "fanciful junk" exactly, and was that actually known before or just poo-poo'd the way basically everything the openbsd folks introduce is?

Trapsled?

Which mitigations exactly?

macOS has enforced W^X in most cases for many years.

As for the two mitigations mentioned in the article:

NO_SMT seems to be equivalent to Linux's "core scheduling" feature, which landed recently [1]. This approach, involving disabling SMT (aka hyperthreading) for specific processes, is different from OpenBSD's more brute-force approach of disabling SMT systemwide; there are pros and cons to both approaches.

As for the other one, forcing VERW to be executed on every return from the kernel, both Linux and OpenBSD chose the brute-force approach of doing this for all processes by default; both added this feature in 2019 as part of the coordinated disclosure of the MDS vulnerability class. Apple is instead doing it on a per-thread basis. Again, pros and cons.

[1] https://lwn.net/Articles/861251/

(To provide more context, before the new APIs Apple used to flip actual page memory protections, which required going through the kernel. The new SPRR APIs allow for essentially the same thing, except they work per-thread and just set a register accessible from userspace that essentially applies an extra mask on the permission bits, which is much faster.)

It’s clear that W^X isn’t “solving security”, but it’s not a bad idea just because it’s a low-hanging fruit. On Apple platforms, I think that it came to be as a natural consequence of the ability to toggle RX mappings to be RW without a syscall.

Almost all DMA-capable peripherals on Apple Silicon (including iDevices) are gated behind an IOMMU.

Reply on news.ycombinator.com