docs/dawn/asserts-vs-check.md - dawn.git - Git at Google

 # Dawn: Checking asserts [Bug 442860471](https://crbug.com/442860471)

 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**.

 ## Fix: `DAWN_UNREACHABLE`

 A 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_UNREACHABLE`s 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>

 ## Fix: `DAWN_ASSERT` to `DAWN_CHECK`

 There 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_ASSERT`s will be promoted to release `DAWN_CHECK`s.

 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_ASSERT`s that will be promoted are:

 * Cheap 1-2 instruction checks (null/bounds/error)
 * Avoid checks that would be found via null page
     * There is no point in checking a null pointer if the very next line it will trigger a null page segfault (which is not considered a Chrome vulnerability)
 * Hot code paths are allowed for checking memory bounds

 CL: <https://dawn-review.git.corp.google.com/c/dawn/+/302235>

 ## Drawback(s)

 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.
	# Dawn: Checking asserts [Bug 442860471](https://crbug.com/442860471)

	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.

	## Fix: `DAWN_UNREACHABLE`

	A 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_UNREACHABLE`s 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>

	## Fix: `DAWN_ASSERT` to `DAWN_CHECK`

	There 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_ASSERT`s will be promoted to release `DAWN_CHECK`s.

	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_ASSERT`s that will be promoted are:

	* Cheap 1-2 instruction checks (null/bounds/error)
	* Avoid checks that would be found via null page
	* There is no point in checking a null pointer if the very next line it will trigger a null page segfault (which is not considered a Chrome vulnerability)
	* Hot code paths are allowed for checking memory bounds

	CL: <https://dawn-review.git.corp.google.com/c/dawn/+/302235>

	## Drawback(s)

	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.