231–240 of 259 posts
1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas ! But yeah this was support for a the longest time by IBM basically. It's nice to see it's getting more widespread.
Nitpick: The AS/400 in 1988 didn't use the PowerPC. I believe it had it's own proprietary memory with tag bits included. The first RS-64 with the PowerPC AS extensions came out in 1995.
1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas ! But yeah this was support for a the longest time by IBM basically. It's nice to see it's getting more widespread.
The problem with PowerPC AS tagging was that it relied entirely on the trap instruction. If you could control execution at all, you could skip the trap instruction and it did nothing. This implementation, by my reading, essentially adds a synchronous trap instruction after every single load and store, which builds a real security boundary (even compared to Android MTE, where reads would trap but writes were only chec…
From https://www.devever.net/~hl/ppcas
> As such, they can principally be viewed as providing a performance enhancement for the IBM i operating system, which uses these instructions to keep track of pointer validity. It is the IBM i OS which enforces security invariants, for example by always following every pointer LQ with a TXER.
Earlier quoted context omitted.
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.
DVM tried to mitigate the slowness with JIT+SSA, but ART mixed in JIT+SSA alongside AOT+PGO (that is, a no JITing ART means a full AOT ART, unlike in DVM where the Interp takes over when in vmSafeMode). Even if the runtime will continue to lag in terms of power/performance efficiency wrt ObjC/Swift, Google should at least let the developers decide if they want to disallow JIT from creating executable memory regions inside their app's sandbox, like Apple does: https://developer.apple.com/documentation/security/hardened-...
Earlier quoted context omitted.
Where studies suggest "a lot" is sub-0.1%. For example, https://www.capabilitieslimited.co.uk/_files/ugd/f4d681_e0f2... was a study into porting 6 million lines of C and C++ to run a KDE+X11 desktop stack on CHERI, and saw 0.026% LoC change, or ~1.5k LoC out of ~6 million LoC, all done in just 3 months by one person. That's even an overestimate, because it includes many changes to build systems just to be able to cro…
Does that study include enabling intra object overflow protection, or not? When I say that this optional feature would force you to change a lot more code I’m comparing CHERI without intra object overflow protection to CHERI with intra object object overflow protection. Finally, 6 million lines of code is not that impressive. Real OSes are measured in billions
Sorry, I misinterpreted what you were saying. No, that's not with subobject bounds. If you want that then yes there is more incompatibility, because C does not have a good subobject memory model. That's not really because there's anything wrong with CHERI, it's just because the language itself is at odds in places with doing that kind of enforcement with any technology. But, if you're willing to incur that additional friction (as we do for our pure-capability kernel in CheriBSD), you can enable it, and it can protect against additional vulnerabilities that other security technologies fundamentally cannot. We even provide a sliding scale of subobject bounds enforcement, where each of the three levels restricts bounds in more cases at the expense of compatibility. The architecture gives you the flexibility to decide what software model you want to enforce with it.
> Finally, 6 million lines of code is not that impressive.
We have far more than that ported, that was just one case study done in a few months by one developer. FreeBSD alone is, by my very rough estimation cloc that excludes LLVM, about 14 million lines of C and C++ (yes, I'm not distinguishing architecture-specific code and all kinds of other considerations, but it's close enough and gives an order of magnitude for the purposes of this conversation), and we have FreeBSD ported. Not to mention our work on, say, Chromium and V8 (Chromium being another set of 10s of millions of lines of code, again tractable with the engineering effort of just a few members of our research group).
> Real OSes are measured in billions
Citation needed. The Linux kernel is only a bit over 40 million lines of code these days. Real systems may well approach the billions of lines of code running once you factor in all the libraries, daemons and applications running on top of it, but that is not all low-level OS code that needs the kind of porting an OS or runtime does. Even if it were a billion lines of code, though, extrapolating at 0.026% that would be 260 kLoC changed, which isn't that scary a number.
Even V8, which is about the worse case you could possibly have (highly-stylised code written in a way that uses types in CHERI-unfriendly ways; a language runtime full of pointers; many (about 6?) different highly-optimised just-in-time compilers that embed deep knowledge of the ISAs and ABIs they are targeting and like to play games with pointers in the name of performance) we see (last I checked) ~0.8% LoC changed, or about 16k out of 2 million. The porting cost is real, but the numbers have never suggested to us it's at all intractable for industry.
Earlier quoted context omitted.
Can you elaborate on what you perceive as broken?
mremap?
> 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 sequ…
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…
Remember that Spectre V1 is about causing the kernel to [incorrectly and] speculatively perform a load, and then trying to leak the loaded value by measuring the state of the cache. You might reasonably want to try this since MTE tags are stored in kernel memory.
But if the set of all possible target addresses for relevant loads on a path subject to influence by userspace can be constrained to a particular memory region, you [presumably] cannot trivially use Spectre V1 to leak values from a different region.
Also, see this[^2] paper referenced in the article.
[^1]: https://mastodon.online/@ezhes_/115175838087995856
[^2]: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=983...
Earlier quoted context omitted.
I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production. Others are aware of where MTE…
Apple has implemented synchronous MTE with almost neutral overhead and also mitigated Spectre v1 using a novel technique that I haven't heard of before (which, alas, they don't really go into detail here); what's more, they plan to ship this to (hundreds of) millions of devices. I think these are significant improvements of the state of the art.
Unsure about iOS, but back then, Webkit published their initial mitigations (like: Index masking, Pointer poisoning): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
"There has never been a successful, widespread malware attack against iPhone. ..." b your iphones BEEN pwned for YEARS and it was done in minutes LOL. gtfoh with help from ChatGPT: Apple claims “never been a successful iPhone malware attack” Reality: WireLurker, Masque, XcodeGhost, YiSpecter, jailbreak 0-days, Pegasus/Predator/Reign 0-clicks. iPhones pwned for yrs — by kids in pajamas
Yes, but with MIE there will come an end to that, hopefully. The business model of Pegasus et al. will be gone.
Earlier quoted context omitted.
Maybe it is not that they want to be locked up, but they are clueless / don't care. It sucks when the reason for why we can't have nice things is... the majority of people, doesn't it? In politics they would just say democracy at work, and believe me, people are just as clueless about that as they are with technology / privacy / security.
In this very thread you can see really smart technologists largely praising this. Those aren't random Joes, and they have pretty convincing arguments - it really does improve security (and for some people, physical safety). Apple always makes very convincing points and plausible cases which are truly hard to argue against, when it takes away any kind of control from the users for their own good. This doesn't change t…
GrapheneOS makes similar security improvements, but it doesn't lock the escape hatches or stifle our freedoms. I could still root my device if I wanted to (although this is not recommended) and I can turn exploit protections off and customize the level of enforcement in detail, per-app, if I want/need to.
Earlier quoted context omitted.
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 e…
You disable mitigations for those processes.