3 ms·
I’m glad Phil’s work is finally getting the recognition it deserves. There may be useful takeaways here for Rust’s “unsafe” mode - particularly for application
by sheepscreek 1y ago
I’m glad Phil’s work is finally getting the recognition it deserves.
There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!
- gpm 1y ago> particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds! As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.
- quotemstr 1y agoHe could add an API to mint a capability out of thin air. It could even be done out of process. In fact, I think Fil-C and CHERI could implement 90% the same programmer-level API!
- hedgehog 1y agoFor securing and maintaining a complex legacy application it seems like a reasonable approach would be to move the majority into Fil-C, then hook the bits that don't fit up via RPC. Maybe some bits get formal verification, rewritten in Rust, ported to new platform APIs, whatever, but at least you get some safety for the whole app without a rewrite.