An Armful of CHERIs(msrc-blog.microsoft.com)
msrc-blog.microsoft.com
An Armful of CHERIs
https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cheris/
24 comments
It will also effectively destroy performance for general purpose computing. Aside from secure enclaves and certain specific computing usages, it doesn't seem to offer much for day-to-day security. However I do think it can be useful for some kernel/systemland operations if the additional circuitry does not have too much overhead.
>It will also effectively destroy performance for general purpose computing.
Is that a confirmed statement or is that an assumption? Just wondering.
Is that a confirmed statement or is that an assumption? Just wondering.
It's an assumption, and so far it seems to be wrong. The whole point of having production boards is to allow for more testing of performance impacts; but evidence so far is that most applications see a single-digit percentage impact.
Some applications may even see improved performance, since relying on hardware bounds checking can allow software bounds checking to be elided.
Some applications may even see improved performance, since relying on hardware bounds checking can allow software bounds checking to be elided.
>see a single-digit percentage impact
That seems like a very very good trade off! Do we know any downside to it? Sorry I tend to ask for cons when things sounds too good to be true. ( Apart from the need to recompile )
That seems like a very very good trade off! Do we know any downside to it? Sorry I tend to ask for cons when things sounds too good to be true. ( Apart from the need to recompile )
Pointers are 128bit (to be large enough to contain the range, permission, type, etc, as well as the address), so existing code will at a minimum need recompilation, but likely much C/C++ code that makes assumptions about sizes of pointers and integers and the ability to freely convert between them will need to be adjusted. Pointer-heavy data structures will see increases in memory pressure due to pointers doubling in size relative to typical modern 64bit platforms. Still pretty cool.
The upper 64 bits doesn't contain the permissions directly, but a value to lookup in a PowerPC style hash page table for the permissions, range, type, etc. If it encoded it directly, it wouldn't be an object capability system. It only needs to be large enough to cover the number of objects in an address space that are covered by the scheme. It's 128 bit to then round that up to a power of two for hardware reasons but still have a 64but pointer.
I could see a Cheri V2 that uses multi level schemes for both the object lookup and the offset address to pack it back into 64 bits, but that's added complexity that's not strictly needed for an MVP of test designs.
I could see a Cheri V2 that uses multi level schemes for both the object lookup and the offset address to pack it back into 64 bits, but that's added complexity that's not strictly needed for an MVP of test designs.
To get full protection also against dangling pointers to deallocated objects ("temporal safety"), a service similar not too unlike a garbage collector would have to be used.
Several algorithms have been developed, and the best of those have had an average runtime overhead of around 5% in benchmarks of algorithms, but in some benchmarks the overhead has been over 25%. Then there is overhead for memory that has yet to be cleared for reuse.
I haven't seen any benchmark of any real application. (I might just have missed it though)
I haven't seen any benchmark of any real application. (I might just have missed it though)
Performance in detriment of everything else is what brought us here in first place.
"In the case of CHERI, this was to change the user-visible abstract machine exposed by hardware in a way that hasn’t been done for mainstream hardware since the PDP-11." - the authors should take the time to familiarise themselves with the Burroughs B6700 (designed in the 1960s) which provided tagged memory, and a similar mechanism to CHERI architectural capabilities through the B6700 descriptor mechanism.
CHERI is a welcome development in producing safer systems, but it is packaging ideas that have been around for 50+ years, long overdue of course, but finally hardware costs have commoditised such that these ideas can be baked into mass produced hardware.
https://en.wikipedia.org/wiki/Burroughs_large_systems_descriptors
CHERI is a welcome development in producing safer systems, but it is packaging ideas that have been around for 50+ years, long overdue of course, but finally hardware costs have commoditised such that these ideas can be baked into mass produced hardware.
It's too bad that 286 style 16bit protected mode (and the iAPX 432 before it) was so shit on at the time. We had the potential to have these concepts be ubiquitous, but collectively dismissed the protection mechanisms as intrinsically too slow.
It feels like from the outside that there was a decent sized faction at Intel in the 80s to give us a hardware object capability system, but they ended up losing the political battle, and by the time of AMD designing long mode, the last remnants were swept away.
I wish the 386's 32 bit protected mode had been structured as GDT entries that had a bit to optionally point to page tables rather than just having base addresses into a global page table. It would have encouraged these techniques in commodity systems 30 years ago.
Hell, we might not even have had spectre and at least would have had better tools to address it if we had that plus rings 1 & 2 still useable. The user and kernel space would have had the ability to describe untrusted data to the MMU. It feels like we're just pretending that NetSpectre isn't a thing and somehow spectre is only an issue with untrusted code.
It feels like from the outside that there was a decent sized faction at Intel in the 80s to give us a hardware object capability system, but they ended up losing the political battle, and by the time of AMD designing long mode, the last remnants were swept away.
I wish the 386's 32 bit protected mode had been structured as GDT entries that had a bit to optionally point to page tables rather than just having base addresses into a global page table. It would have encouraged these techniques in commodity systems 30 years ago.
Hell, we might not even have had spectre and at least would have had better tools to address it if we had that plus rings 1 & 2 still useable. The user and kernel space would have had the ability to describe untrusted data to the MMU. It feels like we're just pretending that NetSpectre isn't a thing and somehow spectre is only an issue with untrusted code.
What a weird nit to pick.
You are of course right, that was also my reaction, then I realised that they wrote "since the PDP-11." and not before.
Recent and related:
Arm releases experimental CHERI-enabled Morello board - https://news.ycombinator.com/item?id=30007474 - Jan 2022 (81 comments)
Arm releases experimental CHERI-enabled Morello board - https://news.ycombinator.com/item?id=30007474 - Jan 2022 (81 comments)
I'm hugely optimistic about CHERI, or similar approaches if this fails to get traction.
We get the biggest security benefits when we rule out entire classes of vulnerability and take them away from developers needing to care about them, e.g. memory safe languages. It's particularly good that CHERI works with C and C++ code at the source level.
No offense to software developers, but the incentives to push code out as quickly as possible simply doesn't align with the need for security, even if the developer understands all the potential issues.
We get the biggest security benefits when we rule out entire classes of vulnerability and take them away from developers needing to care about them, e.g. memory safe languages. It's particularly good that CHERI works with C and C++ code at the source level.
No offense to software developers, but the incentives to push code out as quickly as possible simply doesn't align with the need for security, even if the developer understands all the potential issues.
This might be hyperbolic, but I worry that this will further cement the stranglehold that Big Tech has on us, broadly speaking, as hackers. Remote attestation, hardware-backed DRM, TPMs and other Microsoft-favoured technologies exist to wrest control of a computer from a user with physical access to "the rights holder" or "the IT department".
Say what you want about memory vulnerabilities (they're a bad thing!), I secretly like the fact that everything has an implementation bug for a determined enough attacker. It means that if you own a device and have unrestricted physical access to it -- something that only really happens if you own a device -- then you're likely able to bend its software to your will. That's what hacking is about, after all!
I worry that this architecture will end up in HDCPv3 chips, or as an embedded SOC (or chiplet) in the next x86 processors, constantly checking that everything is okay. People say that this idea leading to hating behind trusted computing is paranoid, but as every rooted Android user knows, it's not.
Say what you want about memory vulnerabilities (they're a bad thing!), I secretly like the fact that everything has an implementation bug for a determined enough attacker. It means that if you own a device and have unrestricted physical access to it -- something that only really happens if you own a device -- then you're likely able to bend its software to your will. That's what hacking is about, after all!
I worry that this architecture will end up in HDCPv3 chips, or as an embedded SOC (or chiplet) in the next x86 processors, constantly checking that everything is okay. People say that this idea leading to hating behind trusted computing is paranoid, but as every rooted Android user knows, it's not.
You are obviously correct that taking away the ability to exploit code will impact "good" hacks as well as "bad" ones.
However, I'd rather be able to install an OS I want without needing to hack the software in the first place. We need a "right to modify" alongside other issues like "right to repair".
However, I'd rather be able to install an OS I want without needing to hack the software in the first place. We need a "right to modify" alongside other issues like "right to repair".
Someone better tell Microsoft that one does not write C/C++, /s.
As for CHERIs, I have been following the research from afar and it is great to see how far they managed to come.
As for CHERIs, I have been following the research from afar and it is great to see how far they managed to come.
I wonder if this mechanism could also be used for bounds checking when accessing dynamically sized collections. That would be a boon for C/C++ as well as safe languages.
But I guess it can not because while the underlying allocation may have space for 100 objects, the high-level container might only have initialized the first 10 objects for example.
But I guess it can not because while the underlying allocation may have space for 100 objects, the high-level container might only have initialized the first 10 objects for example.
Most likely that is the goal to combine it with MTE, as described on the article.
By the way Solaris SPARC ADI has been doing it for a decade now (bounds checking).
By the way Solaris SPARC ADI has been doing it for a decade now (bounds checking).
In terms of computer security, this is revolutionary.
Wow.
> When malloc or operator new returns a new object, it will subdivide one of these capabilities and provide a pointer that gives access to precisely one object. No mechanism in the system can turn that into a pointer to another object.
Impressive. This is a game-changer, will eliminate a whole class of side -channel attacks.