logoChat01.ai

综合两篇文章，总结 waltzz 这篇工作的不足，分析后续有什么可以改进的创新点

Erstellt am: 24. März 2026

Beantwortet mit GPT-5.4 Thinking von Chat01

Frage

3372297.3417260.pdf
Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf

综合两篇文章，总结 waltzz 这篇工作的不足，分析后续有什么可以改进的创新点

Gedanke

Further refining WALTZZ shortcomings analysis

WALTZZ has limited scope, only covering the Wasm core spec and lacking support for ongoing proposals like garbage collection or threads. It also heavily depends on seed inputs and a generator for rare constructs, which may limit systematic exploration compared to Squirrel's more diverse structure and dynamic dependency modeling. There's no learning-based or coverage-directed generation in WALTZZ, which might be why it doesn't show advantages in some evaluations.

Improving WALTZZ's capabilities

WALTZZ shows limitations with unsupported instructions, which cause problems on certain runtimes, and lacks a way to handle infinite loops effectively, although timeout is acceptable. To improve, a coverage-guided generator targeting under-covered types and an adaptive grammar could be helpful. Also, a lightweight cost model could solve diversity issues. While no bugs were found in JS engines or Rust, this highlights the thorough testing rather than a flaw. Comparing with Squirrel’s separation of structure and data highlights another area for improvement.

Thought for 2m 27s

Antwort

我这里把“两篇文章”理解为你上传的 WALTZZ 和 Sqirrel。先说结论：** WALTZZ 很强，但它的“有效性保证”主要还停留在 Wasm 的栈类型/局部上下文层；和 Sqirrel 相比，它还没有把更高层的“语义依赖”和“执行环境依赖”系统化建模出来。** 这恰好也是后续最值得做创新的地方。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

一、WALTZZ 的主要不足

  1. 对“语义”的建模还不够深，更多是在保 stack-valid，而不是保更完整的 module/environment semantics。
    WALTZZ 的核心抽象是 stack-invariant transformation：只要两段代码对栈的输入输出类型兼容，就可以替换；遇到 memory/table/local 这类上下文需求时，再做 on-demand 的 context repair。这个设计很高效，也让它在实验里做到 100% valid input。可问题是，这种“有效性”主要是 类型层和局部上下文层 的。相比之下，Sqirrel 不只是保语法正确，还显式区分 define/use、scope、isA/isAnElement，并构建 dependency graph 做实例化，本质上是在做更高层语义约束求解。从这个对比看，WALTZZ 对 Wasm 中更复杂的全局依赖——比如 memory/table/global/import/export、跨函数关系、host API 交互协议——还没有形成类似 Sqirrel 的统一语义图模型。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf) (3372297.3417260.pdf)

  2. 对“执行环境空间”的探索不足。
    WALTZZ 主要在输入模块空间里做得很好，但作者自己在讨论部分已经承认：很多 SpiderMonkey 的历史 bug 依赖于 不同 build/run command、ARM 架构、特定 JIT tier、命令行选项；另外，大约 40% 的 bug 涉及进行中的 Wasm proposals，50% 的 bug 会和 JS context 交互。这说明真正影响 bug 暴露的，不只是模块本身是否合法，还包括架构、编译层级、flag、宿主上下文。而 WALTZZ 当前评测基本还是默认配置 + 固定 harness，这使它对工业级 JS engine 的深层 bug 还不够“环境敏感”。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  3. 对新标准/新 proposal 的覆盖还不够。
    WALTZZ 在实现上明确说自己目前主要支持 Wasm core specification，而 Wasm 还在持续演进，像 GC、threads 等 proposals 正在标准化。作者也指出，新的 bug 往往更可能出现在这些较新的 proposal 实现里。这意味着 WALTZZ 当前更像是“core-spec oriented fuzzer”，而不是一个真正面向 Wasm 演进生态的 fuzzing 平台。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  4. 仍然有明显的 seed / runtime-support 依赖。
    WALTZZ 从官方 Wasm tests 中抽取 seed，并且只对 valid seed 做定制化变异；在 wasm-micro-runtime 和 wasm3 上，它的优势不明显，作者给出的原因之一就是这些 target 本身较轻、seed 已经提供了不错覆盖，另外某些 runtime 对 proposal 支持不完整，WALTZZ 还会生成这些 runtime 不认识的指令，反而影响效果。这说明它虽然比传统 mutation 强很多，但还没有彻底摆脱seed 分布和runtime 能力不匹配的问题。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  5. 生成器仍偏“随机骨架 + 类型约束”，缺少更强的目标导向。
    WALTZZ 的 skeleton-based generator 把 control skeleton 和 data generation 分开，这很巧妙；但它本质上还是随机选择 block/loop/if 等结构，再递归填充类型匹配的指令。和 Sqirrel 相比，WALTZZ 没有把“什么样的组合更可能触发深层状态/新优化路径/稀有 verifier 行为”显式建模出来。换句话说，它解决了“能不能生成合法输入”，但还没有充分解决“怎样更有针对性地生成高价值输入”。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

  6. oracle 仍然偏传统崩溃导向。
    WALTZZ 主要还是靠崩溃、ASAN、覆盖率来衡量成效。这个方向当然有效，但对 Wasm/JS engine 这类系统，很多更现实的问题未必直接表现为 crash，还可能是 错误验证、错误编译、spec violation、cross-runtime inconsistency、sandbox policy 绕过。这一点在它对 JS engines 零新 bug 的结果上也能侧面看出来：不是没问题，而是当前 oracle 对这类问题不够敏感。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

