mem-isolate

Languages and libraries

rust crate

SHOW HN2025

113points
70comments
#661of 3,837 in 2025
Top 18%of 2025 by points

How HN took it

RoastedHalf or more of the comments are critical

2 positive, 9 neutral or asking, 1 mixed, 15 critical, out of 27 comments about the project. Thread score -0.41.

Idea: 2 for, 6 againstExecution: 0 for, 4 againstPerformance: 0 for, 4 againstDocs: 0 for, 1 against

The thread, comment by comment

Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.

positive neutral or mixed critical about another commenter or something else the maker

What HN said

What people liked

  • Clever trick for when you are in a bind

    From 1 comment
  • Interesting and clever idea

    From 2 comments
    • This is super interesting! I would be very curious to see how we can get into even more safety when running WebAssembly in Wasmer with this crate (similar to V8 isolates).…
      syrusakbary on HN
    • That's actually a pretty clever idea, I never realized you can that. Thanks for sharing.
      panstromek on HN

Objections

  • Fork is unsafe in multithreaded programs and can deadlock

    From 3 comments
    • This isn't mentioned anywhere on the page, but fork is generally not a great API for these kinds of things. In a multi-threaded application, any code between the fork and exec…
      destroycom on HN
    • 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;…
      Svetlitski on HN
    • 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,…
      kelnos on HN
  • Does not make unsafe code safe in the Rust sense

    From 2 comments
    • I don't think this meets the definition of "safe" in "safe" Rust: "safe" doesn't just mean "won't crash due to spatial memory errors," it means that the code is in fact spatially…
      woodruffw on HN
    • It's not just that it won't crash, it means that an exploit in the unsafe code won't allow corrupting memory used by the rest of the program
      NoahKAndrews on HN
  • Fork is too slow for hot paths

    From 2 comments
    • This is cool from a theoretical perspective, but `fork()` can be prohibitively expensive, at least on the hot path. This is a cool tool that should be used with care.
      djha-skin on HN
    • Which pretty much makes this whole thing pointless since a lot of unsafe code exists purely for performance reasons.
      VWWHFSfQ on HN
  • Child process still has the same privileges and secrets, so isolation is weak

    From 1 comment
    • This is pretty immaterial from an exploit development perspective: 1. The forked process has a copy of the program state. If I'm trying to steal in-process secrets, I can do it…
      woodruffw on HN

Requests

  • Clarify limitations and warnings in docs

    From 2 comments
    • 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,…
      kelnos on HN
    • At the risk of sounding overly harsh, I just don’t think this crate is a particularly good idea. I really do mean this as constructive criticism, so let me explain my reasoning.…
      Svetlitski on HN
  • Support mutation of arguments and shared state

    From 2 comments
    • This 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…
      TheDong on HN
    • > It forces functions to be memory pure (pure with respect to memory), even if they aren't. What if the unsafe code is not supposed to be pure but mutates some memory? For…
      corank on HN

Questions

  • Why use a pipe instead of shared memory

    From 1 comment
  • What unsafe code motivated this

    From 1 comment
    • I'd love to know what horrible library / code the author was using where sandboxing it like this seemed like the best alternative.
      slashdev on HN

Alternatives named

  • OS sandboxing and process separation (seccomp, Landlock, AppContainer, Chromium sandbox)

    From 3 comments
    • Rather design the application from the start to use multiple processes, OS IPC and actual OS sandboxing APIs. Pseudo sandboxing on the fly is an old idea and with its own issues,…
      pjmlp on HN
    • My starting point would be Chromium's documentation, as - presumably - chrome is one of the most widely used and battle tested, user-facing, third party sandboxes running on end…
      MaulingMonkey on HN
    • Linux also has Landlock now. macOS sandboxing is notoriously under-documented, has sharp edges, and is nowhere near as expressive as Linux sandboxing.
      amarshall on HN
  • Compile C to WebAssembly then to C (wasm2c) as in Firefox

    From 1 comment
    • 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-webassembly/ Firefox…
      nextaccountic on HN
  • Sanitizers such as -fsanitize=undefined

    From 1 comment
    • You can skip all this nonsense with ``` -fsanitize=undefined ```
      dmitrygr on HN

Category, keywords, summaries and labels on this page were made by AI (Thread Reader v2) and not checked by hand. Each point links to the comments it came from.

Add a badge to your READMEShown on HackerShow
[![Shown on HackerShow](https://hackershow.org/badge.svg)](https://hackershow.org/show/43601301)