petermcneeley@
Apr 15, 2026
There has been an influx of security bugs for Dawn due to a capability phase shift in AI assisted vulnerability discovery.
In Dawn often these are triggered by going outside known assumptions or they become real security issues when further assumptions are invalidated.
DAWN_UNREACHABLEA good example of this is the assumption that all switches on enums are valid enums. Some minor vulnerability can lead to full execution control via the undefined behavior of a switch table that jumps to an invalid enum. Example https://crbug.com/499159695
To resolve this, all DAWN_UNREACHABLEs now check at runtime that unexpected fallthroughs (switch and function) will do a full CHECK (as in immediately crash/ICE in release).
This induces ~ 2 instructions per switch and is deemed to be acceptable.
See CL: https://dawn-review.git.corp.google.com/c/dawn/+/301675
DAWN_ASSERT to DAWN_CHECKThere are other cases where an assumption would have caught a security issue but does not because the assumption in code is DAWN_ASSERT, not a check.
Example https://crbug.com/500609033
The conclusion is certain DAWN_ASSERTs will be promoted to release DAWN_CHECKs.
This is more controversial than the unreachable case as some of these checks can be expensive and some can be in hot code paths (paths that are called many times per frame/submit).
For the initial phase, DAWN_ASSERTs that will be promoted are:
CL: https://dawn-review.git.corp.google.com/c/dawn/+/302235
The main drawback here is when do we get to remove these checks? The answer is likely never!
However, it is likely that within the next year we will be able to ask advanced AI security models what would be the impact of removing specific checks. It might even be that every future change in Dawn will get evaluated for security by an AI model.