Linux Sandboxes and Fil-C • Hacker News Board

Re: Linux Sandboxes and Fil-C

#131

Post by sureglymop » Sun, Dec 14, 2025, 9:32 PM UTC

pjmlp wrote: post #68

burakemir wrote: post #30

My trouble with separate categories "memory safety technology" and "sandboxing technology" is that something like WASM execution is both: * Depending on how WASM is used, one gets safety guarantees. For example, memory is not executable. * Privileges are reduced as a WASM module interacts with the environment through the WASM runtime and the embedder Now, when one compiles C to WASM one may well compile things with b…

Depends on how it is used is already a sign that WebAssembly isn't really as safe as being sold, by many of its advocates, versus other bytecode formats. Like, C is actually really safe, it only depends on how it is being used. People only have to enumerate the various ways and tools to write safe code in C. Problem solved, or so we get to believe.

WASM is just a bytecode format for a stack based vm. Granted it is weirdly named, the actual "Assembly" equivalent is WAT.

But the point is, it is a format specification, which has nothing to do with safety. You can implement a totally unsafe WASM runtime if you so choose. Personally I think it's not a bad thing, at least we have something like it that can run in a browser environment. But I am curious to know why you dislike it so much.

Re: Linux Sandboxes and Fil-C

#132

Post by dnr » Sun, Dec 14, 2025, 9:40 PM UTC

quotemstr wrote: post #49

pizlonator wrote: post #48

Earlier quoted context omitted.

> An attacker who can get a program to access an offset he controls relative to P2 can access P1 if P2 is torn such that it's still coupled, at the moment of adversarial access, with P1's capability Only if the program was written in a way that allowed for legitimate access to P1. You’re articulating this as if P1 was out of thin air; it’s not. It’s the capability you loaded because the program was written in a way t…

> Only if the program was written in a way that allowed for legitimate access to P1. You’re articulating this as if P1 was out of thin air; it’s not. My program: if (p == P2) return p[attacker_controlled_index]; If the return statement can access P1, disjoint from P2, that's a weird execution for any useful definition of "weird". You can't just define the problem away. Your central claim is that you can take any old…

I'm not an expert here but I have to say this feels like a very weak objection.

p points to P1. One thread reads through p. Another thread races with that and mutates p to point to P2. The result is the first thread reads from either P1 or P2 (but no other object).

This seems totally fine and expected to me? If there's a data race on a pointer, you might read one or the other values, but not garbage and not out of bounds. I mean, if it could guarantee a panic that's nice, but that's a bonus, not required for safety.

Re: Linux Sandboxes and Fil-C

#133

Post by foldr » Sun, Dec 14, 2025, 9:48 PM UTC

tialaramex wrote: post #130

foldr wrote: post #120

Earlier quoted context omitted.

What I mean is, what’s to stop us saying that C upholds all the same guarantees that Rust does and that it’s the programmer that’s responsible for upholding them (just as the programmer is responsible in the case of Rust code marked ‘unsafe’)? This seems like a semantic game to avoid acknowledging that unsafe Rust comes with some of (though not all) of the same risks as C code. In short, the definitions are not impor…

