> Some programs have a ~4x slowdown

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!

▲

pizlonator 5 days ago | parent [-]

> How does it compare to something like RLBox?

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

▲

IshKebab 5 days ago | parent [-]

That feels like a very binary view of security. There are certainly cases where something like RLBox takes you from "horrific anything-goes C security" to "probably fine". Image parsing for example, which is a common source of vulnerabilities.

So the question of performance is still relevant, even if RLBox's security properties are less tight.

▲

pizlonator 5 days ago | parent [-]

I think you're trying to compare RLBox and Fil-C because you view them both as "add more security". I get it and that's not entirely unfair, but...

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.

▲

IshKebab 4 days ago | parent [-]

Yeah, because they are both "add more security". I totally understand that they are different. But if you just want "more security" then they are both reasonable options to pick, and it makes sense to compare their performance.

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.

	▲	pizlonator 4 days ago \| parent \| next [-]
		> But if you just want "more security" then they are both reasonable options to pick 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
	▲	kragen 4 days ago \| parent \| prev [-]
		Apples and the abstract concept of the imaginary unit i?