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

61–70 of 259 posts

Re: Memory Integrity Enforcement

#61

Post by quotemstr »

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.

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

Re: Memory Integrity Enforcement

#62

Post by leoc »

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.

Sure, I'm not suggesting that Apple might actually do both at the same time. They could however implement the less burdensome one now while intending to replace it with the the all-singing-all-dancing alternative down the line.

Re: Memory Integrity Enforcement

#63

Post by pizlonator »

leoc wrote: post #62
pizlonator wrote: post #60

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) They also imply a very different system architecture.

Sure, I'm not suggesting that Apple might actually do both at the same time. They could however implement the less burdensome one now while intending to replace it with the the all-singing-all-dancing alternative down the line.

Gotcha. My point about different systems architectures makes me think it’s unlikely that you’d want to do that

Re: Memory Integrity Enforcement

#64

Post by pizlonator »

quotemstr wrote: post #61
pizlonator wrote: post #60

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) They also imply a very different system architecture.

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

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

Re: Memory Integrity Enforcement

#65

Post by bri3d »

quotemstr wrote: post #61
pizlonator wrote: post #60

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) They also imply a very different system architecture.

> 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 the allocator supplies; CHERI requires a fundamental paradigm shift. Apple love paradigm shifts but there's no indication they're going to do one here; if they do, it will be a separate effort.

Re: Memory Integrity Enforcement

#66

Post by spaceribs »

bergfest wrote: post #52

With EU chat control, the state will be on my device, having access to everything they want, decide what I can and cannot do. Once Google forces WEI on us, the whole web will get locked down. And secure boot and now MIE will make sure we can never take back our freedom.

That is, unless we balkanize our systems and services.

Re: Memory Integrity Enforcement

#67

Post by quotemstr »

pizlonator wrote: post #64
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?

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

Some progress on UAF though! https://dl.acm.org/doi/10.1145/3703595.3705878

Re: Memory Integrity Enforcement

#68

Post by randyrand »

> 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 the push of a button with basic modification. They just have chosen not to at this time. I feel like this paragraph is drawing a bigger distinction than actually exists.

Re: Memory Integrity Enforcement

#69

Post by bri3d »

pizlonator wrote: post #64
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?

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.

Re: Memory Integrity Enforcement

#70

Post by als0 »

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…

Second bus?
Post reply on HN