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

81–90 of 162 posts

Re: Linux Sandboxes and Fil-C

#81

Post by tialaramex »

pizlonator wrote: post #51
quotemstr wrote: post #49

Earlier quoted context omitted.

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

> that's a weird execution for any useful definition of "weird". Weird execution is a term of art in the security biz. This is not that. Weird execution happens when the attacker can control all of memory, not just objects the victim program rightly loaded from the heap. > Your central claim is that you can take any old C program, compile it with Fil-C, and get a memory-safe C program. Yes. Your program is memory saf…

> Rust has a weaker definition if you consider that you can use `unsafe`

I don't see it. Rust makes the same guarantees regardless of the unsafe keyword. The difference is only that with the unsafe keyword you the programmer are responsible for upholding those guarantees whereas the compiler can check safe Rust.

Re: Linux Sandboxes and Fil-C

#82

Post by razighter777 »

iberator wrote: post #72

Any wizard here? Fill-C vs Rust? Realistic comments without hype.

Both are great tech but solve the problem of safety differently. I would say Fil-c is great for non-performance-critical (think like somewhere between c and go/java, still very fast) existing C programs where compatibility with the existing program / security is a big concern. think ffmpeg, nginx, sudo.

Fil-c:

- You have a great existing c program that may have memory bugs, and you wanna make it safer.

- Or you wanna write a new program in c, and be extra sure it's safe and don't mind a little performance penalty.

- Or you wanna find subtle memory bugs by building your c program with fil-c (asan style) and disable it for performance in your release build.

Rust is great when you want to build a new codebase from scratch, and have the time and patience to deal with the borrow checker. It also gives you some thread safety, (which is different from memory safety) at the development time cost of dealing with the borrow checker. Rust:

- A new codebase where you need multithreading and safety, and want excellent performance

- You need a broad ecosystem of existing packages

- Your problem space benefits from a robust type system.

Re: Linux Sandboxes and Fil-C

#83

Post by IshKebab »

pjmlp wrote: post #66
IshKebab wrote: post #62

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…

> hardly any benefit over OS processes, talking over JSON-RPC

Hardly any benefit except portability and sandboxing, the main reasons WASM exists?

Re: Linux Sandboxes and Fil-C

#84

Post by zozbot234 »

IshKebab wrote: post #63
zozbot234 wrote: post #61

Earlier quoted context omitted.

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.

You wouldn't be able to get quite as fine-grained. One memory per object is probably horrifically slow. And I don't know about Fil-C, but CHERI at least allows capabilities (pointers with bounds) to overlap and subset each other. I.e. you could allocate an arena and get a capability for that, and then allocate an object inside that arena and get a smaller capability for that, and then get a pointer to a field in that…

One would probably just need to define WASM extensions that allow for such subsetting. Performance will probably be competitive with software implementations of CHERI (perhaps with varying levels of hardware acceleration down the road) which isn't that bad.

Re: Linux Sandboxes and Fil-C

#85

Post by pjmlp »

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 is only portable if the only thing it does is heating up CPU, given that everything else depends on the host.

Re: Linux Sandboxes and Fil-C

#86

Post by pjmlp »

zozbot234 wrote: post #61
pizlonator wrote: post #17

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.

Some WebAssembly runtimes now do support those parts of the specification.

Re: Linux Sandboxes and Fil-C

#90

Post by brabel »

seabrookmx wrote: post #60
procaryote wrote: post #54

Earlier quoted context omitted.

If you can rely on memory errors panicing before the memory error can have an effect, you're memory safe. Memory safety doesn't require "can't crash".

Exactly. Or Rust wouldn't be memory safe due to the existence of unwrap(). Not that crashing can't be bad, as we saw recently with Cloudflare's recent unwrap-based incident.

Even without unwrap, Rust could still crash on array out of bounds access. And probably more similar cases.
Post reply on HN