And do you say that C offers these guarantees ? Real world C software does not read like software written by people who are in fact upholding those guarantees you say C could equally have. It reads as though they think such a guarantee is a joke or an irrelevance. It's not rare for me to run into people who think C's pointers are just indexing into a massive array of all RAM (or its equivalent on today's systems with…

You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language.

>And do you say that C offers these guarantees ?

No, that would be silly, and it's an illustration of why it is silly to say that a language guarantees X if it is the programmer who must check that X holds. If we go down that route (which, to repeat, would be silly), then we can make C safe without any technical changes just by adding some language to the standard saying that C programmers are obliged to ensure that their code maintains a certain list of invariants. When you say that "Rust makes the same guarantees regardless of the unsafe keyword", it seems to me that you are doing something equally pointless.

Re: Linux Sandboxes and Fil-C

#134

Post by azakai » Sun, Dec 14, 2025, 10:18 PM UTC

singpolyma3 wrote: post #76

pjmlp wrote: post #67

Earlier quoted context omitted.

Finally reality is catching up with the WASM sales pitch against other bytecode formats introduced since 1958, regarding security and how great it is over anything else.

Warm was great because it was lightweight and easy to target from any language and create any custom interaction API with the host. That's becoming less true as they bolt on features no one needed (GC) and popularize standardized interfaces that contain the kitchen sink (WASI) but these things can still be treated as optional so it can still be used for much more flexible use cases than java or .net

> features no one needed (GC)

WasmGC is absolutely necessary for languages like Dart, Kotlin, and Java, which are all using it right now successfully.

But I get that if you're compiling C or Rust then it might seem like it isn't useful.

Re: Linux Sandboxes and Fil-C

#135

Post by bit1993 » Sun, Dec 14, 2025, 11:39 PM UTC

foldr wrote: post #133

tialaramex wrote: post #130

Earlier quoted context omitted.

And do you say that C offers these guarantees ? Real world C software does not read like software written by people who are in fact upholding those guarantees you say C could equally have. It reads as though they think such a guarantee is a joke or an irrelevance. It's not rare for me to run into people who think C's pointers are just indexing into a massive array of all RAM (or its equivalent on today's systems with…

You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language. >And do you say that C offers these guarantees ? No, that would be silly, and it's an illustration of why it is silly to say that a language guarantees X if it is the programmer who must check that X holds. If we go down that route (which, to repeat, would be silly), then we can make C…

> ... then we can make C safe without any technical changes just by adding some language to the standard saying that C programmers are obliged to ensure that their code maintains a certain list of invariants.

In Rust you can use #![forbid(unsafe_code)] to totally forbid unsafe code in your codebase. Rust also checks for memory safety at compile time, these are strong guarantees that ensure that if the code compiles it is memory safe.

Re: Linux Sandboxes and Fil-C

#136

Post by foldr » Sun, Dec 14, 2025, 11:51 PM UTC

bit1993 wrote: post #135

foldr wrote: post #133

Earlier quoted context omitted.

You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language. >And do you say that C offers these guarantees ? No, that would be silly, and it's an illustration of why it is silly to say that a language guarantees X if it is the programmer who must check that X holds. If we go down that route (which, to repeat, would be silly), then we can make C…

> ... then we can make C safe without any technical changes just by adding some language to the standard saying that C programmers are obliged to ensure that their code maintains a certain list of invariants. In Rust you can use #![forbid(unsafe_code)] to totally forbid unsafe code in your codebase. Rust also checks for memory safety at compile time, these are strong guarantees that ensure that if the code compiles i…

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)

Re: Linux Sandboxes and Fil-C

#137

Post by bit1993 » Mon, Dec 15, 2025, 12:04 AM UTC

foldr wrote: post #136

bit1993 wrote: post #135

Earlier quoted context omitted.

> ... then we can make C safe without any technical changes just by adding some language to the standard saying that C programmers are obliged to ensure that their code maintains a certain list of invariants. In Rust you can use #![forbid(unsafe_code)] to totally forbid unsafe code in your codebase. Rust also checks for memory safety at compile time, these are strong guarantees that ensure that if the code compiles i…

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 as to why that part is unsafe.

Re: Linux Sandboxes and Fil-C

#138

Post by yjftsjthsd-h » Mon, Dec 15, 2025, 12:33 AM UTC

quotemstr wrote: post #102

pizlonator wrote: post #98

Earlier quoted context omitted.

> I will define "trustworthy system" as one in which the author acknowledges and owns limitations instead of iteratively refining private definitions until the limitations disappear. You know about this limitation that you keep going on about because it’s extremely well documented on fil-c.org

[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…

Wait, no, you just said

> I will define "trustworthy system" as one in which the author acknowledges and owns limitations

You can't then go on to complain that the author does document the limitations but considers the overall system good. Fil-C, by the definition you just espoused, is a "trustworthy system".

Re: Linux Sandboxes and Fil-C

#139

Post by jstarks » Mon, Dec 15, 2025, 1:20 AM UTC

quotemstr wrote: post #96

lifis wrote: post #79

Earlier quoted context omitted.

I think his argument is that you can have code this: user = s->user; if(user == bob) user->acls[s->idx]->has_all_privileges = true; And this happens: 1. s->user is initialized to alice 2. Thread 1 sets s->idx to ((alice - bob) / sizeof(...)) and s->user to Bob, but only the intval portion is executed and the capability still points to Alice 3. Thread 2 executes the if, which succeeds, and then gives all privileges to…

Exactly. I agree that this specific problem is hard to exploit. > Seems perhaps fixable by making pointer equality require that capabilities are also equal You'd need 128-bit atomics or something. You'd ruin performance. I think Fil-C is actually making the right engineering tradeoff here. My point is that the way Pizlo communicates about this issue and others makes me disinclined to trust his system. - His incorrect…

All I’m really hearing is that this guy rubs you the wrong way, so you’re not going to give him the benefit of the doubt that you’d give to others.

I mean, maybe you’re right that his personality will turn everyone off and none of this stuff will ever make it upstream. But that kind of seems like a problem you’re actively trying to create via your discourse.

Re: Linux Sandboxes and Fil-C

#140

Post by tialaramex » Mon, Dec 15, 2025, 1:42 AM UTC

foldr wrote: post #133

tialaramex wrote: post #130

Earlier quoted context omitted.

And do you say that C offers these guarantees ? Real world C software does not read like software written by people who are in fact upholding those guarantees you say C could equally have. It reads as though they think such a guarantee is a joke or an irrelevance. It's not rare for me to run into people who think C's pointers are just indexing into a massive array of all RAM (or its equivalent on today's systems with…

You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language. >And do you say that C offers these guarantees ? No, that would be silly, and it's an illustration of why it is silly to say that a language guarantees X if it is the programmer who must check that X holds. If we go down that route (which, to repeat, would be silly), then we can make C…

> You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language.

Quite some way up this thread pizlonator insists that each programming language defines memory safety differently, quantifying some as "weaker" or "stronger" and giving the example that Rust has the `unsafe` keyword and so that's weaker than Fil-C.

That's what we were discussing when you jumped in with your C hypothetical.

You apparently instead believe in a single universal "safety" and every language is either absolutely safe or unsafe according to foldr for whatever that's worth - but that's not what we were talking about.