二、后续最值得做的创新点

  1. 把 Sqirrel 的“语义依赖图”思想迁移到 Wasm，做 stack + context + state 的统一建模。
    这是我认为最有研究价值的一条。Sqirrel 的强点在于：它不只保结构，还把依赖关系显式图化。对应到 Wasm，可以把 stack type、memory/table/global、element/data segment、call_indirect 的 table 约束、import/export、host object 生命周期、跨函数 def-use 统一进一个 module-level semantic dependency graph。这样一来，WALTZZ 就能从“局部类型不坏”升级到“全局语义尽量自洽”。这会比现在的 on-demand context repair 更系统，也更可能触发验证器之后、编译器之内的深层逻辑。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf) (3372297.3417260.pdf)

  2. 做 configuration-aware / environment-aware fuzzing。
    不要只 fuzz 模块，也要 fuzz 运行配置。可以把架构（x86/ARM）、JIT tier、编译选项、命令行 flags、feature toggles、JS/WASI host state 一起纳入搜索空间，形成“模块 + 配置 + 宿主交互”的联合变异。作者在讨论里已经给了很强的证据：很多历史 bug 就依赖这些维度。谁把这部分做成系统，谁就更可能在大厂 JS 引擎里打出成果。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  3. 做 proposal-aware fuzzing，按 runtime 能力自适应。
    WALTZZ 现在的问题之一是会在某些 runtime 上生成不被支持的 proposal 指令。下一步可以先做 capability inference：自动探测某个 runtime 支持哪些 Wasm proposals、哪些 host APIs、哪些 flags；然后针对能力图动态切换 grammar、mutator 和 generator。再进一步，可以做 differential fuzzing：同一模块在多个 runtime / 多个 proposal 组合下交叉比对，找验证、编译、执行结果不一致。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  4. 把生成器从“随机合法”升级成“覆盖/新颖度驱动生成”。
    现在 skeleton generator 更多是随机骨架展开。可以继续往前走两步：
    一是用 coverage deficit 来反推该生成哪类 stack signature、哪类 CFG 形态、哪类稀有 instruction combo；
    二是把“新颖度”定义得更语义化，比如新 verifier state、新 optimization phase、新 tier transition、新 resource-state。
    这样生成器不只是补 rare construct，而是主动攻击“还没被充分探索的语义区域”。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  5. 把 harness 本身也纳入变异，做 host-interaction fuzzing。
    WALTZZ 目前对 JS engine 主要靠固定的 Wasm-JS API harness；但作者又说 50% 的历史 bug 和 JS context 交互有关。这说明真正高价值的下一步，不是单纯让模块更复杂，而是让 模块与宿主的交互序列 更复杂：
    先 validate/compile/instantiate 再重复导出调用、混入 JS 对象/typed array、切换 tracelogger、WASI 文件/网络/权限状态等。
    换句话说，要 fuzz 的不只是 Wasm module，而是 module + host protocol。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

  6. 引入更强的 oracle：从 crash-oriented 扩展到 spec / compiler / sandbox-oriented。
    一个成熟方向是同时做三类检查：

  • differential oracle：不同 runtime、不同 tier、不同 optimization level 输出是否一致；
  • spec oracle：验证器/解释器/编译器对同一模块的接受与结果是否一致；
  • security oracle：越界、类型混淆、宿主引用泄露、权限边界穿透。
    这会让 WALTZZ 从“找内存 bug 的 fuzzer”升级为“找 Wasm runtime correctness + security bug 的平台”。这一点其实也是从 Sqirrel 能同时兼顾语言正确性与覆盖反馈得到的启发。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

