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

141–150 of 259 posts

Re: Memory Integrity Enforcement

#141

Post by strcat »

bri3d wrote: post #39
brcmthrowaway wrote: post #18

How does this compare to CHERI?

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. Ever…

The early ARM Cortex MTE support has full support for synchronous and asymmetric (synchronous on reads, asynchronous on write) modes. Asynchronous was near zero cost and asymmetric comparable to a mitigation like MTE. This has been available since the launch of the Pixel 8 for Android. GrapheneOS began using it in the month the Pixel 8 launched after integrating it into hardened_maloc. It currently uses mode synchronous for the kernel and asymmetric for userspace. EMTE refers to FEAT_MTE4 which is a standard ARM extension with the 4th round of MTE features. It isn't Apple specific.

MTE is 4 bits with 16 byte granularity. There's usually at least 1 tag reserved so there are 15 random tags. It's possible to dynamically exclude tags to have extra deterministic guarantees. GrapheneOS excludes the previous random tag and adjacent random tags so there are 3 dynamically excluded tags which were themselves random.

Linux kernel MTE integration for internal usage is not very security focused and has to be replaced with a security-focused implementation integrated with pKVM at some point. Google's recently launched Advanced Protection feature currently doesn't use kernel MTE.

Re: Memory Integrity Enforcement

#142

Post by ignoramous »

tptacek wrote: post #132
ignoramous wrote: post #128

Earlier quoted context omitted.

> 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…

This is a Daniel Berlin post explaining why Google didn't originally enable MTE full-time on Android. It explicitly acknowledges that keeping MTE enforcement enabled for everyone would block vulnerabilities.

Unfortunate Daniel Berlin did not push Google to invest in MTE for security specifically, like Apple has done now with EMTE (MTE v4?). I mean, AOSP is investing heavily in rewriting core components like Binder IPC in Rust for memory safety instead... They also haven't resurrected the per-app toggle to disable JIT in ART for Java/Kotlin apps (like DVM's android:vmSafeMode)... especially after having delivered on-device "Isolated compilation" but (from what I can tell) only for OS (Java/Kotlin) components.

AOSP's security posture is frustrating (as Google seemingly solely decides what's good and what's bad and imposes that decision on each of their 3bn users & ~1m developers, despite some in the security community, like Daniel Micay, urging them to reconsider). The steps Apple has been taking (in both empowering the developers and locking down its own OS) in response to Celebgate and Pegasus hacks has been commendable.

Re: Memory Integrity Enforcement

#143

Post by astrange »

ghostpepper wrote: post #115
sfink wrote: post #88

Earlier quoted context omitted.

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…

Making attackers work harder is still a worthwhile goal. No security is perfect.

Also, all of these security improvements are nearly-free assert()s which catch memory bugs.

Re: Memory Integrity Enforcement

#144

Post by jrtc27 »

pizlonator wrote: post #60
leoc wrote: post #40

Earlier quoted context omitted.

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?

MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag) They also imply a very different system architecture.

We actually have ideas for how to combine the two; see section C.5 of https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.pdf

Re: Memory Integrity Enforcement

#145

Post by astrange »

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.

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.

Re: Memory Integrity Enforcement

#146

Post by jrtc27 »

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.

That's not true. Capabilities are in main memory as much as any other data. The tags are in separate memory (whether a wider SRAM, DRAM ECC bits, or a separate table off on the side in a fraction of memory that's managed by the memory controller; all three schemes have been implemented and have trade-offs). But this is also true of MTE; you do not want those tags in normal software-visible main memory either, they need to be protected.

Re: Memory Integrity Enforcement

#147

Post by astrange »

bri3d wrote: post #39
brcmthrowaway wrote: post #18

How does this compare to CHERI?

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. Ever…

SPTM isn't a hardware feature, it's basically a hypervisor that manages the page tables and tag memory so that the kernel doesn't own its own tags.

Re: Memory Integrity Enforcement

#148

Post by jrtc27 »

bri3d wrote: post #39
brcmthrowaway wrote: post #18

How does this compare to CHERI?

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. Ever…

> has a parallel capability stack

There is one stack, the normal program stack that's normal main memory.

> capability pointers

If you use pure-capability CHERI C/C++ then there is only one type of pointer to manage; they just are implemented as capabilities rather than integers. They're also just extensions of the existing integer registers; much as 64-bit systems extend 32-bit registers, CHERI capability registers extend the integer registers.

> requires microarchitectural support for a tag storage memory

Also true of MTE?

> your memory operations also need to provide a pointer to a capability object stored in the capability store

There is no "capability object stored in the capability store". The capability is just a thing that lives in main memory that you provide as your register operand to the memory instruction. Instead of `ldr x0, [x1]` to load from the address `x1` into `x0`, you do `ldr x0, [c1]` to load from the capability `c1`. But `c1` has all of the capability; there is no indirection. It sounds like you are thinking of classical capability systems that did have that kind of indirection, but an explicit design goal of CHERI is to not do that in order to be much more aligned with contemporary microarchitecture.

> The capability store is literally a separate bus and memory that isn't accessible by programs,

As above, there is no separate bus, and capabilities are not in separate memory. Everything lives in main memory and is accessed using the same bus. The only difference is there are now capability tags being stored alongside that data, with different schemes possible (wider SRAM, DRAM ECC bits, carving out a bit of main memory so the memory controller can store tags there and pretend to the rest of the system that memory itself stores tags). To anything interacting with the memory subsystem, there is one bus, and the tags flow with the data on it.

Re: Memory Integrity Enforcement

#149

Post by jrtc27 »

leoc wrote: post #57
bri3d wrote: post #39

Earlier quoted context omitted.

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. Ever…

Something I'm not clear about: is CHERI free and clear in patent terms, or do people have their hands out grasping for an MPEG-like licensing bonanza? If it's the latter then that might matter as much as purely technical obstacles to CHERI adoption.

Cambridge and Arm have made a joint statement that nothing that is essential to the deployment of CHERI ("capability essential IP") is being patented by them: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-953.pdf. As with any patent issues, you should consult your legal team and not take anyone else's word for it, because patent law is a minefield and who knows what patents may be out there lurking that nobody realises happens to cover some aspect of CHERI, or design choices in an implementation of it, as with any processor technology, but we are not out to patent it. We believe that the right thing to do is to make the technology open in order to allow it to be widely used for the good of the field.
Post reply on HN