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

Show HN: I built a Rust crate for running unsafe code safely

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Show HN: I built a Rust crate for running unsafe code safely

#41

Post by im3w1l »

jesprenj wrote: post #32

Why use a pipe to communicate instead of shared memory?

It's much easier to reason about a child process sending you possibly corrupt objects over a pipe, compared to a child process possibly corrupting shared memory as you are reading it. I've read enough about processor level memory barriers to understand I don't really understand that at all.

Re: Show HN: I built a Rust crate for running unsafe code safely

#42

Post by dmitrygr »

nextaccountic wrote: post #37

There is a way to sandbox native code without forking to a new process, and it looks like this https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the…

You can skip all this nonsense with

    -fsanitize=undefined

Re: Show HN: I built a Rust crate for running unsafe code safely

#43

Post by Georgelemental »

dmitrygr wrote: post #42
nextaccountic wrote: post #37

There is a way to sandbox native code without forking to a new process, and it looks like this https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the…

You can skip all this nonsense with -fsanitize=undefined

Not foolproof, doesn’t catch everything.

Re: Show HN: I built a Rust crate for running unsafe code safely

#44

Post by [deleted] »

nextaccountic wrote: post #37

There is a way to sandbox native code without forking to a new process, and it looks like this https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the…

[deleted]

Re: Show HN: I built a Rust crate for running unsafe code safely

#45

Post by cyberax »

dmitrygr wrote: post #42
nextaccountic wrote: post #37

There is a way to sandbox native code without forking to a new process, and it looks like this https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the…

You can skip all this nonsense with -fsanitize=undefined

It won't do anything for data races, for example.

Re: Show HN: I built a Rust crate for running unsafe code safely

#46

Post by Svetlitski »

This is likely to violate async-signal-safety [1] in any non-trivial program, unless used with extreme care. Running code in between a fork() and an exec() is fraught with peril; it's not hard to end up in a situation where you deadlock because you forked a multi-threaded process where one of the existing threads held a lock at the time of forking, among other hazards.

[1] https://man7.org/linux/man-pages/man7/signal-safety.7.html

Re: Show HN: I built a Rust crate for running unsafe code safely

#47

Post by panstromek »

nextaccountic wrote: post #37

There is a way to sandbox native code without forking to a new process, and it looks like this https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the…

That's actually a pretty clever idea, I never realized you can that. Thanks for sharing.

Re: Show HN: I built a Rust crate for running unsafe code safely

#48

Post by krick »

loeg wrote: post #40

As a joke, it's funny. Obviously you would not want to actually deploy this. I feel like most comments are too quick to criticize using this in prod (don't!) and missing the point.

It's much more problematic how many comments praise it not as a joke. And, honestly, it doesn't seem like it was intended as a joke. It's a legitimately bad idea, that is treated as a good idea by some scary number of people.

Re: Show HN: I built a Rust crate for running unsafe code safely

#50

Post by pclmulqdq »

woodruffw wrote: post #22
mirashii wrote: post #19

Earlier quoted context omitted.

Even better, this library, with its use of unsafe and fork underneath, introduces a whole new class of undefined behavior to a program by providing a safe interface over an unsafe API without actually enforcing the invariants necessary for safety. In order for the fork() it calls to be safe, it needs to guarantee a bunch of properties of the program that it simply cannot. If this gets used in a multithreaded program…

Yep. I wanted to start from the high-level point of "safe doesn't mean doesn't crash," but you're right that the technique itself is unsound.

In rust terminology, "safe" actually implies more frequent crashes on untrusted inputs.
Post reply on HN