三、如果让我概括成一句话

WALTZZ 的核心贡献是把 Wasm fuzzing 从“字节级盲变异”推进到了“栈类型不变的结构化变异”；但它下一阶段真正该做的，是像 Sqirrel 那样，把“合法性”从局部类型层提升到全局语义层，再把 fuzzing 从输入空间扩展到配置空间和宿主交互空间。
前者解决“模块内部怎么更聪明”，后者解决“环境外部怎么更真实”。这两个方向合起来，才是下一代 Wasm runtime fuzzing 最可能出的创新点。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

要是你愿意，我可以继续把上面这段整理成论文写作风格的“相关工作 + 局限性 + future work”三段式表述。

Frage

以往有什么 verifier state 引导的模糊测试吗，帮我搜寻相关的工作

Gedanke

Finalizing references and venue details

I’ll mention the venues accurately for SEV (OSDI 2024), BpfChecker (CCS 2024), and BRF (FSE 2024). For Veritas/SpecCheck, I’ll say “2025 paper,” as I didn’t fully verify the venue. I’ll avoid mentioning venues for AFLNet unless further verification is possible and focus on the year instead.

Thought for 5m 13s

Antwort

我搜了一圈，结论比较明确：严格意义上“把 verifier 的内部抽象状态直接当成 greybox feedback 来驱动变异/调度”的论文非常少。现有最接近的工作主要集中在 eBPF verifier；更多论文其实是三类：一类把 verifier state 用作正确性 oracle，一类把 verifier 约束用作输入生成规则，还有一类把“状态”用于差分/状态覆盖，但状态未必是 verifier 自己的内部抽象状态。Linux 内核文档也能看出来，eBPF verifier 本身确实维护了很丰富的内部状态：它会沿路径模拟执行，跟踪寄存器和栈槽的状态、范围和指针类型，这些都体现在 bpf_reg_state 一类结构里。(Kernel.org)

最接近你说法的工作是 SEV / “Validating the eBPF Verifier via State Embedding” (OSDI 2024)。 这篇工作的核心不是普通 coverage-guided fuzzing，而是抓住了 verifier 的本质：它会维护“对程序状态的过近似”。SEV 的做法是把具体状态嵌进 eBPF 程序里，构造成 verifier 本应拒绝/接受的检查点；一旦 verifier 的判定和这些嵌入状态不一致，就说明它的抽象状态没有正确覆盖 concrete state，从而暴露 logic bug。作者一个月里找到了 15 个未知 bug，其中 10 个已修复，且有 2 个能导致本地提权。所以它非常像“verifier-state-aware testing”，但更准确地说是“state-informed validation/oracle”，还不是 AFL 风格把 state 当 fitness 的灰盒调度。 (USENIX)

第二条很关键的是 Veritas / SpecCheck（2025）。 这篇工作明确批评了此前 eBPF verifier fuzzing 的 oracle 太间接，很多时候只能靠下游执行时的内存错误或 runtime pattern 去“侧面证明” verifier 出错；它转而用一个规格化 oracle 去判断某个具体 eBPF 程序按语义和安全约束到底应不应该被接受，然后把这个结果与 verifier 的决定做交叉比对。它报告找到了 13 个 verifier bug，还能覆盖安全问题和可用性问题。它依然不是“用 verifier 内部状态做反馈”，但已经从“状态启发”走到了“状态/语义正确性 oracle”。 (Cheriton School of CS)

