[RFC] Future of Evocatio

[SonicStark]

There are several aspects which have hindered the pace of futher development and application:

1. CapSan is Actually Puppet of Sanitizers
   Current implementation of CapSan lies in both target binary and afl-fuzz. And the former part, which is based on some call-back tricks from sanitizer runtime, obtain capability details and save as-is or as-hashed. This makes CapSan become a puppet of sanitizers, although they may be decoupled from the perspective of source code structure.
   Imagine that there may be sanitizers like XSan, YSan, ZSan, or even XYZSan, each of them also have multiple versions. This should be a headache matter to support all of them, with speed, pre-compiling, linking and compatibility problems settled.
   What's more, recent features such as UBSan support even depend on un-public interfaces of LLVM compiler-rt. This can make CapSan more unstable and fragile.

2. Capability Details May be Unnecessary
   As a fuzzing suite, Evocatio reflects data flow related stuffs through capability, infers $D_{byte}$ by watching changes of capability. This means that users don't need to care about the detail of capability most time. Only hash is enough. Capability of a seed may come from ABCXYZSan, from hardware, from sun, air or water, but as long as the hash is available, Evocatio should work well.
   What's more, only severity assessment or other post-analysis steps depend on capability details, since they need concrete data.

3. Internal Working Mechanism is Not Clear Enough
   It should upgrade to the latest stable version of AFL++. And all modifications based on AFL++ should be marked out so that Evocatio can be friendly to more people in community.

So it has been planned that the whole Evocatio would be refactored. There are two steps in total:

• Step 1: Upgrade to latest stable version of AFL++ with slight changes. bug-severity-AFLplusplus will be renamed to CapFuzz.
• Step 2: Make CapSan and current post-analysis steps of bug-severity standalone. Finally Evocatio = CapSan + CapFuzz + BugSeverity.

[tiedaoxiaotubie]

For the 2 point, I would say capability details is unnecessary for CapFuzz, but it is still useful for Evocatio. Our project provided users with capability scanning scripts, which can summarize bug capabilities into a capability report, the report is designed for human, it must be readable. Human expert can read the report to assess the severity of the bug directly according to their application scenario. Because of the page limitation, I didn't talk about the bug report much in our CCS paper, but user should understand why the original version of Evocatio use two kind of Capsan (one provides details, the other provides hash only). Since @SonicStark is trying to refactor the code, I suggest we make the function clear: that is, we allow user to "extract" the "readable" bug capability by providing a specific version of CapSan, but this specific CapSan is only for extracting readable bug information, not for CapFuzz.

[SonicStark]

Can't agree more!:grinning:

[tiedaoxiaotubie]

BTW, I agree with your plan, pls go ahead. I think the UBSan support has been there in a recent PR, merge it before refactor would be better IMO.