Unlikely that new HW will be the solution.
You can have a memory safe Linux userland today in stock hardware. https://fil-c.org/pizlix
You can have a memory safe Linux userland today in stock hardware. https://fil-c.org/pizlix
That's likely to be true in embedded also, just because of the relationship between volume and performance in silicon. Fil-C runs on the high volume stuff, so it'll get better perf.
CHERI doubles the size of pointers, so it's not like it has a decisive advantage over Fil-C.
Also, the fact that having access to CHERI hardware is a thing you presume I don't have should tell you a lot about how likely CHERI is to ever succeed
Heh. I don't doubt it. Just like RISC-V in QEmu on a x86 box is faster than any RISC-V core that anyone can get their hands on ... but only so far.
Are all possible memory problems checked, which to me include those listed in https://matu3ba.github.io/articles/optimal_debugging/#practi... (OOB, null, type confusion, integer overflow, invalid stack access, UUM, data races, illegal aliasing/provenance, stack overflows, ..) ?
There’s so much perf on the table that I haven’t claimed yet.
I’m just focusing on other things most of the time, like right now I want to actually make a super easy to install memory safe sshd distro.
The perf is more than good enough for that so that’s just a thing I should ship
All of the things you list are either checked or they’re given some kind of safe semantics. Like some kinds of type confusion are just fine and need to work (like int to float bit casts)
That is amazing and looks like an excellent first use case.
There are a lot of x86 boxes out there. Is Fil-C really faster on all of them vs. CHERI on Morello?
(Disclosure: I had a ~1GHz? atom mini-PC recently until it bricked. It could technically boot Windows 10 or Linux, but it was not fast.)
Do you think that MTE will make an Apple M5 slower than an Atom as well?
It's not, actually.
Fil-C is more compatible with C/C++ than CHERI, because Fil-C doesn't change `sizeof(void*)`.
Fil-C is more compatible in the sense that I can get CPython to work in Fil-C and to my knowledge it doesn't work on CHERI.
Fil-C also has an actual story for use-after-free. CHERI's story is super weak
This also means Fil-C seems not to be really helpful when a program uses its own allocators on top of malloc() or page allocation from OS, while with CHERI this works naturally through capability restriction.
The fact that InvisiCaps don’t support capability restriction is a choice though. I could have made them support that feature. I didn’t because I’m going for C/C++ compatibility and the only way to make meaningful use of capability restriction is to change people’s code.
Worth noting that if a program has its own allocator then you have to make more than zero changes in both Fil-C and in CHERI to get the benefit:
- In fil-C you just get rid of the custom allocator.
- In CHERI you make the allocator do capability restriction, which is actually kinda hard to get right (if the allocator’s metadata doesn’t also do capability restriction and the allocator uses inline free lists then that could easily turn into a full blown capability escape).
MicroPython has been ported though. What makes CPython special, so it couldn't be ported?
> Fil-C also has an actual story for use-after-free. CHERI's story is super weak
Indeed, CHERI does not always trap on use-after-free if the program is fast enough. A free'd memory object is kept until another thread has found all pointers to the object and made them invalid.
If I understood the paper right, Cornucopia-Reloaded does invalidate a capability directly when loaded if the pointed-to page is marked free. Therefore, any allocation of at least a page should have no use-after-free.
I don't know, but I'm guessing it's the pointer shenanigans that happen in the CPython bytecode.