如果往“constraint-guided”方向看，BRF 是一篇必须提的相关工作。 BRF 不是 fuzz verifier 本身，而是 fuzz 被 verifier 挡在后面的 eBPF runtime。它的关键观察是：大量输入根本过不了 verifier，于是它去研究 verifier 和 eBPF 子系统的语义约束、依赖关系，再把这些规则融到输入生成里。结果是它生成的程序里约 98% 能通过 verifier，48 小时内成功执行的 eBPF 程序数量约为 Syzkaller 的 8 倍，覆盖率高 101%。这条线很像“verifier-constraint-guided fuzzing”，但仍然不是直接把 verifier 的 abstract state 暴露成 feedback。 (arXiv)

再往“state 作为差分/反馈指标”看，BpfChecker 很值得看。 它不是盯着单个 verifier 的内部状态，而是把不同 eBPF runtime 的中间状态 / post-state建模出来，做差分测试；同时它还用错误信息去约束变异，让生成的 eBPF 程序语义更强。论文里甚至把“需要新的 runtime-state 指标，而不是只看 code coverage”当成一个明确挑战提出来。这篇和你的想法最像的地方在于：它已经承认‘状态’应该成为主反馈对象，只是它对齐的是跨 runtime 的执行状态，不是单个 verifier 的抽象解释状态。 (yajin.org)

在 Wasm 这条线上，也有一串“非常接近，但还没到 verifier-state-guided”的工作。 ESFuzzer 用 equivalent statements 和 stack repair 来确保生成样本通过 Wasm validation；WALTZZ 则把重点放在 stack-invariant transformation，上来就把“runtime 会验证 stack semantics、只有 valid module 才能深入执行”当成核心挑战；RGFuzz 更进一步，从 Wasm runtime 里抽取 compiler rules 来指导生成。它们都在做一件事：** 用 validator/verifier 的约束，去生成更能通过验证、从而更能到达深层逻辑的输入**。但严格说，它们主要利用的是规则/栈语义/验证约束，不是把 validator 的内部状态当成显式反馈。(MDPI)

如果你想找“方法学上的祖先”，那就要看通用 state-aware fuzzing。 AFLNet 把协议响应码当 state-feedback；StateAFL 从长生命周期内存里自动推断协议状态机；SGFuzz 显式维护 state transition tree，并用新状态节点和稀有状态去分配能量；StateFuzz 直接把 state-variable 的值和状态转移作为反馈，报告比 Syzkaller 更高的 state coverage 和 bug finding。这些工作不是 verifier 论文，但它们给了一个很清楚的模板：state 可以不是 oracle，而可以成为 seed selection、energy schedule、mutation focus 的一等公民。 这正是 verifier-state-guided fuzzing 还没有被系统做透的地方。(mboehme.github.io)

所以，如果你要在 related work 里下判断，可以这样写：现有最接近的工作主要有三支——state embedding / spec oracle（SEV、Veritas）、verifier-constraint-guided generation（BRF，Wasm 上的 ESFuzzer/WALTZZ/RGFuzz）、以及state-aware fuzzing 框架（AFLNet/StateAFL/SGFuzz/StateFuzz）。但据我这轮检索，我没有看到一篇已经成熟发表、且被广泛认作“直接把 verifier 的内部 abstract state（例如 eBPF 的 register/stack abstract state，或 Wasm validator 的 type/stack context）暴露成 greybox fitness 来驱动 seed scheduling 和 mutation”的代表作；这反而说明这条线还有明显空位。这个判断是我基于上面这些文献做的综合归纳。(Kernel.org)

如果你愿意，我下一步可以直接帮你把这些工作整理成一段论文 related work 小节，或者进一步提炼成你这个方向的novelty statement。

Frage

帮我分析两篇文章中，waltzz 可以引入什么机制，改进灰盒模糊测试中的生成

Gedanke

{"pointers":["5:0","5:6","5:11","5:12","5:13","5:15","5:16"]}

Thought for 2m 7s

Gedanke

Considering citation and clarity

We’ve got enough info for a reference, but without line markers, it’s tricky. The issue is that line ranges should be there, but I can’t access them. Citations might still be acceptable without them — I'll proceed with the filecite approach. I’ll assume the articles in question are WALTZZ and Sqirrel. Let's dive into the mechanisms WALTZZ could bring to greybox fuzzing.

Clarifying WALTZZ and Sqirrel mechanisms and suggestions

