Why did you write a new RTOS for CHERIoT?
cheriot.org
cheriot.org
> CHERI extends conventional hardware Instruction-Set Architectures (ISAs) with new architectural features to enable fine-grained memory protection and highly scalable software compartmentalization. The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities.
CHERIoT is work towards bringing similar things to RISC-V for IoT use-cases.
The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities.
These features enable new software constructs that are incrementally deployable within existing software ecosystems.
So while it's possible to add CHERI to existing projects, to get the full benefits they decided they needed to go all-in, hence CHERIoT.
[1]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
> CHERIoT was designed to provide both spatial and temporal safety, both enforced efficiently in the hardware. As such, we can rely on a shared heap, even in situations where you need to provide mutual distrust.
This means you can pass pointers directly between processes. A pointer isn't just an address, it's a capability, similar to a file descriptor in that you cannot forge one.
This means there's no need for virtual address space mappings, which could in theory provide some significant performance gains, similar to unikernels but without sacrificing hardware-enforced memory protections. Though, capability pointers have their own costs--in memory, in the need to garbage collect old pointers--so it remains to be seen what the net cost would be in a system fully optimized for these abilities.
However I have not seen anything that effectively handles fragmentation. Maybe you could do some sort of transparent compaction in conjunction with “demand paging” in the relocated area, but that would be very intrusive and likely only provide runtime guarantees like a system using a compacting GC.
I'm not sure what you mean by questions. But cheri does have an answer to how revocation works: All cheri capabilities (pointers) are tagged and the tags are controlled with protected instructions. To revoke a capability, you can sweep the tagged memory and untag any revoked cabability. To reduce revocation work, you can defer reusing cabilities for as long as reasonable and then revoke many in a single sweep.
Of course, this is not cheap compared to the rest of cheri-- but they do have an answer to it, and it's implemented e.g. in cheribsd. It's intrusive (at least in terms of performance/latency) as you note, though it's distinct from most other GC approaches because it's secure even against malicious code, and can't have false positives or false negatives (because tags are completely unambigious).
One of the cool things about cheri is that it eliminates the need for a TLB for security reasons which could have positive performance effects... unfortunately virtual memory is still needed for virtual memory that exceeded physical memory. Though for an IOT-ish device swap is probably a non-issue.
Which is my point about questions; there exists a potential solution but it remains to be seen how effective it would be in the circumstances.
Personally, I think they should probably implement a two-level capability. The kernel presents a top-level capability during allocation requests which userspace can then derive from at will. Kernel revokation of the top-level capability would revoke any derived capability. The derivation relation can almost certainly be stored in the tag resulting in no additional space requirements per-capability. At worst you could add some additional hardware machinery to support efficiently managing and resolving the derivation relation.
But again, potential solutions with some questions around usability.
Although a hardware-optimised take on this is interesting, CHERI is not unique in allowing a flat, shared-address-space operating system using hardware-enforced memory protection.
You can imagine doing such a thing on a regular system by associating a set of capabilities with each thread or process. The capabilities refer to a range of the single address space. Normally the range is not mapped to that process; when the process tries to access the range the kernel handles the page fault by checking the capability list and mapping the range. If a capability is revoked the range is unmapped again and associated caches (i.e. the TLB) are flushed.
This scheme obviously has different trade-offs versus using hardware-checked fat pointers, but has the advantage that it can be implemented on commodity hardware.
This is the basic idea behind the Mungi single-address-space operating system from 1998, among others. (https://research.ibm.com/publications/the-mungi-single-addre...). Is it also straightforward to implement such a scheme at user level in some implementations of L4.
It works by changing pointers from (in assembler) equivalent to integers to a hardware supported capability type. That type is twice the size of an address contains the bounds on the memory allocation it points into. Each such double capability is also protected against manipulation by an extra bit that isn't addressable by normal means (to record the manipulation invalidating the capability).
At first glance having twice as fat pointers should slow things down, but if you fully commit to the hardware capabilities in your OS you can get away with a minimal MMU could more than make up the overhead of larger pointers (faster context switches, less TLB stalls, etc.)
With its formal proofs, it should be the automatic go-to for security, high-assurance or hard realtime scenarios.
0. https://www.youtube.com/playlist?list=PLtoQeavghzr0ZntMmRPwg...
1. https://www.youtube.com/watch?v=BQhykTrtIwg&list=PLtoQeavghz...
If we didn’t have Rust this would be super cool. With Rust this seems like slapping flexseal on the leaky boat.
https://cheriot.org/cheri/myths/2024/08/28/cheri-myths-safe-...
Is it neat? Sure. Is it practical and useful? I’m skeptical.