Thread

5x faster Edge Functions: V8 isolates to Firecracker MicroVMs

229 points · 106 comments · jbott

aaronvg · 1790796164 · focus · HN ↗
Wish it explained where the v8 isolate latency is coming from compared to microvms
1. vmg12 · 1790796414 · focus · HN ↗
  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.
  1. dummydummy1234 · 1790797703 · focus · HN ↗
    Why are v8 isolates bad, I see speculative execution hacks, but are there others?
    binsquare · 1790798213 · focus · HN ↗
    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 · 1790803014 · focus · HN ↗
    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.
    tbrockman · 1790877580 · focus · HN ↗
    But those same things (and more), in the majority case of completely benign workloads, are significantly better for resource utilization and performance.
    I don't think their model is "run everything in V8 isolates as the only isolation primitive", I believe it's closer to "run things with V8 isolates as the floor, dynamically trading efficiency for security in response to runtime (and I'd also assume static) analysis". They also add restrictions to make it more difficult/expensive for code to exploit side-channels (ex. changing the resolution and behavior of `performance.now ` and `Date.now` , no multithreading, no SharedArrayBuffer , etc.). Code attempting to exploit side-channels usually has a fingerprint. If you can classify it well enough, and the cost of a false positive is paying for the process isolation you'd otherwise have paid for everything all the time, you probably end up with healthier margins.
    I don't disagree that there are real issues, but I don't think that Cloudflare necessarily misrepresents them (though they do perhaps fall quite a bit short of saying "don't run security critical workloads on our platform"). If you can accept the risk though, you get cheap compute with someone else managing all the infrastructure. If you can't, you probably shouldn't be using Workers (and maybe not even cloud compute in general).
    Sources:
    * <a href="https://gruss.cc/files/scalableisolation.pdf" rel="nofollow">https://gruss.cc/files/scalableisolation.pdf
    * <a href="https://arxiv.org/html/2110.04751v1" rel="nofollow">https://arxiv.org/html/2110.04751v1
    * <a href="https://arxiv.org/pdf/2608.17043" rel="nofollow">https://arxiv.org/pdf/2608.17043
    * <a href="https://blog.cloudflare.com/revisiting-spectre-attacks-on-workers/" rel="nofollow">https://blog.cloudflare.com/revisiting-spectre-attacks-on-wo...
    kentonv · 1790880930 · focus · HN ↗
    It's true that V8 isolates are more risky than micro VMs*. However, it's also true that micro VMs are more risky than giving each tenant their own machine.
    At some point you have to decide where along the spectrum you want to put the boundary of "acceptable" for your workload.
    Some people argue that isolates are below the necessary threshold and micro VMs are above it. But this isn't really based on any rigorous mathematical analysis, it's mostly vibes. It used to be that people said VMs weren't secure enough for critical workloads, but few people say that these days.
    I would argue that we (Cloudflare) have demonstrated that the isolate model can work fine if done carefully: we've been doing it this way for nearly a decade with no breaches.
    * Not "strictly riskier", though. There are some risks micro VMs have that V8 isolates do not. Micro VMs that allow tenants to run arbitrary x86 code place a huge amount of trust in the hardware to be exactly correct; a trusted JIT makes it much easier to work around hardware bugs when they are found.
    vmg12 · 1790892115 · focus · HN ↗
    I'm the original poster that said v8 isolates aren't a great sandbox and I would state that I didn't say they were impossible to use as a sandbox. I know you all at cloudflare are doing a ton on top of v8 isolates to make them secure.
    I think as a general rule you'd just want multiple uncorrelated layers of isolation. If you aren't willing to spend what cf does on securing v8 isolates I think process isolation + seccomp + v8 isolates might be enough, otherwise all of our browsers would be ticking time bombs.
    tbrockman · 1790904715 · focus · HN ↗
    I agree! Just to be clear, by "security critical" I mean the tier where you'd also refuse shared VMs. I'm not convinced most people have workloads and threat models that actually need the isolation they say they want, nor a fully considered notion of what their preferred primitive buys them (per your footnote, and any number of other issues I'm completely unaware of). But I like and appreciate Workers, and am grateful to be paying less because Cloudflare bin-packed more.
    phickey · 1790798283 · focus · HN ↗
    Despite naming them isolates, the V8 team does not consider them to be a security boundary.
    vmg12 · 1790800727 · focus · HN ↗
    The v8 JIT is very complex and can lead to sandbox escapes if there are type confusion bugs.
  2. torginus · 1790801275 · focus · HN ↗
    But I guess they are good enough to isolate multiple instances of the same code, ran by the same customer in parallel.
    Normal_gaussian · 1790803125 · focus · HN ↗
    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.
    torginus · 1790842655 · focus · HN ↗
    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.
2. wmf · 1790797782 · focus · HN ↗
  "In the past, requests went out to a hosted execution service."
  They were outsourcing to another company so there's plenty of room for overhead to creep in.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.