Comment by pizlonator
4 months ago
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
4 months ago
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
Fil-C is basically CHERI in software, with large speed and memory overhead.
Fil-C running on any x86 box is faster than any CHERI implementation that has ever existed.
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.
Is this your last design iteration? Benchmarks would be great and some performance justification based on the design (techniques).
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, ..) ?
2 replies →
> Fil-C running on any x86 box is faster than any CHERI implementation that has ever existed.
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.
> Fil-C running on any x86 box is faster than any CHERI implementation that has ever existed
There are a lot of x86 boxes out there. Is Fil-C really faster on all of them vs. CHERI on Morello?
2 replies →
Do you even have access to CHERI hardware Phil?
1 reply →
But seemingly on track to move from "large" to "significant" speed and memory overhead. It is already really useful especially for running tests in pipelines.
> Fil-C is basically CHERI in software
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
If i understand InvisiCaps Fil-C correctly, it does not allow capability restriction (as metadata are stored at the beginning of each object), while with CHERI one can take ptr/capability for an object, restrict it to a capability for a sub-object, pass that to a callee (with function call), and the callee can access only the sub-object.
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.
1 reply →
> 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.
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.
1 reply →