Comment by pizlonator

Comment by pizlonator 2 days ago

I understand his argument.

Here are the reasons why I don’t buy it:

1. I’m not claiming that Fil-C fixes all security bugs. I’m only claiming that it’s memory safe and I am defining what that means with high precision. As with all definitions of memory safety, it doesn’t catch all things that all people consider to be bad.

2. Your program would crash with a safety panic in the absence of a race. Security bugs are when the program runs fine normally, but is exploitable under adversarial use. Your program crashes normally, and is exploitable under adversarial use.

So not only is it not likely to be present or exploitable, but if you wrote that code then you’d be crashing in Fil-C in whatever tests you ran at your desk or whenever a normal user tried to use your code.

But perhaps point 1 is still the most important: of course you can write code with security bugs in Fil-C, Rust, or Java. Memory safety is just about making a local bug not result in control of arbitrary memory in the whole program. Fil-C achieves that key property here, hence its memory safe.

DreadY2K 14 hours ago

> I’m only claiming that it’s memory safe and I am defining what that means with high precision

Do you have your definition of memory safety anywhere? Specifically one that's precise enough that if I observe a bug in a C program compiled via Fil-C, I can tell whether this is a Fil-C bug allowing (in your definition) memory unsafety (e.g. I'm pretty sure an out-of-bounds read would be memory unsafety), or if it's considered a non-memory-safety bug that Fil-C isn't trying to prevent (e.g. I'm pretty sure a program that doesn't check for symlinks before overwriting a path is something you're not trying to protect against). I tried skimming your website for such a definition and couldn't find this definition, sorry if I missed it.

I typically see memory safety discussed in the context of Rust, which considers any torn read to be memory-unsafe UB (even for types that don't involve pointers like `[u64; 2]`, such a data race is considered memory-unsafe UB!), but it sounds like you don't agree with that definition.

Reply View 0 replies

lifis 2 days ago

In my understanding the program can work correctly in normal use.

It is buggy because it fails to check that s->idx is in bounds, but that isn't problem if non-adversarial use of s->idx is in bounds (for example, if the program is a server with an accompanying client and s->idx is always in bounds when coming from the unmodified client).

It is also potentially buggy because it doesn't use atomic pointers despite comcurrent use, but I think non-atomic pointers work reliably on most compiler/arch combinations, so this is commonplace in C code.

A somewhat related issue if that since Fil-C capabilities currently are only at the object level, such an out-of-bounds access can access other parts of the object (e.g. an out-of-bounds access in an array contained in an array element can overwrite other either of the outer array)

It is true though that this doesn't give arbitrary access to any memory, just to the whole object referred to by any capability write that the read may map to, with pointer value checks being unrelated to the accessed object.

Reply View 1 reply

pizlonator a day ago

If you set the index to `((alice - bob) / sizeof(...))` then that will fail under Fil-C’s rules (unless you get lucky with the torn capability and the capability refers to Alice).

Reply View | 0 replies