Stream: git-wasmtime

Topic: wasmtime / issue #13216 Enable Wasm GC by default

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2026 at 21:56):

fitzgen assigned fitzgen to issue #13216.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2026 at 21:56):

fitzgen opened issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2026 at 21:56):

fitzgen added the wasm-proposal:gc label to Issue #13216.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2026 at 21:57):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (Apr 28 2026 at 17:46):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (Apr 28 2026 at 18:35):

alexcrichton commented on issue #13216:

One other open question I've been thinking: the design of Wasmtime's GC is such that the GC itself is more sandboxed than relying on raw malloc, for example, but in practice the net effect of the implementation is that this downgrades the severity of a heap corruption bug from a "critical maybe RCE CVE" to a "moderate DoS CVE". That seems like a net win no matter what, but it still means that heap corruption bugs are a CVE just like before.

The open question here that I think would be worth considering is: should we go a step further? For example all heap indexing operations right now are panic-y throughout the implementation. Like with component-model-async, should those all use a bail_bug! lookalike thing? Panic-in-debug-mode but return-error-in-release-mode for example.

My thinking here is that if do truly want to plan for heap corruption bugs to be routine enough that we don't want to assign a CVE to all of them we probably need to go the whole distance of closing this off as a CVE vector (as best we can at least).

view this post on Zulip Wasmtime GitHub notifications bot (Apr 28 2026 at 18:36):

alexcrichton edited a comment on issue #13216:

One other open question I've been thinking: the design of Wasmtime's GC is such that the GC itself is more sandboxed than relying on raw malloc, for example, but in practice the net effect of the implementation is that this downgrades the severity of a heap corruption bug from a "critical maybe RCE CVE" to a "moderate DoS CVE". That seems like a net win no matter what, but it still means that heap corruption bugs are a CVE just like before.

The open question here that I think would be worth considering is: should we go a step further? For example all heap indexing operations right now are panic-y throughout the implementation. Like with component-model-async, should those all use a bail_bug! lookalike thing? Panic-in-debug-mode but return-error-in-release-mode for example.

My thinking here is that if we do truly want to plan for heap corruption bugs to be routine enough that we don't want to assign a CVE to all of them we probably need to go the whole distance of closing this off as a CVE vector (as best we can at least).

view this post on Zulip Wasmtime GitHub notifications bot (Apr 28 2026 at 21:52):

fitzgen commented on issue #13216:

if we do truly want to plan for heap corruption bugs to be routine

Routinely having heap corruption bugs is most definitely not the plan. (Not that bugs are ever the plan, but still.)

My gut reaction is that doing the bail_bug! thing for the GC would be fairly invasive, likely harm performance, and might not be as effective here as it is for CM async:

The only way to really address these points at the same time, AFAICT, is to self-host the whole collector in Wasm. But we've already talked about how we don't want that on the critical path for shipping Wasm GC.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 29 2026 at 01:09):

alexcrichton commented on issue #13216:

On one hand I do agree that we of course aren't planning to have bugs, but on the other hand I feel like history shows that we have consistently had bugs and peer engines also are generally known to have routine bugs/issues related to GC things. Part of the assumption of the sandboxed design is effectively assuming that these bugs will exist, and personally I feel that we should do our best to see that all the way through and strive to completely close off a class of CVEs.

I agree that GC code is largely infallible and additionally that this will harm performance. That was also true of component-model-async, however. There are methods that now return a Result purely for "we got states mixed up" and all the host code is certainly slowed down by returning a Result everywhere. I feel that the performance critical parts of GC (e.g. collection/sweeping/allocation) all have a solid path to become as-fast-as-possible through self-hosted wasm as well.

I also don't quite agree that it'll be less effective than component-model-async. Even with component-model-async there are still paths that panic to become a DoS, for example. In component-model-async there's also quite a lot of trampolines to manage and interactions with unsafe code. Despite all this, however, I think it was very much the right decision to move to bail_bug! instead of panicking. I agree it's not the most idiomatic, but it's so much easier to review code and not have to try to review all .unwrap() operations for "ok but can this actually panic?". It doesn't mean we're 100% secure from bugs but this is always about defense in depth layers. In other words I don't think the existence of complicated JIT code and GC impl code should dissuade us from making the rest of the system have more defense layers. If anything we should be focusing more on the code we can't add another layer to, and right now that's not the most feasible as it's considered equivalent to everything else.

