Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Integrity Enforcement

security.apple.com

Post reply on HN
Print view View original

191–200 of 259 posts

Re: Memory Integrity Enforcement

#191

Post by saagarjha »

strcat wrote: post #171
astrange wrote: post #145

Earlier quoted context omitted.

It certainly isn't something you can just turn on. I don't know how hardened_malloc works, but one problem is that C malloc() doesn't know the type of memory it's allocating, which is naturally an issue when you need to… allocate typed memory. You can fix this insofar as you control the compiler and calls to malloc(), which you don't, because third party code may have wrappers around it.

MTE is not about typed memory. It's for detecting invalid memory accesses outside of an object or outside of the lifetime of the object in general. hardened_malloc is the main place GrapheneOS implements MTE for userspace. In the kernel, it's implemented in various allocators and in Chromium in PartitionAlloc. The kernel and PartitionAlloc allocators have typed allocator designed unlike malloc. It's still possible to…

Yes, this is exactly what you're missing and why what Apple has done is novel. They've combined MTE with typed allocators to reduce the performance impact and make it effective as Android failed to do.

Re: Memory Integrity Enforcement

#192

Post by jrtc27 »

checker659 wrote: post #178
bri3d wrote: post #54

Earlier quoted context omitted.

IMO it's the latter; CHERI requires a lot of heavy lifting at the compile-and-link layer that restricts application code behaviors, and an enormous change to the microarchitecture. On the other hand, heap-cookies / tag secrets can be delegated to the allocator at runtime in something like MIE / MTE, and existing component-level building blocks like the SPTM can provide some of the guarantees without needing a whole p…

> compile-and-link layer Not to mention the dynamic linker.

Yeah you need a compiler, linker and OS. That's true of any security technology. CHERI may be more significant in that regard because it's a bigger rethink than just stuffing some extra metadata into the existing types, but it's not at all intractable. We, a research group, maintain CheriBSD, a "full-fat" port of FreeBSD to CHERI (Morello and CHERI-RISC-V), so to a big tech organisation it's a small investment. The cost to tech companies is not making it work, it's often much more boring business factors.

Re: Memory Integrity Enforcement

#193

Post by saagarjha »

slashtab wrote: post #118
saagarjha wrote: post #47

Earlier quoted context omitted.

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.

So Apple did research and Daniel just “turned it on”?! I am not talking about Hardware part even then you're biased and dismissive of other's effort.

Shipping MIE (or even MTE) is a many-year effort that requires several parties. I appreciate that Daniel and the GrapheneOS team have been working on making sure the allocator is MTE aware, as well as (I assume) updating Android code to work under MTE. However, to actually ship this, you need someone to design the feature itself, then threat model it, release hardware for it, plumb it through the build system and make sure the OS is aware of it, and then there's a bunch of ongoing work that needs to be done so that it can be released. Much of this work was done by Google and Arm, not Daniel, involving dozens if not hundreds of engineers.

Daniel's position on MTE for a while has been that Google is dragging their feet in turning it on, but he fails to understand that there is more to it than just flipping a switch that he does in his OS. To actually productionize it requires a huge amount of effort that Apple put in here and Daniel, as talented as he is, really can't do. We know this because Google was not able to do it even though they wanted to. (For the avoidance of doubt: Google does want to turn on MTE, they're not just dawdling "just because". The current MTE implementation is not good enough for them.)

Re: Memory Integrity Enforcement

#194

Post by saagarjha »

MBCook wrote: post #120
sfink wrote: post #94

Earlier quoted context omitted.

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…

You’re on the right track, I think. The mastodon link posted in a sibling comment within a minute of yours provides more details: It sounds like the kernel’s allocations may only use one tag(?). So if you get in there, jackpot right? No tags to deal with. So they’re using special compiler flags to limit all offsets to less than 4 GB. Then they placed different parts of the kernel far apart in address space with a 4 G…

Kind of, but they don't just use one tag, they use all the tags just as userspace would. You throw all the allocations with the same type into a <4GB region and tag it, then make sure that pointer arithmetic stays within that region.

Re: Memory Integrity Enforcement

#197

Post by saagarjha »

bigyabai wrote: post #176
astrange wrote: post #43

Earlier quoted context omitted.

https://www.theguardian.com/news/2022/jan/17/two-female-acti...

It's detestable how Apple handled the aftermath of this: https://en.wikipedia.org/wiki/FORCEDENTRY In November 2021, Apple Inc. filed a complaint against NSO Group and its parent company Q Cyber Technologies in the United States District Court for the Northern District of California in relation to FORCEDENTRY, requesting injunctive relief, compensatory damages, punitive damages, and disgorgement of profits but in 202…

If I remember correctly the Israeli government stepped in and seized all the material that Apple could use in the lawsuit, so there was no point in continuing.

Re: Memory Integrity Enforcement

#198

Post by Findecanor »

bri3d wrote: post #75
als0 wrote: post #70

Earlier quoted context omitted.

Second bus?

CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.

A CHERI capability is stored in main memory but with the tag bit for that location set. The tags are stored in separate memory pages, also in main memory in current designs.

Maybe you've been confused by a description of how it works inside a processor. In early CHERI designs, capabilities were in different architectural processor registers from integers.

In recent CHERI designs, the same register numbers are used for capabilities and other registers. A micro-architecture could be designed to have either all registers be capability registers with the tag bit, or use register renaming to separate integer and capability registers.

I suppose a CHERI MCU for embedded systems with small memory could theoretically have tag pages in separate SRAM instead of caching main memory, but I have not seen that.

Re: Memory Integrity Enforcement

#199

Post by Findecanor »

VogonPoetry wrote: post #170
pizlonator wrote: post #71

Earlier quoted context omitted.

CHERI is deterministic. That’s strictly better, in theory. (Not sure it’s practically better. You could make an argument that it’s not.)

This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!)…

I suspect that the parent poster was referring to MTE's memory protection being probabilistic. There are only 16 tag values for an attacker to guess. You can combine MTE and PAC, but PAC is also only probabilistic.

With CHERI, there is nothing to guess. You either have a capability or you don't.

Re: Memory Integrity Enforcement

#200

Post by jooize »

randyrand wrote: post #68

> There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware ... to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way.. Correct me if I'm wrong, but the spyware that has been developed certainly could be applied at scale at th…

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

Post reply on HN