When contrasting WALTZZ and Sqirrel, it’s clear that WALTZZ solves "stack-type validity," focusing on stack types and local context. However, Sqirrel builds upon this by adding semantic dependency analysis and delayed instantiation. To improve WALTZZ, it could evolve to include semantic-context-consistent generation. I’ll propose mechanisms sourced from both papers and my synthesis, keeping citations handy for validation.

Thought for 3m 13s

Antwort

如果你说的“两篇”是 WALTZZ 和 Sqirrel，那我觉得最核心的结论是：

WALTZZ 现在已经很强地解决了“生成后能过 Wasm verifier/validator”这个问题，但它的生成器主要还是围绕 stack type 和局部 context 在工作；Sqirrel 多出来的关键一层，是“先生成结构，再用依赖关系把语义补全”。
所以，WALTZZ 最值得引入的，不是再多几个 mutator，而是把生成流程从 stack-correct generation 升级成 stack-correct + semantic-context-consistent generation。WALTZZ 本身依赖 stack-invariant transformation、typed IR、context repair 和 skeleton-based generation，目标是保持栈语义有效并生成稀有代码结构；Sqirrel 则把“结构生成”和“语义实例化”拆开，用依赖图去补全操作数关系。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

我会优先建议 WALTZZ 引入下面几类机制。

  • 把“on-demand context repair”提升成“全局依赖图实例化”。
    现在 WALTZZ 在 splicing 或生成时，主要是在发现缺内存、表、局部变量等上下文时做按需修补；这很实用，但本质上还是局部修补。Sqirrel 的做法更系统：它先给数据打上更细的类型标签，再定义关系规则，然后构建 dependency graph，最后按依赖顺序实例化。迁到 Wasm 上，可以把 function / table / memory / global / local / label / element segment / data segment / type signature 都当成“语义对象”，建立类似 DefFunc(sig)、UseFunc(sig)、UseTableForCallIndirect(sig)、UseMemoryForLoad(width)、UseLabel(stacktype) 这样的关系图。这样生成器不再是“遇缺补缺”，而是“先规划关系，再一次性补全”，会更适合生成跨组件耦合更强的模块，比如 call_indirect + table.set + ref.func + element segment 这类组合。这个建议是基于 WALTZZ 的 context repair 和 Sqirrel 的 dependency-graph/instantiation 机制做的综合推断。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf) (3372297.3417260.pdf)

  • 引入“占位符骨架 + 延迟实例化”的两阶段生成。
    WALTZZ 的 skeleton-based generator 已经把“控制流骨架生成”和“具体值生成”分开了，这是它很强的地方；但它填充的仍主要是能满足 result type 的 instruction/value。Sqirrel 更进一步：先把结构骨架造出来，再把具体标识符和操作数留成占位符，最后根据依赖图统一实例化。对 Wasm 来说，可以先生成抽象骨架，例如“这里需要一个 call_indirect，这里需要一个可跳转到的 label，这里需要一个可 load 的 memory，这里需要一个满足签名的 callee”，把具体 table index、function ref、memory index、global/local 索引先延后。这样一来，WALTZZ 更容易生成结构很复杂但当前上下文尚不完备的模块，而不是在生成过程中被局部约束卡住。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

  • 把 WALTZZ 的“类型”从 stack type 扩展成“语义角色类型”。
    WALTZZ 当前最核心的标签是代码段的 stack type，这保证了 verifier 视角下的类型正确；Sqirrel 的启发在于，它把“同样是表/列”继续细分成“定义还是使用”“在什么作用域使用”“可引用谁”。Wasm 里也很需要这种 refinement。比如现在两个片段都可能是 [ ] -> [i32]，但一个 i32 是“可当 br depth 的条件值”，另一个 i32 是“可当 memory offset/index 的地址值”，还有一个可能是“可当 call_indirect 的 table index”。如果只按 stack type 分组，它们都兼容；但从语义上看，后续可接的结构完全不同。把类型细分成“role-aware type”后，生成器检索片段、拼接片段、实例化占位符时都会更准，能减少“虽然可验证，但执行层面很浅”的样本。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

  • 把 Sqirrel 的 relation rules 映射成 Wasm 语义规则库。
    Sqirrel 明确依赖一组 relation rules 来约束实例化，比如谁必须引用谁、谁必须在作用域内、谁必须先定义后使用。WALTZZ 也有类似知识，但现在更多散在不同 mutator 和 repair 逻辑里。把它们抽成统一规则库，会明显改进生成。Wasm 里最有价值的规则包括：
    call 的目标函数签名匹配；call_indirect 的 table entry 与预期 type 匹配；br/br_if/br_table 的目标 label stack type 匹配；load/store 必须有相应 memory；global/local get/set 要与定义类型一致；element/data segment 要与 table/memory 存在性和元素类型一致；导入项与使用点要对应。
    这一步的价值不只是“多过验证”，而是能系统性地产生深层运行态依赖，让样本更可能进入编译、优化、实例化、执行中的复杂逻辑。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

  • 把 fragment library 从“按 stack type 索引”升级成“按语义模式索引”。
    WALTZZ 的 splicing 很强，但它现在的匹配核心仍然是 stack type；Sqirrel 的 IR library 则不只是存结构，还会按类型和结构去去重、复用。WALTZZ 可以把片段库再分层，比如除了 [tin]->[tout] 之外，再记录“需要 memory / 需要 table / 定义 label / 消耗 ref / 产生可复用 callee / 引入 indirect call / 引入 segment side effect”这些语义标签。这样生成器在想要“补一个 rare construct”时，不必随机碰运气，而能有目标地取出“兼容且语义上互补”的片段。对灰盒来说，这会直接提高生成阶段的命中率。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)

  • 把反馈从“单一 coverage”改成“分阶段有效性反馈”。
    Sqirrel 有个很重要的经验：coverage 很重要，但错误路径上的 coverage 可能有害，因为它会把 fuzzer 吸到 parser/validator 的浅层报错逻辑里；作者甚至明确提到要抑制只命中短错误路径的输入。WALTZZ 虽然已经能稳定生成有效输入，但一旦你把生成器做得更激进，还是会遇到同样问题。所以我建议它在生成阶段引入多级反馈，例如：
    validator pass、instantiate pass、compile deeper、execute deeper、new runtime coverage 分开打分；只在后几级给予高奖励，降低“只是合法但只走初始化/报错路径”的样本权重。
    这其实是把 Sqirrel 的“alternative feedback”经验，嫁接到 WALTZZ 的生成调度上。(3372297.3417260.pdf) (3372297.3417260.pdf)

  • 自动学习 relation rules，而不是全手写。
    Sqirrel 自己也承认 relation-rule construction 现在主要靠人工规则，并计划用 data-flow analysis 或机器学习从正常执行里自动抽。这个点对 WALTZZ 更重要，因为 Wasm 提案在持续演进，单靠手写规则很难长期跟上。比较现实的做法是：从官方 spec tests、已知有效模块、以及运行时接受的样本里，抽取“对象共现 + 依赖顺序 + 使用位置”模式，自动学出高频约束，再把它们喂给生成器做先验。这样生成器对新 proposal（GC、threads、JS context 交互）会更容易扩展。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)

