Top
Best
New

Posted by circuit 4 days ago

Memory Integrity Enforcement(security.apple.com)
500 points | 234 commentspage 3
pjmlp 3 days ago|
This is great, since Oracle introduced SPARC ADI, into Solaris and their Linux SPARC workloads that I keep looking forward to "C Machines" becoming a common way to fix C language issues.

Unfortunately, like in many other cases, Intel botched their MPX design, only evolutions of MTE and CHERI are around.

rudedogg 3 days ago||
The tagging mechanism reminds me of generational indices like https://floooh.github.io/2018/06/17/handles-vs-pointers.html, but I’m a bit out of my depth
rdtsc 3 days ago||
1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas !

But yeah this was support for a the longest time by IBM basically. It's nice to see it's getting more widespread.

bri3d 3 days ago||
The problem with PowerPC AS tagging was that it relied entirely on the trap instruction. If you could control execution at all, you could skip the trap instruction and it did nothing. This implementation, by my reading, essentially adds a synchronous trap instruction after every single load and store, which builds a real security boundary (even compared to Android MTE, where reads would trap but writes were only checked at the next context switch).
rdtsc 2 days ago||
Yeah, the security part wasn't baked into the hardware. It relied on the OS (it ran a virtualization layer of sorts) to enforce it via traps if it set those traps.

From https://www.devever.net/~hl/ppcas

> As such, they can principally be viewed as providing a performance enhancement for the IBM i operating system, which uses these instructions to keep track of pointer validity. It is the IBM i OS which enforces security invariants, for example by always following every pointer LQ with a TXER.

pyth0 3 days ago|||
The big difference with this seems like it is an actual security mechanism to block "invalid" accesses where as the tagged memory extensions only provided pointer metadata and it was up to the OS to enforce invariants.

> Extensions provide no security. [...] The tagged memory extensions don't stop you from doing anything.

strcat 3 days ago|||
SPARC ADI was a predecessor to ARM MTE. ARM MTE has been available and used in production for several years now. ADI is also 4 bit but with 64 byte granularity rather than 16 byte.
rdtsc 2 days ago||
That's interesting. I had no idea about SPARC.

From https://lwn.net/Articles/710668/

> If a rogue app attempts to access ADI enabled data pages, its access is blocked and processor generates an exception.

Yeah that sounds closer to ARM MTE. Thanks for the pointer

sillywalk 3 days ago||
Nitpick: The AS/400 in 1988 didn't use the PowerPC. I believe it had it's own proprietary memory with tag bits included.

The first RS-64 with the PowerPC AS extensions came out in 1995.

rdtsc 2 days ago||
You're right. That's a good point.
akyuu 3 days ago||
I wonder if these protections will apply to macOS as well.
saagarjha 3 days ago|
The hardware for it isn't there yet, but I assume when new Macs ship it will be enabled there.
MBCook 3 days ago||
Once the hardware is there I don’t see why they wouldn’t turn it on.
HackerNewt-doms 3 days ago||
Is MTE restricted to the newest (17) iPhone models or does it work on the older ones too?
saagarjha 3 days ago|
Just the newest ones.
brcmthrowaway 3 days ago||
If we are checking every pointer at runtime how isn't this dog slow?
hyperhello 3 days ago||
The chip does it by itself, in parallel to its other operations.
riscvsupreme 3 days ago||
[flagged]
max_ 3 days ago||
[flagged]
nothankyou777 3 days ago||
We move from the "prison phone" to the escape-proof "prison phone", and the spiritual abominations on hackernews celebrate.
cmxch 3 days ago||
More like Manufacturer Integrity Enforcement the way Apple makes things.

What’s the real benefit for regular/power users?

saagarjha 3 days ago|
If you are targeted by advanced spyware then it makes it more difficult for their exploit to work.
apaprocki 3 days ago||
Whether you like it or not, we are in an echo chamber. We will all benefit more rapidly once we figure out how to explain to an everyday Joe Blow why this technology is necessary in their daily life to get them hyped to upgrade their cracked XR/XS/11 barely hanging onto life support.
OutOfHere 4 days ago|
Meanwhile, Google is doing all it can to weaken Android safety by withholding images and patches, also by failing to fully segregate applications from each other. The evidence is linked below:

(1) AOSP isn't dead, but Google just landed a huge blow to custom ROM developers: https://www.androidauthority.com/google-not-killing-aosp-356...

(2) Privacy-Focused GrapheneOS Warns Google Is Locking Down Android: https://cyberinsider.com/privacy-focused-grapheneos-warns-go...

(3) GrapheneOS exposes Google's empty promises on Android security updates: https://piunikaweb.com/2025/09/08/grapheneos-google-security...

acdha 4 days ago|
Look, I’m an iOS user but this seems like flame-bait to me without any technical details. I’ve seen a lot of Google blog posts about security improvements over the years so that seems like a very sweeping assertion if you’re not going to support it.
ysnp 3 days ago|||
I haven't read the articles posted (and I don't know how credible piunikaweb and cyberinsider are) but here is the first-ish hand information from GrapheneOS: https://grapheneos.social/@GrapheneOS/115164133992525834

> ... Google recently made incredibly misguided changes to Android security updates. Android security patches are (now) almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access.. Google's existing system for distributing security patches to OEMs was already incredibly problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins.

> ... The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days. Moving in the opposite direction with 4 months of early access is extraordinarily irresponsible. ...Their 3-4 month embargo has an explicit exception for binary-only releases of patches. We're fully permitted to release the December 2025 patches this month in a release but not the source code.

> Nearly all OEMs were failing to ship the monthly security patch backports despite how straightforward it is. The backports alone are not even particularly complete patches. They're only the High and Critical severity Android patches and a small subset of external patches for the Linux kernel, etc. Getting the full Android patches requires the latest stable releases.

transpute 3 days ago|||
Recent discussion on 90-day embargo for security updates, https://news.ycombinator.com/item?id=45158523
acdha 3 days ago||
That’s potentially substantial but I note that Graphene specifically rejected the framing:

https://xcancel.com/GrapheneOS/status/1964757878910136346

transpute 3 days ago||
Yes, they said it was worse, i.e. affected all Android, not only AOSP, https://news.ycombinator.com/item?id=45161011