Hacker News Reader

Comment by vmg12 | Hacker News Reader

v8 isolates aren't actually a great sandbox and I would not trust them implicitly in the AI era. This is probably why they wrap them in an additional sandbox.

View on HN

But I guess they are good enough to isolate multiple instances of the same code, ran by the same customer in parallel.

Without commenting on v8 isolates specifically, this doesn't necessarily hold in any isolation situation; many customers are running code on behalf of their customers, which are often submitting jobs on behalf of theirs, and so on. Isolation breaches within a platform customer can result in significant cross-user data breaches.

You're right, but there are cases when the risk can be managed. Like if you're running an auth lambda in one isolate, and another isolate is running the exact same copy of the code, I'd say malicious exploitation would be low enough a risk, that I'd be comfortable running things like this.

And I'd say this even is a majority use case.

Why are v8 isolates bad, I see speculative execution hacks, but are there others?

Despite naming them isolates, the V8 team does not consider them to be a security boundary.

v8 isolates are still shared kernel

while microvm's are separate kernel + hardware virtualization through hypervisor guarantees

I wouldn't call it bad either, just different tools for different things

Not only are they shared kernel... They're shared process, shared address space, shared memory pool and allocator... In fact, there is very little isolated about them at all.

I bet there are a million ways to cause side channels allowing learning about other code or data on the same machine, and just one V8 bug (of which there have historically been thousands) let's you take over or modify code in another isolate.

The v8 JIT is very complex and can lead to sandbox escapes if there are type confusion bugs.

Reply on news.ycombinator.com