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

71–80 of 259 posts

Re: Memory Integrity Enforcement

#71

Post by pizlonator »

bri3d wrote: post #65
quotemstr wrote: post #61

Earlier quoted context omitted.

> 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) Why would you need MTE if you have CHERI?

Why would you need CHERI if you have working mitigations that don't demand a second bus? I think it's two halves of the same coin and Apple chose the second half of the coin. The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits th…

CHERI is deterministic.

That’s strictly better, in theory.

(Not sure it’s practically better. You could make an argument that it’s not.)

Re: Memory Integrity Enforcement

#72

Post by pizlonator »

bri3d wrote: post #69
pizlonator wrote: post #64

Earlier quoted context omitted.

Not saying you’d want both. Just answering why MTE isn’t a path to CHERI But here’s a reason to do both: CHERI’s UAF story isn’t great. Adding MTE means you get a probabilistic story at least

True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag. Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.

I think the intra object issue might be niche enough to not matter.

And CHERI fixes it only optionally, if you accept having to change a lot more code

Re: Memory Integrity Enforcement

#73

Post by philodeon »

> In 2018, we were the first in the industry to deploy Pointer Authentication Codes (PAC) in the A12 Bionic chip, to protect code flow integrity in the presence of memory corruption. The strong success of this defensive mechanism in increasing exploitation complexity left no doubt that the deep integration of software and hardware security would be key to addressing some of our greatest security challenges.

There have been multiple full-chain attacks since the introduction of PAC. It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses. This should give you pause as to how secure EMTE actually is.

Re: Memory Integrity Enforcement

#74

Post by bri3d »

pizlonator wrote: post #72
bri3d wrote: post #69

Earlier quoted context omitted.

True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag. Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.

I think the intra object issue might be niche enough to not matter. And CHERI fixes it only optionally, if you accept having to change a lot more code

I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.

Re: Memory Integrity Enforcement

#75

Post by bri3d »

als0 wrote: post #70
bri3d wrote: post #65

Earlier quoted context omitted.

Why would you need CHERI if you have working mitigations that don't demand a second bus? I think it's two halves of the same coin and Apple chose the second half of the coin. The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits th…

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.

Re: Memory Integrity Enforcement

#76

Post by bri3d »

pizlonator wrote: post #71
bri3d wrote: post #65

Earlier quoted context omitted.

Why would you need CHERI if you have working mitigations that don't demand a second bus? I think it's two halves of the same coin and Apple chose the second half of the coin. The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits th…

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

FWIW (I am a nobody compared to you; I didn't make FIL-C :) ) - I think that MIE/MTE are practically superior to CHERI.

I also think this argument is compelling because one exists in millions of consumer drives, to-be-more (MTE -> MIE) and one does not.

Re: Memory Integrity Enforcement

#77

Post by nine_k »

superkuh wrote: post #30

This is the opposite of fun computing. This is commercial computing who's only use case it making sure that people can send/receive money through their computers securely. I love being able to peek/poke inside and look at my processes ram, or patch the memory of an executable. All this sounds pretty impossible on Apple's locked down systems. They're not so much general purpose computers anymore as they are locked dow…

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?

Re: Memory Integrity Enforcement

#78

Post by quotemstr »

bri3d wrote: post #74
pizlonator wrote: post #72

Earlier quoted context omitted.

I think the intra object issue might be niche enough to not matter. And CHERI fixes it only optionally, if you accept having to change a lot more code

I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.

Yes, but CHERI opens whole new system design possibilities, including things like ultra-cheap intra-address-space security boundaries. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201607...

> We have used CHERI’s ISA facilities as a foundation to build a software object-capability model supporting orders of magnitude greater compartmentalization performance, and hence granularity, than current designs. We use capabilities to build a hardware-software domain-transition mechanism and programming model suitable for safe communication between mutually distrusting software

and https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tu...

> Processes are Unix' natural compartments, and a lot of existing software makes use of that model. The problem is, they are heavy-weight; communication and context switching overhead make using them for fine-grained compartmentalisation impractical. Cocalls, being fast (order of magnitude slower than a function call, order of magnitude faster than a cheapest syscall), aim to fix that problem.

This functionality revolves around two functions: cocall(2) for the caller (client) side, and coaccept(2) for the callee (service) side. Underneath they are implemented using CHERI magic in the form of CInvoke / LDPBR CPU instruction to switch protection domains without the need to enter the kernel, but from the API user point of view they mostly look like ordinary system calls and follow the same conventions, errno et al.

There's a decent chance that we get back whatever performance we pay for CHERI with interest as new systems architecture possibilities open up.

MTE helps us secure existing architectures. CHERI makes new architectures possible.

Re: Memory Integrity Enforcement

#79

Post by brookst »

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…

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.

Re: Memory Integrity Enforcement

#80

Post by pandalicious »

>The presence of EMTE leaves Spectre V1 as one of the last avenues available to attackers to help guide their attacks, so we designed a completely novel mitigation that limits the effective reach of Spectre V1 leaks — at virtually zero CPU cost — and forces attackers to contend with type segregation. This mitigation makes it impractical for attackers to use Spectre V1, as they would typically need 25 or more V1 sequences to reach more than 95 percent exploitability rate — unless one of these sequences is related to the bug being exploited, following similar reasoning as our kalloc_type analysis.

Did they ever explain what that mitigation does?

Post reply on HN