On Tue, Oct 26, 2021 at 10:16:22PM +0200, Peter Zijlstra wrote:

On Wed, Oct 13, 2021 at 11:16:43AM -0700, Sami Tolvanen wrote:

quoted

This series adds support for Clang's Control-Flow Integrity (CFI)
checking to x86_64. With CFI, the compiler injects a runtime
check before each indirect function call to ensure the target is
a valid function with the correct static type. This restricts
possible call targets and makes it more difficult for an attacker
to exploit bugs that allow the modification of stored function
pointers. For more details, see:

  https://clang.llvm.org/docs/ControlFlowIntegrity.html

So, if I understand this right, the compiler emits, for every function
two things: 1) the actual funcion and 2) a jump-table entry.

Then, every time the address of a function is taken, 2) is given instead
of the expected 1), right?

Yes, and we had to bodge around this with function_nocfi() to get the
actual function address.

Really there should be a compiler intrinsic or attribute for this, given
the compiler has all the releveant information available. On arm64 we
had to us inine asm to generate the addres...

Taking a step back, it'd be nicer if we didn't have the jump-table shim
at all, and had some SW landing pad (e.g. a NOP with some magic bytes)
in the callees that the caller could check for. Then function pointers
would remain callable in call cases, and we could explcitly add landing
pads to asm to protect those. I *think* that's what the grsecurity folk
do, but I could be mistaken.

But how does this work with things like static_call(), which we give a
function address (now a jump-table entry) and use that to write direct
call instructions?

Should not this jump-table thingy get converted to an actual function
address somewhere around arch_static_call_transform() ? This also seems
relevant for arm64 (which already has CLANG_CFI supported) given:

  https://lkml.kernel.org/r/20211025122102.46089-3-frederic@kernel.org

Ugh, yeah, we'll need to do the function_nocfi() dance somewhere...

Thanks,
Mark.