141–150 of 162 posts
Earlier quoted context omitted.
That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.
Wasm now supports multiple modules and multiple linear memories per module, so it ought to be quite possible to compile C to Wasm in a way that enforces C's object access rules, much like CHERI if perhaps not Fil-C itself.
What's the rationale for naming it after yourself?
Earlier quoted context omitted.
Because that’s not the sandboxing tech that either OpenSSH or the browsers use as far as I can tell. But landlock works great in Fil-C.
Thanks, I see. From the title I didn't infer that it's browser or openssh specific but that's ok.
I should add that landlock just works, and that lots of the other sandboxing techs also work
Earlier quoted context omitted.
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 whe…
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 comc…
Earlier quoted context omitted.
No, this program doesn’t demonstrate the issue. You can’t access out of bounds of whatever capability you loaded.
Fil-C lets programs access objects through the wrong pointer under data race. All over the Internet, you've responded to the tearing critique (and I'm not the only one making it) by alternatively 1) asserting that racing code will panic safely on tear, which is factually incorrect, and 2) asserting that a program can access memory only through its loaded capabilities, which is factually correct but a non sequitur for…
Try it. That’s what happens.
> through its loaded capabilities, which is factually correct but a non sequitur for the subject at hand.
It’s literally the safety property that Fil-C guarantees.
Safety properties provided by languages aren’t about preventing every bad thing that users can imagine. Just because the language does something different than what you expect - even if it allows you to write a program with a security bug - doesn’t mean that the language in question isn’t memory safe.
> You're shredding your credibility for nothing. You can instead just acknowledge Fil-C provides memory safety only for code correctly synchronized under the C memory model.
Fil-C provides memory safety even for incorrectly synchronized code. That safety guarantee is easy to understand and easy to verify: you only get to access the memory of the capability you actually loaded. You’re trying to evade this definition by getting hung up on what the pointer’s intval was, and your PoC uses a pointer comparison to illustrate that. You’re right that the intval is untrusted under Fil-C rules.
I’m not going to downplay the guarantees of my technology just to appease you. Whether or not you find me credible is less important to me than being honest about what Fil-C guarantees.
Earlier quoted context omitted.
Fil-C lets programs access objects through the wrong pointer under data race. All over the Internet, you've responded to the tearing critique (and I'm not the only one making it) by alternatively 1) asserting that racing code will panic safely on tear, which is factually incorrect, and 2) asserting that a program can access memory only through its loaded capabilities, which is factually correct but a non sequitur for…
> asserting that racing code will panic safely on tear, which is factually incorrect Try it. That’s what happens. > through its loaded capabilities, which is factually correct but a non sequitur for the subject at hand. It’s literally the safety property that Fil-C guarantees. Safety properties provided by languages aren’t about preventing every bad thing that users can imagine. Just because the language does somethi…
> 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).
In the comment above, you write, referring to a fault on access through a torn capability
> Try it. That’s what happens.
Your position would be clearer if you could resolve this contradiction. Yes or no: does an access through a pointer with an arbitrary offset under a data race that results in that pointer's capability tearing always fault?
> You’re right that the intval is untrusted under Fil-C rules.
Can Fil-C compile C?
You can't argue, simultaneously,
1) it's the capability, not your "intval", that is the real pointer with respect to execution flow and simultaneously, and
2) that Fil-C compiles normal C in which the "intval" has semantic meaning.
Your argument is that Fil-C is correct with respect to capabilities even if pointers are transiently incorrect under data races. The trouble is that Fil-C programs can't observe these capabilities and can observe pointers, and so make control flow decisions based on these transient incorrect (you call them "untrusted") inputs.
Earlier quoted context omitted.
[Woman walking on beach at sunset, holding hands with husband] Voiceover: "Miracurol cures cancer." [Couple now laughing over dinner with friends] "Ask your doctor if Miracurol is right for you." [Same footage continues, voice accelerates] "In clinical trials, five mice with lymphoma received Miracurol. All five were cured. One exploded. Not tested in humans. Side effects include headache, itchiness, impotence, explo…
It’s really sad to see your posts on this thread. Fil-C is an incredible achievement and absolutely full of interesting technical details to dig into. I’m not a mod, but as a reader of the site and someone who takes a curious interest in the progress of Fil-C, can you please stop attacking its creator like this. It’s tedious, needlessly rude, and lessens the opportunity for the rest of us to actually learn something…
Earlier quoted context omitted.
I'm aware of that, but I'm responding to the original claim that "Rust makes the same guarantees regardless of the unsafe keyword " (see https://news.ycombinator.com/item?id=46262774 )
Ah. I agree with you. When unsafe is used the borrow checker cannot check for memory safety, the programmer has to provide the guarantees by making sure their code does not violate memory safety, similar to programming in C. But unsafe Rust is still far better than C because the unsafe keyword is visible and one can grep it and audit the unsafe parts. Idiomatic Rust also requires that the programmer provides comments…
The practical memory safety we see in Rust is much more the result of trying hard to avoid memory safety issues and requiring comments for unsafe blocks is part of this culture.
Earlier quoted context omitted.
> It can hose your memory all it wants, it can just only do so within the confines of the sandbox. True, although as I understand it the WASI component model at least allows multiple fine-grained sandboxes, so it's somewhere in-between per-object capabilities and one big sandbox for your entire program. I haven't actually used it yet so I might be wrong about that. > so you'll probably have to wait ten years to get s…
WASI is basically CORBA, and DCOM, PDO for newer generations. Or if you prefer the bytecode based evolution of them, RMI and .NET Remoting. I don't see it going that far. The WebAssembly development experience on the browser mostly still sucks, especially the debugging part, and on the server it is another yet another bytecode. Finally, there is hardly any benefit over OS processes, talking over JSON-RPC (aka how RES…
Earlier quoted context omitted.
Ah. I agree with you. When unsafe is used the borrow checker cannot check for memory safety, the programmer has to provide the guarantees by making sure their code does not violate memory safety, similar to programming in C. But unsafe Rust is still far better than C because the unsafe keyword is visible and one can grep it and audit the unsafe parts. Idiomatic Rust also requires that the programmer provides comments…
I think making things more explicit with "unsafe" is an advantage of Rust, but I think "far better" is a bit of an exaggeration. In C you need to audit pointer arithmetic, malloc/free, casts and unons. If you limit pointer arithmetic to a few safe accessor functions and have a documented lifetime rules, this is also relatively simple to do (more difficult than "grep" but not much). Vice versa, if you use a lot of "un…