Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Sandboxes and Fil-C

fil-c.org

Post reply on HN
Print view View original

121–130 of 162 posts

Re: Linux Sandboxes and Fil-C

#121

Post by apitman »

mhjkl wrote: post #113
singpolyma3 wrote: post #76

Earlier quoted context omitted.

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

There’s no guarantee the toolchains will support WASM “preview” forever and make the bloat optional, and even if they do you could still end up in an ecosystem where it would be unviable. At some point you’re probably better off just compiling to RISCV and using an emulator library instead.

Fortunately core wasm is simple enough for a single person to implement an interpreter or even compiler for.

Even if the major engines continue to pile on complexity we have a pretty good escape hatch I think.

Re: Linux Sandboxes and Fil-C

#122

Post by kllrnohj »

IshKebab wrote: post #83
pjmlp wrote: post #66

Earlier quoted context omitted.

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…

> hardly any benefit over OS processes, talking over JSON-RPC Hardly any benefit except portability and sandboxing, the main reasons WASM exists?

WASM sacrifices guest security & performance in order to provide mediocre host sandboxing, though. It might be a useful tradeoff sometimes, but proper process-based sandboxing is so much stronger and lets the guest also have full security & performance.

Re: Linux Sandboxes and Fil-C

#123

Post by apitman »

creatonez wrote: post #34
fragmede wrote: post #25

Which requirements does a full blown virtual machine not meet? By leaning on that as the sandbox, we get Qubes, but maybe I don't know what I'm talking about.

When it comes to VMs, most things are solved and have near native performance, but desktop graphics are not. Due to limitations in GPU architecture, you usually have to dedicate an entire GPU to the VM to have reasonable graphical acceleration. Qubes doesn't solve this either, IIRC the apps running in VMs are glued to the host with X11 forwarding without any acceleration support.

For what it's worth the Intel B50 supports GPU virtualization and software support seems to be improving quickly. Really hoping this blows the lid off over the next couple years.

Re: Linux Sandboxes and Fil-C

#124

Post by IshKebab »

kllrnohj wrote: post #122
IshKebab wrote: post #83

Earlier quoted context omitted.

> hardly any benefit over OS processes, talking over JSON-RPC Hardly any benefit except portability and sandboxing, the main reasons WASM exists?

WASM sacrifices guest security & performance in order to provide mediocre host sandboxing, though. It might be a useful tradeoff sometimes, but proper process-based sandboxing is so much stronger and lets the guest also have full security & performance.

How is process-based sandboxing stronger? Also the performance penalty is not only due to sandboxing (I doubt it's even mostly due to it). Likely more significant is the portability.

Re: Linux Sandboxes and Fil-C

#126

Post by kragen »

azakai wrote: post #117
kragen wrote: post #108

Earlier quoted context omitted.

Correct me if I'm wrong, but with LLVM on Wasm, I think casting a function pointer to the wrong type will result in you calling some totally unrelated function of the correct type? That sounds like the opposite of safety to me. I agree about the call stack, and don't know about GC.

That is incorrect about function pointers: The VM does check that you are calling the right function type, and it will trap if the type does not match. Here it is in the spec: > The call_indirect instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must have type funcref. Since it may contain functions of heterogeneous type, the callee is dynamically ch…

Hmm, I wonder if I was confusing emscripten's asm.js approach with its approach to Wasm. Thank you!

Re: Linux Sandboxes and Fil-C

#127

Post by tialaramex »

jancsika wrote: post #110
tialaramex wrote: post #106

Earlier quoted context omitted.

But the definition is what we're talking about, not whether you make mistakes. Of course it's important that safe Rust is checked by the compiler, but that's crucially not part of how safety is defined. I would guess that somebody more on the pulse of C's safety efforts could tell you whether they have a definition of memory safety for C or whether they're comfortable with an existing definition from somebody else.

Since you know C and you know Rust: I'm curious what you make of quotemastr's point about a race causing a mismatch between the pointer's capability and its index. First off, in your estimation can this realistically be exploited to wreak havoc on extant C programs compiled using Fil-C? Second, is such a mismatch able to happen in safe Rust? Third, is such a mismatch able to happen in unsafe Rust? Edit: clarification…

I can try.

"Wreak havoc" is a very vague claim. Instinctively the tearing feels like something very difficult to usefully exploit, but, we know historically that the only people who can reliably tell you whether it was difficult are the attackers actually trying to do it. Don't believe the defenders.

AIUI this capability versus value distinction is a Fil-C thing. So, that's not a thing in Rust at all. In Safe Rust the pointer types, which is what we care about here, aren't very interesting because safe Rust can't dereference them, safe Rust is fine with you making a pointer from the word "LAUGHING" (not a pointer to the string, just the literal bytes in ASCII, but treated as a pointer) or from just some random bytes you found in a data file, because it's not allowed to dereference them so, cool, whatever, no harm no foul.

In unsafe Rust we're allowed to dereference valid pointers, but it's our job to ensure we obey that rule about validity, it being our job to obey rules is what "unsafe" means. So, that silly "LAUGHING" pointer isn't valid, it's just pointer-shaped toxic material. Even if, by coincidence, a pointer you have happened to have the same address as that pointer, in both C and Rust it's not OK to just go around dereferencing invalid pointers, they are not offsets into an imaginary huge array of all memory even though some C programmers act like they are.

Ignoring the Fil-C specific capabilities, in Rust the tearing issue is a matter of synchronization, which is something Rust cares about as part of delivering "fearless concurrency". Rust's marker traits Send and Sync are good place to start learning about that. Yes, we could unsafely implement these marker traits in unsafe Rust when we shouldn't, and thus enable what I imagine you'd call havoc.

So, mostly the problem is that your question is (unintentionally) too vague to answer well but I hope I was at least somewhat helpful.

Re: Linux Sandboxes and Fil-C

#128

Post by foldr »

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…

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 from an expert.

Re: Linux Sandboxes and Fil-C

#129

Post by jacquesm »

IshKebab wrote: post #124
kllrnohj wrote: post #122

Earlier quoted context omitted.

WASM sacrifices guest security & performance in order to provide mediocre host sandboxing, though. It might be a useful tradeoff sometimes, but proper process-based sandboxing is so much stronger and lets the guest also have full security & performance.

How is process-based sandboxing stronger? Also the performance penalty is not only due to sandboxing (I doubt it's even mostly due to it). Likely more significant is the portability.

> How is process-based sandboxing stronger?

Because the guarantees themselves are stronger, process isolation is something we have decades of experience with, it goes wrong every now and then but those are rare instances whereas what amounts to application level isolation is much weaker in terms the guarantees it that it provides and the maturity level of the code. That suggests that if you base your isolation scheme on processes rather than 'just' sandboxing that you will come out ahead and even with all other things the same you'd have one more layer in your stack of swiss cheese slices. A VM would offer another layer of protection on top of that, one with yet stronger guarantees.

Re: Linux Sandboxes and Fil-C

#130

Post by tialaramex »

foldr wrote: post #120
tialaramex wrote: post #106

Earlier quoted context omitted.

But the definition is what we're talking about, not whether you make mistakes. Of course it's important that safe Rust is checked by the compiler, but that's crucially not part of how safety is defined. I would guess that somebody more on the pulse of C's safety efforts could tell you whether they have a definition of memory safety for C or whether they're comfortable with an existing definition from somebody else.

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 virtual addressing), that's not just not in the same ballpark as a safe C program, that's playing a different sport on another continent.

Post reply on HN