In terms of Apple Kremlinology, should this be seen a step towards full capability-based memory safety like CHERI ( https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... ) or more as Apple signaling that it thinks it can get by without something like CHERI?

> This is great ...

That's Apple and here is Google (who have been at memory safety since the early Chrome/Android days):

  Google folks were responsible for pushing on Hardware MTE ... It originally came from the folks who also did work on ASAN, syzkaller, etc ... with the help and support of folks in Android ... ARM/etc as well.

  I was the director for the teams that created/pushed on it ... So I'm very familiar with the tradeoffs.
  
  ...

  Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it.

  Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead.

  For example, you will suddenly cause tons of user-visible crashes. But not even consistently. You will crash on phones with MTE, but not without it (which is most of them).

  This is probably not the experience you want for a user.

  For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1mn of them. This is not likely to make developers happy.

  Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable. Are there harmless bugs it will catch? Yes.

  ...

  As an aside - It's also not obvious it's the best choice for run-time mitigation.

Google Security (ex: TAG & Project Zero) do so much to tackle CSVs but with MTE the mothership dropped the ball so hard.

RIP Vigilant Labs

Okay a bit drastic, I don’t really know if this will affect them.

I have some inside knowledge here. KPP was released around the time KTRR on A11 was implemented to have some small amount of parity on <A11 SoCs. I vaguely remember the edict came down from high that such a parity should exist, and it was implemented in the best way they could within a certain time constraint. They never did that again.

> FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off

I interpreted that as what they came up with when first looking at/starting to implement MTE, not their plan since $longTimeAgo.

Apple has certainly gotten better about security, and I suspect things like what you listed are a big part of why. They were clearly forced to learn a lot by jailbreakers.

Yeah it’s hard to get these things right the first time.

Neither Apple or Google truly knows how widespread attacks on their products have been despite portraying it as if they have perfect insight into it. They're claiming to know something they cannot. GrapheneOS has published leaked data from exploit developers showing they're much more successful at exploiting devices and keeping up with updates than most people believe. We have access to more than what we've published, since we don't publish it without multiple independent sources to avoid leaks being identified. These tools are widely available, and it cannot be generally known when they're used whether it's data extraction or remote exploitation. Catching exploits in the wild is the exception to the rule, otherwise exploit development companies would have a much harder job needing to keep making new exploits after they're heavily used. They wouldn't value a single exploit chain nearly as much as they do if it stopped working after it was used 50k times. Law enforcement around the world has access to tools like Cellebrite Premium which are used against many people crossing borders, at protests, etc. That is usage at scale. There's far less insight into remote exploits which don't have to be distributed broadly to be broadly used.

I wonder why XcodeGhost doesn't count as successful, widespread malware attack against iPhone. WeChat was infected. It was before iOS had pasteboard protections.

[1] https://en.wikipedia.org/wiki/XcodeGhost

Maybe, maybe not. But it seems fair to point out. Certainly if it was as exposed as, say, Windows, then there would have been many.

It's mainly there as a swipe at Android. I don't think it really relates to the rest of the article (and, with no insight but with my conspiracy theory hat on, was included to peddle the merits of their App Store model).

absolutely. it is awful lawyer twinkie talk. but the fact that we get such a detailed artile press release on MIE new aphl tech it speaks to its validity and confidence which is plainly great for all of us.

Even with Android MTE, one of the workarounds was probabilistic attacks on the small tag size, which imply multiple tries. One of the big distinctions here is uniform synchronous enforcement, so writes trap immediately and not on the next context switch.

The other 15/16 attempts would crash though, and a bug that unstable is not practically usable in production, both because it would be obvious to the user / send diagnostics upstream and because when you stack a few of those 15/16s together it's actually going to take quite a while to get lucky.

It also won't help with supply-chain attacks. Executed by e.g. a state actor who is playing the long game.

To be fair, they didn't claim it to be a meaningful attack deterrent. They said "success...in increasing exploitation complexity".

Sure, the whole sentence is a bit of a weird mess. Paraphrased: it made exploits more complex, so we concluded that we needed a combined SW/HW approach. What I read into that is that they're admitting PAC didn't work, so they needed to come up with a new approach and part of that approach was to accept that they couldn't do it using either SW or HW alone.

Then again... I don't know much about PAC, but to me it seems like it's a HW feature that requires SW changes to make use of it, so it's kind of HW+SW already. But that's a pointless quibble; EMTE employs a lot more coordination and covers a lot more surface, iiuc.

> It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses.

Correction: it forces attackers to find PAC bypasses. They are not infinite.

Haha, just because there's been bypasses doesn't mean it hasn't been effective.

I would deeply, strongly caution against using public exploit availability as any evidence of security. It’s a bad idea, because hundreds of market factors and random blind luck affect public exploitability more than the difficulty of developing an exploit chain.

Apple are definitely doing the best job that any firm ever has when it comes to mitigation, by a wide margin. Yet, we still see CVEs drop that are marked as used in the wild in exploit chains, so we know someone is still at it and still succeeding.

When it comes to the Xbox One, it’s an admirable job, in no small part because many of the brightest exploit developers from the Xbox 360 scene were employed to design and build the Xbox One security model. But even still, it’s still got little rips at the seams even in public: https://xboxoneresearch.github.io/games/2024/05/15/xbox-dump...

I think the nature of the scene changed and exploits and jailbreaks are kept to small groups, individuals or are sold.

For example, I might know of an unrelated exploit I'm sitting on because I don't want it fixed and so far it hasn't been.

I think the climate has become one of those "don't correct your adversary when they make mistakes" types of things versus an older culture of release clout.

Saying "never" is too bold. But it's definitely getting immensely difficult.

There are still plenty of other flaws besides memory unsafety to exploit. I doubt that we'll see like a formally proven mainstream OS for a long time.

