A few weeks ago, we discussed what to do with SyzyASan. It's not clear if we're going to prioritize it, but on the engineering side there was agreement what to do if we were to do anything, so let's write this down.

SyzyASan is several things:
1. Using the syzygy framework to instrument chrome.dll in a post-build step
2. An alternate asan runtime that works better than the llvm asan runtime when running in the wild (crashkey integration, faster, filters out crashes due to bad injected third-party code, etc)


General consensus is that we should use clang to write the right binary for 1 (this would mean we'd also end up with an instrumented chrome_child.dll, not just chrome.dll, which we'd then have to disable at runtime somehow, for perf reasons, and because chrome_child.dll crashes are redundant with crashes we get from clusterfuzz. rnk had ideas on how to do this.)

General consensus for 2, including from llvm asan runtime folks (kcc) is that we should try and use the SyzyASan runtime with clang-compiler-instrumented code. Concretely, that'd mean extracting it from the syzygy repo, moving it into src.git, porting it over to chrome's base/ (it's currently written on top of an old clone of base), and then shipping.

Hooking up clang instrumentation to the SyzyASan runtime is already done and passes "hello world".

Intercepting calls to malloc etc could use help of the linker (llvm asan uses hotpatching which isn't very reliable); possibly with explicit support via lld-link, but maybe regular linker flags are enough.


Seb also wrote an (internal-only) doc on this at https://docs.google.com/document/d/18qYwiaHzzzYy9e3w-qcaNNmjfkenJu9G2rACg6fjR40/edit?usp=gmail . Internal thread "Steps to shipping SyzyASan with Clang" on the internal syzygy list also has a bunch of information.


If we do tackle this, we should make sure it's not Windows-specific but could be used on e.g. Android as well.