You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6d8072c
Browse filesBrowse the repository at this point in the historyBrowse files
Related to #66. TinyWasm's default validator limits are deliberately
broad for general WASM. For host that loads untrusted guest programs, a
small binary can still encode disproportionate parse work (like a large
local declaration or `array.new_fixed` count).
This adds opt-in `ParseLimits` to `ParserOptions` for encoded module
bytes, entries per section, parameters plus locals per function,
`br_table` targets, and `array.new_fixed` elements. Byte, file, and
stream entrypoints share the input limit; streaming counts total bytes
read even when its buffer slides. The two operator fanouts are checked
before wasmparser validation and lowering. Compact-import expansion is
counted before validation when the section limit is set.
All limits default to unlimited. The ordinary parser path and
interpreter dispatch are unchanged; hosts that enable operator fanout
limits take a guarded parser-only decode path. Validation should remain
enabled for untrusted modules. These are input and known-amplification
limits, **not** a hard peak-memory or elapsed-time guarantee: wasmparser
can allocate while decoding a recursive type group before TinyWasm
checks its expanded size.
With limits in place, some pathological .wasm files now get properly
rejected on my Apple Watch test app, instead of the app crashing.
Local Mac validation: 50,000 deterministic fuzz mutations of adversarial
parser fixtures. I also looked at guard techniques from other WASM
parsers/runtimes test suites and rolled some of those tests in.
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,7 +75,7 @@ Applications that only load `.twasm` can remove the parser and validator from th
75
75
76
76
WebAssembly [validation](https://webassembly.github.io/spec/core/valid/index.html) is enabled by default through the `validate` feature. Keep this feature enabled and leave `ParserOptions::validation` enabled for modules from untrusted sources. Without validation, parsing can produce modules that violate runtime assumptions and may panic during instantiation or execution.
77
77
78
-
Validation does not limit parsing or execution resources. Hosts that run untrusted code should also set input limits, configure stack and `ResourceLimiter` limits, and use fuel- or time-budgeted execution as needed.
78
+
Validation does not limit parsing or execution resources. Hosts that run untrusted code should also set opt-in `parser::ParseLimits` for input and known parse-time amplification points, configure stack and `ResourceLimiter` limits, and use fuel- or time-budgeted execution as needed.
79
79
80
80
Loading `.twasm` checks the archive header and encoding but does not run WebAssembly validation or verify TinyWasm's runtime invariants. Load archives only from trusted sources. For untrusted input, parse a WebAssembly binary with validation enabled.
@@ -28,3 +38,7 @@ let module = parser.parse_module_stream(&mut stream)?;
28
38
```
29
39
30
40
If you just want the default configuration, the top-level `parse_bytes`, `parse_file`, and `parse_stream` helpers are thin wrappers around `Parser::default()`.
41
+
42
+
The limits are opt-in and disabled by default. They bound encoded input and
43
+
known parse-time amplification points; they are not a hard cap on peak memory
44
+
or elapsed time. A host should also bound guest runtime resources after parsing.
0 commit comments