| ▲ | vmg12 3 hours ago |
| 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. |
|
| ▲ | torginus 2 hours ago | parent | next [-] |
| But I guess they are good enough to isolate multiple instances of the same code, ran by the same customer in parallel. |
| |
| ▲ | Normal_gaussian an hour ago | parent [-] | | 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. |
|
|
| ▲ | dummydummy1234 3 hours ago | parent | prev [-] |
| Why are v8 isolates bad, I see speculative execution hacks, but are there others? |
| |
| ▲ | phickey 3 hours ago | parent | next [-] | | Despite naming them isolates, the V8 team does not consider them to be a security boundary. | |
| ▲ | vmg12 2 hours ago | parent | prev | next [-] | | The v8 JIT is very complex and can lead to sandbox escapes if there are type confusion bugs. | |
| ▲ | binsquare 3 hours ago | parent | prev [-] | | 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 | | |
| ▲ | londons_explore an hour ago | parent [-] | | 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. |
|
|