Discuss control-flow integrity implementation

[ddcc]

This is the follow-up to #717 that discusses fine-grained CFI for WebAssembly, currently implemented using runtime instrumentation from Clang/LLVM, but proposed to use multiple tables.

[ddcc]

It's not ready to be merged, but I'd like to get some feedback on the proposal. I plan to implement multiple table support and perform some benchmarks to measure the code size decrease (remove of runtime instrumentation), increase in runtime speed, etc.

[ghost]

Is this actually wasm 'supporting' CFI, or one implementation built on wasm?

[ddcc]

Aside from the coarse-grained CFI that we have already, it is supporting a fine-grained CFI implementation from Clang/LLVM.

[d1m0]

I am trying to understand how fine-grained a CFI scheme we are aiming to support using Wasm primitives. Specifically do we support non-disjoint sets? I think the referenced LLVM CFI implementation does support them, but the proposal talks about disjoint sets.

To make the question concrete, here is a small example: Imagine a C++ program with classes A,B,C,D all implementing/overriding a method f(). They form the following hierarchy:

      A
     /  \
   B    C
   |
   D

And we have the following program:

        A* a = ... ;
(1)     a->f(); // safe values are Af,Bf,Cf,Df
        B *b = ...;
(2)     b->f(); // safe values are Bf, Df

Are the allowed sets of targets at (1) and (2) the same? If not how would this be enforced in wasm?

If we want to support different sets for (1) and (2) in Wasm, using separate function tables, it seems like there would be a lot of duplication.

[ddcc]

There are no limits on CFI granularity from Wasm itself, but efficiency of the CFI implementation tends to be a usage concern.

The Clang/LLVM implementation doesn't support disjoint sets, because it uses type signatures. So, in your example, all implementations of f() would be in the same set. Adding support for non-disjoint sets is practically infeasible with a single homogeneous table and index range checking. One could implement partial support by allowing overlapping ranges, but that requires careful layout of indexes, and doesn't scale well. At some point, it would need instrumentation for checking multiple independent ranges, which has high runtime overhead.

Nevertheless, non-disjoint tables should be easily doable using multiple homogeneous tables, although you do end up with duplicate entries. From your example, put (1) in one table, and (2) in another table. Of course, you could optimize this further with some sort of hybrid multiple tables plus range-based checking approach, but that's beyond the scope of this proposal.

Thanks, I will update the text to clarify based on the comments.

[ddcc]

I've updated the text, please take a look. The single table CFI implementation has also been merged into upstream Clang/LLVM.

[dschuff]

Since this now focuses on current features, it doesn't need to have the Future Features milestone. :)

[ddcc]

Rebased

[jfbastien]

This seems non-controversial based on comments and how long it's been open. I've seen people ask about CFI elsewhere, so even if it isn't comprehensive it's a step in the right direction. Therefore, merging, happy to take more PRs to improve.

[ddcc]

Good to see this finally getting merged :)