I'm also happy to talk this over in a meeting some more, but personally I feel that we have a pretty compelling case to removing panics here. I feel that the stars are aligned in basically the same manner as component-model-async where I feel it's been quite successful at downgrading would-be-CVEs to "just a bug".

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2026 at 17:54):

alexcrichton commented on issue #13216:

I've attempted to prototype what it might look like to "return Result everywhere" with this commit. The main notable changes are:

One thing I've additionally realized is that we'd need to pay special attention to the exnref implementation. I realized since we store (InstanceId, DefinedTagIndex) raw within exnref which, if corrupted, could pretty easily trigger panics elsewhere as well. I haven't audited if memory unsafety is possible in the face of corruption here.

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2026 at 17:55):

alexcrichton commented on issue #13216:

Oh, also, I ran this against the recently-added splay benchmark in Sightglass and "fallible everything" was 2% faster than before, which I suspect is basically in-the-noise, so it at least doesn't have a huge effect on that. I'd expect the primary performance penalty to be the embedder API, however, which the splay Sightglass benchmark doesn't exercise.

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2026 at 17:57):

alexcrichton edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2026 at 18:42):

alexcrichton commented on issue #13216:

Ok I've dug more into a few things. First is exnref and instance/tag indexes. That can cause panics through the embedder API via ExnRef::tag and then using the result. Panics/corruption can't happen through internal usage, however. If a corrupt exception were thrown then it would be caught by the wrong handler, and then if that handler read out invalid GC fields it'd be like any other "plain old" reading corrupted GC heap values.

The next was poking at https://github.com/bytecodealliance/wasmtime/issues/13112 as a somewhat related issue. I've realized that there's lots of usage of TRAP_INTERNAL_ASSERT in the translation from wasm to CLIF, even in "full opts" mode. If any of those are hit that's an instant process abort via a signal handler, and promoting this to a full trap would require side tables for trap code payloads.

Not entirely sure where this leaves us, but that's at least some more information.

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2026 at 20:47):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 12 2026 at 23:20):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 22:33):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 19 2026 at 17:39):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 19 2026 at 17:40):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2026 at 14:49):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2026 at 22:29):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 18:50):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 19:36):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 19:37):

fitzgen commented on issue #13216:

Okay I just put up https://github.com/bytecodealliance/wasmtime/pull/13439 to switch the default collector to the copying collector. My plan is to let that ride a release, and then in the next release, assuming we don't run into any new issues, enable Wasm GC by default / tier 1 as well.

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 19:40):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 20:29):

alexcrichton edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 22 2026 at 17:38):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 22 2026 at 17:58):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 22 2026 at 20:04):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 23 2026 at 23:07):

alexcrichton commented on issue #13216:

@fitzgen going through the tagged gc issues wanted to confirm a few things and ask your thoughts too:

view this post on Zulip Wasmtime GitHub notifications bot (May 26 2026 at 17:48):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 26 2026 at 23:15):

fitzgen commented on issue #13216:

Rewrite the table_ops fuzzer to hammer on all GC/reference types things #10327 - you're confident that the current fuzzer covers "basically enough"?

Yeah, I don't think we need to wait for that to finish completely. We have wasm-smith generating GC instructions and the new GC access fuzzer; I think those should provide enough assurances for us here.

Avoid locks for subtyping checks in Wasm GC #9352 - what's your read on this? From a security issue perspective, this to me feels like "can slow things down but not in a CVE-ish way" in the sense that we still want to do it but I think it'd be reasonable to not block on. Wanted to double-check though.

Correct. Can slow module registration/unregistration down (and vice versa) but wouldn't be a CVE.

List of future optimizations for Wasm GC performance #9351 - I think this can be closed given that everything's a sub-issue at this point, right? There's no glaring holes we're aware of?

Done.

Implement the WebAssembly GC Proposal #5032 - this can probably be closed b/c everything's been implemented for some time now, right?

Was going to do this after we enable Wasm GC by default.

view this post on Zulip Wasmtime GitHub notifications bot (May 26 2026 at 23:15):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 27 2026 at 13:42):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 27 2026 at 18:55):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 27 2026 at 20:37):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

view this post on Zulip Wasmtime GitHub notifications bot (May 27 2026 at 21:15):

fitzgen edited issue #13216:

Blockers for enabling Wasm GC by default:

Last updated: Jun 01 2026 at 09:49 UTC