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

171–180 of 259 posts

Re: Memory Integrity Enforcement

#171

Post by strcat »

astrange wrote: post #145
slashtab wrote: post #118

Earlier quoted context omitted.

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.

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 do partitioning for malloc via size classes and call locations.

Re: Memory Integrity Enforcement

#172

Post by bri3d »

jrtc27 wrote: post #148
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…

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

> To anything interacting with the memory subsystem, there is one bus, and the tags flow with the data on it.

To the architecture, there is one access mechanism with the tag bit set and one separate mechanism with the tag bit unset, no?

I thought this was the whole difference: in MTE, there is a secret tag hidden in a “normal” pointer by the allocator, and in CHERI, there is a separate architectural route for tag=0 (normal memory) and tag=1 (capabilities memory), whether that separate route eventually goes to some partition of main memory, a separate store entirely, ECC bit stuffing, or whatever?

Re: Memory Integrity Enforcement

#173

Post by ysnp »

HackerNewt-doms wrote: post #156
strcat wrote: post #86

Earlier quoted context omitted.

GrapheneOS made our own integration of MTE for hardened_malloc and has done significant work on it. It wasn't simply something we turned on. ARM designed and built the feature which was made available in Cortex cores. Google's Tensor uses standard Cortex cores so unlike Qualcomm they didn't need to make their own implementation. Google integrated it into Android and did some work to make it available on Pixels along…

Is MTE on GrapheneOS restricted to some (newest?) Pixel models? Or does it work with all models that are currently supported by GrapheneOS itself?

MTE is only available in hardware on Pixel 8 and later https://googleprojectzero.blogspot.com/2023/11/first-handset.... GrapheneOS supports all the Pixel 8 and 9 series phones. They plan to support Pixel 10 once Google stop delaying their open-source releases of AOSP.

Re: Memory Integrity Enforcement

#174

Post by pjmlp »

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.

Re: Memory Integrity Enforcement

#175

Post by pjmlp »

ignoramous wrote: post #142
tptacek wrote: post #132

Earlier quoted context omitted.

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

Meanwhile Oracle has been doing it since 2015 with SPARC ADI on Solaris.

I do agree it is a pain not seeing this becoming widely adopted.

As for disabling JIT, it would have the same effect as early Androids, lagging behind Symbian devices, with applications that were wrappers around NDK code.

Re: Memory Integrity Enforcement

#176

Post by bigyabai »

astrange wrote: post #43
user3939382 wrote: post #35

Earlier quoted context omitted.

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://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 2024 asked the court to dismiss the lawsuit.
The perpetrators were caught red-handed and let, go by Apple! This crime can, will, and has continued to happen due to the negligence of Apple's leadership. No doubt influenced by Tim Cook's obligation to the White House and their friends.

Re: Memory Integrity Enforcement

#177

Post by mschuster91 »

bri3d wrote: post #54
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?

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…

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

Well, Apple already routinely forces developers to recompile their applications so if Apple wants to introduce something needing a compiler / toolchain update they can do that easily. And they also control the entire SoC from start to finish and unlike pretty much everyone else also hold an ARM Architecture License so they can go and change whatever they want in the hardware side as well.

Re: Memory Integrity Enforcement

#178

Post by checker659 »

bri3d wrote: post #54
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?

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.

Re: Memory Integrity Enforcement

#179

Post by user3939382 »

pparanoidd wrote: post #154
user3939382 wrote: post #35

Earlier quoted context omitted.

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.

>None of this is for users Your hatred for apple has made you genuinely delusional

A company who cared about users instead of its own profits wouldn’t do any of the things Apple does. Who’s really the naive one here?

Re: Memory Integrity Enforcement

#180

Post by shooshx »

vayup wrote: post #160

> ...attackers must not be able to predict tag values that the system will choose. We address this issue by frequently re-seeding the underlying pseudo-random generator used to select new tags. This point could use more explanation. The fundamental problem here is the low entropy of the tags (only 4 bits). An attacker who randomly guesses the tags has 1/16 chance of success. That is not fixed by reseeding the PRNG. S…

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.
Post reply on HN