It is great that Fil-C exists. This is the sort of technique that is very effective for real programs, but that developers are convinced does not work. Existence proofs cut through long circular arguments.
replies(2):
Some programs have a ~4x slowdown. That's also not super common, but it happens.
Most programs are somewhere in the middle.
> for the use-cases where C/C++ are still popular
This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive. It's written in C or C++ because:
- That's what it was originally written in and nobody bothered to write a better version in any other language.
- The code depends on a C/C++ library and there doesn't exist a high quality binding for that library in any other language, which forces the dev to write code in C/C++.
- C/C++ provides the best level of abstraction (memory and syscalls) for the use case.
Great examples are things like shells and text editors, where the syscalls you want to use are exposed at the highest level of fidelity in libc and if you wrote your code in any other language you'd be constrained by that language's library's limited (and perpetually outdated) view of those syscalls.
How does it compare to something like RLBox?
> This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive.
I don't think that's true, or at best its a very contorted definition of "perf sensitive". Most code is performance sensitive in my opinion - even shitty code written in Python or Ruby. I would like it to be faster. Take Asciidoctor for example. Is that "performance sensitive"? Hell yes!
I don’t know and it doesn’t matter because RLBox doesn’t make your C code memory safe. It only containerizes it.
Like, if you put a database in RLBox then a hacker could still use a memory safety bug to corrupt or exfiltrate sensitive data.
If you put a browser engine in RLBox then a hacker could still pwn your whole machine:
- If your engine has no other sandbox other than RLBox then they’d probably own your kernel by corrupting a buffer in memory that is being passed to a GPU driver (or something along those lines). RLBox will allow that corruption because the buffer is indeed in the program’s memory.
- If the engine has some other sandbox on top of RLbox then the bad guys will corrupt a buffer used for sending messages to brokers, so they can then pop those brokers. Just as they would without RLbox.
Fil-C prevents all of that because it uses a pointer capability model and enforces it rigorously.
So, RLbox could be infinity faster than Fil-C and I still wouldn’t care
So the question of performance is still relevant, even if RLBox's security properties are less tight.
They're just way too different. RLBox is a containerization technology. Fil-C is a memory safety technology.
Like, there's a world where you would use both of them stacked on top of one another, because Fil-C does memory safety without containerizing while RLBox does containerization without memory safety.
It's like comparing apples and oranges - which I always found to be a weird saying because of course it makes sense to compare apples and oranges.
Edit: looked it up and apparently it was originally "apples and oysters" which makes way more sense
https://english.stackexchange.com/a/132907/114887
Although even then it isn't incorrect to compare them. Perhaps you have to choose a canapé, we could have tiny slices of delicious apples, or succulent oysters. But it's impossible to chose because there's no way to compare them arrrghhh!
I wonder what the "most different" two things are.
The only people doing “more security” are the actors in the security theater business.
If you’re serious about security, you’re going to have a threat model. And I cannot imagine a threat model that is addressed by both Fil-C and RLbox in a similar enough way to where you’d be choosing between them based on perf