I literally linked to the commit where V8 is indeed unanimously making that decision. If you clear the indirect branch table when transitioning to and from all untrusted programs, what's your threat model again?
> I get WASM doesn't want to include malloc/free, but the problem is it didn't include paging-based allocation APIs. It used a nonsense linear growth heap design that doesn't match anything about how memory works on any platform and has been obsolete for 20+ years.
Go read the WASM spec. It's explicitly is designed for multiple linear regions, just how mmap works. It just didn't make it into the MVP.
And for things where retpoline isn't needed it's unambiguously wrong (wrong in that runtime is slower than it should be for no gain). What are you not getting about that? They made a decision that when it's wrong it's still safe, but it's still going to be wrong for a non-trivial amount of users.
> Go read the WASM spec. [...] It just didn't make it into the MVP.
Yes, I know, that's why I said what I said. Which was correct and supported by both the spec and your statement just now...?
We're not talking about hypothetical future WASM, we're talking about WASM as it exists today and what problems it can/can't effectively handle.
No, you're not understanding.
retpoline doesn't keep you from attacking others, it keeps you from being attacked. But not everything handles sensitive data and thus doesn't care about being attacked, and doesn't want to pay the cost of the retpoline that they didn't need at all.
How can a WASM app signal "I need retpoline because I have secrets to protect" from "I don't give a damn about retpoline because there's no secret data in my process space at all"?
That's not a decision WASM can unanimously make on behalf of others.
> You can implement all of the malloc protection strategies that OpenBSD uses in user space.
No, you literally can't. WASM doesn't have the APIs necessary to do that. It doesn't have mmap & mprotect. Those are in the "proposals we might consider" future section of WASM. But WASM today cannot implement a malloc/free on-par with those in actual libc implementations on major platforms. To say nothing of debug tools like valgrind.
> OpenSSL's sin wasn't re-implementing malloc; it was re-implementing it poorly (and not bounds checking input from attacker controlled packets).
So the solution to people re-implementing malloc badly is to force everyone to re-implement malloc? How does that follow at all?
I get WASM doesn't want to include malloc/free, but the problem is it didn't include paging-based allocation APIs. It used a nonsense linear growth heap design that doesn't match anything about how memory works on any platform and has been obsolete for 20+ years.
This isn't a big deal in the hyper specific context that WASM is actually targeting, but it is a big deal if you're talking about shoving WASM in places it never had any intention of being.