> iPhone? iOS 17 and 18 have never been jailbroken; now we introduce MIE.

So far as you know. There's a reason they call them zero-day vulnerabilities.

Israeli companies and agencies will surely find a way.. even if software/hardware might really be unhackable, it seems people will never be..

Unhackable and backdoored. Operation Triangulation would have been impossible without Apple backdooring their own hardware.

>Xbox One, 2012? Never hacked.

Not publicly :)

As the ability to make remote controlled hardware unhackable increases the power asymmetry between those who can create such hardware and the masses who cannot will drastically increase. I leave it as an exercise for the audience as to what the equilibrium implications are for the common man, especially in western countries where the prior equilibrium was quite different.

At attacher can guess, and has a 1/16 probability to guess right, but they have only one chance to guess because if you guess wrong, the process terminates (if it's a user-process) or the kernel panics (if it's in the kernel), so in the next opportunity you'll have it will be a different tag to guess.

Four bits provide too few possibilities. Since memory allocations happen millions of times per minute, the chance of collisions grows very quickly, even with periodic reseeding.

> MIE will make sure we can never take back our freedom.

Is the implication here that making phones more secure is... bad? Because it makes jailbreaks harder to develop?

That is, unless we balkanize our systems and services.

What is WEI?

Apple has been working on this for years. It's not like they started thinking about memory tagging when Daniel decided to turn it on in GrapheneOS.

Yes, but with MIE there will come an end to that, hopefully.

The business model of Pegasus et al. will be gone.

I believe they mean the source region's tag, rather than the destination.

https://mastodon.online/@ezhes_/115175838087995856

Nope. I don't know why just checking the tags during speculation wouldn't stop Spectre V1, at least for cross-type accesses? I mean, it's not that simple because your program won't crash if speculation has mismatched tags. Which means you can try as many times as you want until you get lucky. But that's certainly not a "completely novel mitigation", so I'm sure I'm missing something obvious.

Perhaps the real problem is that you can use speculation to scan large amounts of memory for matching tags, some of which would be different types, so you need something to handle that?

(talking out of my butt here)

Available on all the models announced today: air and 17/17 pro (a19 chip and above)

Substantially less complex and therefore likely to be substantially easier to actually use.

CHERI-Morello uses 129-bit capability objects to tag operations, has a parallel capability stack, capability pointers, and requires microarchitectural support for a tag storage memory. Basically with CHERI-Morello, your memory operations also need to provide a pointer to a capability object stored in the capability store. Everything that touches memory points to your capability, which tells the processor _what_ you can do with memory and the bounds of the memory you can touch. The capability store is literally a separate bus and memory that isn't accessible by programs, so there are no secrets: even if you leak the pointer to a capability, it doesn't matter, because it's not in a place that "user code" can ever touch. This is fine in theory, but it's incredibly expensive in practice.

MIE is a much simpler notion that seems to use N-bit (maybe 4?) tags to protect heap allocations, and uses the SPTM to protect tag space from kernel compromise. If it's exactly as in the article: heap allocations get a tag. Any load/store operation to the heap needs to provide the tag that was used for their allocation in the pointer. The tag store used by the kernel allocator is protected by SPTM so you can't just dump the tags.

If you combine MIE, SPTM, and PAC, you get close-ish to CHERI, but with independent building blocks. It's less robust, but also a less granular system with less overhead.

MIE is both probabilistic (N-bits of entropy) and protected by a slightly weaker hardware protection (SPTM, which to my understanding is a bus firewall, vs. a separate bus). It also only protects heap allocations, although existing mitigations protect the stack and execution flow.

Going off of the VERY limited information in the post, my naive read is that the biggest vulnerability here will be tag collision. If you try enough times with enough heap spray, or can groom the heap repeatedly, you can probably collide a tag with however many bits of entropy are present in the system. But, because the model is synchronous, you will bus fault every time before that, unlike MTE, so you'll get caught, which is a big problem for nation-state attackers.

https://saaramar.github.io/memory_safety_blogpost_2022/ is a nice article which goes into this topic for MTE in the past.

It's all fun and games until somebody else patches the RAM of your device, and sends your money away from your account.

More interesting is how to trace and debug code on such a CPU. Because what a debugger often does is exactly patching an executable in RAM, peeks and pokes inside, etc. If such an interface exists, I wonder how is it protected; do you need extra physical wires like JTAG? If it does not, how do you even troubleshoot a program running on the target hardware?

I think if you want to tinker with hardware, you shouldn't buy Apple. It's designed for people who use it as a means to an end, and I think that's a good thing for most people (including me). I want to bank on hardware that I can trust to be secure. Nothing wrong with building your own linux box for play time though.

If you like using debuggers, don't worry, MTE gives you a lot more chances to use them since it finds a lot more crashes. It doesn't stop you writing to memory though, as long as it's the correct type.

PAC may stop you from changing values - or at least you'd have to run code in the process to change them.

It’s a shame you’re getting downvoted because I think you’re correct, and this is a perfectly valid opinion to hold.

I would respond by saying that sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one.

Computing hardware in general is way less expensive and more abundant than it used to be, so there are still many options in the marketplace for people to peek and poke into.

Bingo. None of this is for users. Apple somehow managed to put on a marketing mask of user respect when they’re at least as user abusive as anyone else.

https://xkcd.com/538/

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

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.

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.

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.

The hardware for it isn't there yet, but I assume when new Macs ship it will be enabled there.

Just the newest ones.

The chip does it by itself, in parallel to its other operations.

[flagged]

We move from the "prison phone" to the escape-proof "prison phone", and the spiritual abominations on hackernews celebrate.

If you are targeted by advanced spyware then it makes it more difficult for their exploit to work.

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.