如果把这些合起来，我会把升级后的 WALTZZ 生成器概括成一句话：

现在的 WALTZZ 是“栈不变 + 骨架生成”；下一步最有潜力的是变成“栈不变 + 依赖图驱动的语义实例化 + 分阶段反馈”。

这样做的直接收益有三个：

  1. 生成出的模块不只是 valid，而是更可能 deeply exercisable。因为它们的 call/table/memory/segment/label 关系被系统补全了。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf) (3372297.3417260.pdf)
  2. 更容易稳定地产生 rare but meaningful constructs，而不是只靠随机骨架碰出来。WALTZZ 论文里展示的稀有触发样本已经说明生成器有价值；引入 Sqirrel 的实例化层后，这个价值会更强。(Zhang 等 - WALTZZ WebAssembly Runtime Fuzzing with Stack-Invariant Transformation.pdf)
  3. 反馈会更少被 verifier/validator 浅层路径绑架，生成预算能更多花在真正深入 runtime 的样本上。(3372297.3417260.pdf)

如果你要写成论文里的一个“方法设计段”，我觉得可以直接起个名字，例如：
Semantic-Instantiation over Stack-Invariant Skeletons
或者
Dependency-Guided Wasm Generation。

我也可以下一步直接帮你把这个整理成一段论文风格的“设计动机 + 机制 + 预期收益”。

Diesen Q&A teilen