Conversation

hanno

@hanno

Apr 24, 2020

For a simple piece of C code I wanted to setup

@travisci

to run a simple test with all the fancy sanitizing and bug finding tools gcc/clang provide. This seems like exactly the thing you want to do with a CI, yet it was surprisingly challenging. Thread.

hanno

@hanno

Apr 24, 2020

Issue 1: Code uses getrandom(), which is reasonably new. The travis environment is not very up-to-date. Default is Ubuntu 16. No getrandom. Latest available is Ubuntu 18.

hanno

@hanno

Apr 24, 2020

Issue 2: MSAN. Again the environment is old. MSAN has a issue with getrandom before version 10, no current clang easily available on travis.

hanno

@hanno

Apr 24, 2020

Issue 3: CFI. CFI uses the gold linker, which is not installed in the clang image. Okay, no problem, we can install it, right? well. travis uses its own version of clang, not the one from ubuntu, for whatever reasons. and no gold, thus no CFI.

Replying to

Are you using CFI for bug hunting?

Replying to

yes. it can find things like function declarations that aren't quite right, see blog.fuzzing-project.org/57-Diving-into also pretty much every chrome security advisory says they found issues with cfi, I believe it's often type confusion stuff.

Replying to

Interesting! I was thinking about runtime checks / sanitizing. Sounds like CFI ramps up compiler and linker warnings or introduces additional checks? Did you try if -Wextra, -Wall, -Wpedantic combined with Werror find these bugs as well?

Replying to

and

Clang CFI provides runtime checks for indirect calls via function pointers, C++ method pointers or C++ virtual methods. It verifies that the type used by the caller matches the callee. Only functions identified as potentially called indirectly are allowed to be called indirectly.

Replying to

and

It also expands the runtime cast checks for C++. It uses link-time analysis, which is essentially whole program analysis but per executable / shared object. Cross-DSO CFI is supported but compiling as a single executable provides more precision and avoids the cross-DSO slow path.

Replying to

and

Here's a nice example where function addresses are taken in assembly so the compiler doesn't see them and prevents indirect calls to these functions when it can perform whole program analysis due to LTO with !CONFIG_MODULES: github.com/GrapheneOS/ker

9:24 AM · Apr 24, 2020Twitter Web App

Replying to

and

AOSP uses CFI (and ShadowCallStack) for the Linux kernel on the Pixel 3 / 3 XL / 3a / 3a XL / 4 / 4 XL but it uses dynamic modules to reuse the kernel across multiple devices and improve boot time via async loading. Using !CONFIG_MODULES in GrapheneOS improves the CFI precision.

Replying to

and

The type-based checks work the same either way, but having nearly everything marked as an internal function allows the compiler to figure out that most of the non-static functions never have their address taken and don't need to be included in the sets of permitted callees.

Show replies