Also, I just don’t understand your claim that Fil-C is safer. If the user can choose to do things that makes CHERI less useful, surely they can just choose to not use Fil-C? If “can’t make your own alloc” is acceptable, that’s very easy to enforce on a CHERI system. All of Fil-C’s properties depend on user choice and implementation. And if you pre-suppose good user choices and implementations, then CHERI does not have the drawbacks that you claim. CHERI also has something Fil-C does not. Relevant quote:
If you try to compile an allocator that isn’t safely implemented on CHERI, it’ll just work - you might not even notice.
If you try to do it with Fil-C, you get a runtime error.
That’s what memory safe languages are all about - giving you feedback when you did something unsafe.
This means that Fil-C must simply trust that everything else in the same address space is not doing anything bad. That every Rust unsafe is definitely correct, that the JS implementation has no bugs that would allow writes elsewhere on the heap. CHERI on the other hand can allow safe single address space sharing that is also totally safe.
That’s true! CHERI means you don’t need a type safe language to get some kind of safety.
But you need special hardware, which makes it kinda impractical.
I’m pretty sure they want all vendors, such as Arm, Apple, Intel, and so on, to add CHERI to their products. So there would be no need to convince people to buy special hardware.
Right! That’s the key difference between CHERI and Fil-C:
For CHERI to be successful, the CHERI folks have to convince at least one vendor to ship it, and that vendor had better do a good job of it or it’ll taint the whole project. Yeah, ideally they’d convince all the vendors.
For Fil-C to be successful, I just have to either (a) convince one person to make a useful thing on top of Fil-C or (b) port some useful thing to Fil-C, where that thing becomes much more useful with the added security and not much less useful due to the perf overhead. So, the adoption bar is inherently lower. Sure, it means code changes that CHERI won’t require.
I wrote this last but decided to put it up front rather than at the end: despite all the arguing, I do find Fil-C to be pretty cool, and I hope you’re successful with it! I’m just skeptical, and disagree with your thoughts on CHERI.
If you try to compile an allocator that isn’t safely implemented on CHERI, it’ll just work - you might not even notice.
If you try to do it with Fil-C, you get a runtime error.
Nothing prevents you from enforcing something similar under CHERI. Fil-C has a single blessed alloc, and prevents other allocs from being implemented. This presumably also means blocking all system calls that might be used to implement an alloc. Ultimately, my point is that since Fil-C is software, and CHERI simply adds additional HW features, anything you can do with Fil-C, you can definitely do with CHERI. And any time you figure out how to leverage CHERI to do one of the things you want to do, the hardware is now helping enforce it.
CHERIoT has a shared heap between all compartments, and a single allocator. It enforces quotas, and gives you full spatial and temporal memory safety. As someone in the embedded space, I find it incredibly compelling.
That’s true! CHERI means you don’t need a type safe language to get some kind of safety.
But you need special hardware, which makes it kinda impractical.
But it also means that Fil-C isn’t memory safe in practice, since any Fil-C code will surely often interact with code that isn’t Fil-C. That’s one thing I like about CHERI; memory safe languages may be safe within their own specified semantics, but that falls apart as soon as any external factor may violate the invariants of the safe language. With CHERI, you can know that your nice and safe OCaml program won’t be screwed up by some C++ library you needed to use. Like, I’m a huge Rust fan, but I got to admit, CHERI plugs a big hole that currently affects all safe or semi-safe programming languages.
And idk how practical it would be to replace all not safe code. Fil-C helps a lot with some of it, but far from all.
Right! That’s the key difference between CHERI and Fil-C:
For CHERI to be successful, the CHERI folks have to convince at least one vendor to ship it, and that vendor had better do a good job of it or it’ll taint the whole project. Yeah, ideally they’d convince all the vendors.
For Fil-C to be successful, I just have to either (a) convince one person to make a useful thing on top of Fil-C or (b) port some useful thing to Fil-C, where that thing becomes much more useful with the added security and not much less useful due to the perf overhead. So, the adoption bar is inherently lower. Sure, it means code changes that CHERI won’t require.
Note that CHERI is shipping later this year in a microcontroller. And if I recall correctly, at least one other microcontroller vendor is also designing a CHERI chip. So it’ll be able to prove itself in the real world soon. Of course, there are a lot of differences between the world of embedded and the PC / server space. If the standard is “make one useful thing on top of”, then I think CHERI will succeed :)
You may be surprised, but CHERI already has a decent amount of momentum. Couple hundred million invested, a good number of companies, mostly in industries where safety is important, doing CHERI things. A few governments even recommend CHERI already, even though no hardware is generally available yet.
Also, I’m curious, you’ve mentioned that you’ve found it to be pretty easy to port C projects, but what about all the code that isn’t in C? There’s tons of C++ and Rust out there, which CHERI would make safe, but as far as I can tell, Fil-C would not. So regardless of all else we’ve talked about, CHERI casts a much broader net. Personally, I’d prefer to never write C ever again, even if it was to be made entirely safe. So in any situation where I need a “low level” language, it’d probably be Rust, possibly with some unsafe {}. So from my point of view, while both CHERI and Fil-C promise to help with (some of) the code we already have, only CHERI promises to help with new stuff.
If you try to compile an allocator that isn’t safely implemented on CHERI, it’ll just work - you might not even notice.
If you try to do it with Fil-C, you get a runtime error.
That’s what memory safe languages are all about - giving you feedback when you did something unsafe.
That’s true! CHERI means you don’t need a type safe language to get some kind of safety.
But you need special hardware, which makes it kinda impractical.
Right! That’s the key difference between CHERI and Fil-C:
For CHERI to be successful, the CHERI folks have to convince at least one vendor to ship it, and that vendor had better do a good job of it or it’ll taint the whole project. Yeah, ideally they’d convince all the vendors.
For Fil-C to be successful, I just have to either (a) convince one person to make a useful thing on top of Fil-C or (b) port some useful thing to Fil-C, where that thing becomes much more useful with the added security and not much less useful due to the perf overhead. So, the adoption bar is inherently lower. Sure, it means code changes that CHERI won’t require.
score 2 · canonical
I wrote this last but decided to put it up front rather than at the end: despite all the arguing, I do find Fil-C to be pretty cool, and I hope you’re successful with it! I’m just skeptical, and disagree with your thoughts on CHERI.
Nothing prevents you from enforcing something similar under CHERI. Fil-C has a single blessed alloc, and prevents other allocs from being implemented. This presumably also means blocking all system calls that might be used to implement an alloc. Ultimately, my point is that since Fil-C is software, and CHERI simply adds additional HW features, anything you can do with Fil-C, you can definitely do with CHERI. And any time you figure out how to leverage CHERI to do one of the things you want to do, the hardware is now helping enforce it.
CHERIoT has a shared heap between all compartments, and a single allocator. It enforces quotas, and gives you full spatial and temporal memory safety. As someone in the embedded space, I find it incredibly compelling.
But it also means that Fil-C isn’t memory safe in practice, since any Fil-C code will surely often interact with code that isn’t Fil-C. That’s one thing I like about CHERI; memory safe languages may be safe within their own specified semantics, but that falls apart as soon as any external factor may violate the invariants of the safe language. With CHERI, you can know that your nice and safe OCaml program won’t be screwed up by some C++ library you needed to use. Like, I’m a huge Rust fan, but I got to admit, CHERI plugs a big hole that currently affects all safe or semi-safe programming languages.
And idk how practical it would be to replace all not safe code. Fil-C helps a lot with some of it, but far from all.
Note that CHERI is shipping later this year in a microcontroller. And if I recall correctly, at least one other microcontroller vendor is also designing a CHERI chip. So it’ll be able to prove itself in the real world soon. Of course, there are a lot of differences between the world of embedded and the PC / server space. If the standard is “make one useful thing on top of”, then I think CHERI will succeed :)
You may be surprised, but CHERI already has a decent amount of momentum. Couple hundred million invested, a good number of companies, mostly in industries where safety is important, doing CHERI things. A few governments even recommend CHERI already, even though no hardware is generally available yet.
Also, I’m curious, you’ve mentioned that you’ve found it to be pretty easy to port C projects, but what about all the code that isn’t in C? There’s tons of C++ and Rust out there, which CHERI would make safe, but as far as I can tell, Fil-C would not. So regardless of all else we’ve talked about, CHERI casts a much broader net. Personally, I’d prefer to never write C ever again, even if it was to be made entirely safe. So in any situation where I need a “low level” language, it’d probably be Rust, possibly with some
unsafe {}. So from my point of view, while both CHERI and Fil-C promise to help with (some of) the code we already have, only CHERI promises to help with new stuff.score 3 · canonical