Please please please add a big huge warning to your crate that it should never be used in multi-threaded programs. fork() is not safe when there is more than one thread present, as the child process can easily deadlock (or worse) if the fork() happens at just the wrong time with respect to what other threads are doing.
Show HN: I built a Rust crate for running unsafe code safely
51–60 of 72 posts
Re: Show HN: I built a Rust crate for running unsafe code safely
#52If you can afford to sacrifice that much performance just to run some potentially unsafe code, then you can probably afford to not be writing Rust in the first place and instead use a garbage-collected language.
I think it is basically a garbage collector, just one that operates on a per-function level instead of at the general level of the program
It's not really though because the UB still exists and can be exploited, just in a forked process.
Re: Show HN: I built a Rust crate for running unsafe code safely
#53>>We call this trick the "fork and free" pattern. It's pretty nifty. It should be called "fork and see" pattern instead :D
“fork around and find out”
Re: Show HN: I built a Rust crate for running unsafe code safely
#54Earlier quoted context omitted.
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.
Why do you think this? The closest thing in “common” Rust would be unwraps/panics, but these are (1) not crashes per se, and (2) probably not more common than they would be in an equivalent C codebase.
Re: Show HN: I built a Rust crate for running unsafe code safely
#55Earlier quoted context omitted.
In rust terminology, "safe" actually implies more frequent crashes on untrusted inputs.
Why do you think this? The closest thing in “common” Rust would be unwraps/panics, but these are (1) not crashes per se, and (2) probably not more common than they would be in an equivalent C codebase.
"Panics are not crashes" is a new one. I'm referring to the fact that the rust code panics at the slightest sign of discomfort.
And they are very much more common than in most C codebases. C codebases are generally often overly permissive in what they accept (hence to security bugs). Rust made a different trade.
Re: Show HN: I built a Rust crate for running unsafe code safely
#56This also means the function might not do what you want, i.e. if it takes a `&mut T` argument, that argument can't actually be mutated, and anything that relies on interior mutability, even if it's not a mut argument, also won't work.
Rust allows memory-impure things, like interior mutability of arguments, so you can get different (i.e. incorrect) results when using this to run otherwise fine rust code.
For example:
fn some_fn(x: &mut i32) {
*x = 2;
}
fn main() {
let mux x = 1;
mem_isolate::execute_in_isolated_process(|| {
some_fn(&mut x);
}).unwrap();
println!("{x}"); // prints '1' even though without 'mem_isolate' this would be 2
}Re: Show HN: I built a Rust crate for running unsafe code safely
#57If you want this to be fast when used in processes with large resident set sizes create a thread and there use `vfork()` rather than `fork()`.
Re: Show HN: I built a Rust crate for running unsafe code safely
#58this seems like a good place to ask, I don’t write very much unsafe Rust code… but when I do, it’s because I’m calling the Win32 API. Tools like valgrind do not work on windows, and I am nowhere near smart enough to know the entire layout of memory that should exist. When using Windows and calling system system functions, there’s a lot of casting involved; to convert wide characters and DWORDS to rust primitives for…
> I don’t write very much unsafe Rust code… but when I do, it’s because I’m calling the Win32 API.
Check out windows-rs instead.
Re: Show HN: I built a Rust crate for running unsafe code safely
#59There 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.
Note that the reason why this works for sandboxing is that wasm code gets its own linear memory that is bounds-checked. Meaning that the generated C code will contain those checks as well, with the corresponding performance implications.
Re: Show HN: I built a Rust crate for running unsafe code safely
#60Earlier quoted context omitted.
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.
No, "safe" implies that there's no undefined behavior across all inputs. Whether that's a crash or not is still up to the implementer of the code in question, same as any other language. It is your choice whether to use interfaces that crash or do not crash, that is not forced upon you by the language.