[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] configure: add support for Control-Flow Integrity

From: Daniele Buono
Subject: Re: [PATCH 2/2] configure: add support for Control-Flow Integrity
Date: Mon, 10 Aug 2020 15:01:37 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

Hi Alex, Paolo
Hitting a small issue while adding support for lto (and therefore cfi) to the fuzzer.

The fuzzer requires a modified linker script to place all of the stuff that needs to persist across fuzzing runs into a contiguous section of memory.

It does that by inserting three new sections after the .data section of the binary. Instead of rewriting a full linker script, it's using the *INSERT* keyword to add this to the default linker script.

Now, LTO with LLVM requires to use the gold linker, which does not have a default linker script and therefore does not support the *INSERT* keyword. This can be fixed by taking the default script from the bdf linker, adding the additional sections and ask gold to use the full script.

However, I don't like the idea of replacing the small, self-contained script snippet that is currently used, with a full script (which is probably also dependent on the bfd/os version). So I'm thinking of adding a check in configure. If gold is the linker, automatically create (somehow, still working on it) the full link script by obtaining the default bfd script and add the required parts. Would that work for you?


On 7/2/2020 11:43 AM, Daniele Buono wrote:
Hey Alex!

I agree, in most cases (possibly all of them), a wrong indirect function call will end up with something that is catched by ASan or UBSan. This way, however, you may catch it earlier and it may make debug easier (especially with --enable-cfi-debug which is printing an error with the calling and, most times, the called function).

UBSan does have a similar feature, -fsanitize=function, but unfortunately it works only on C++ code, and therefore is not good in the QEMU case.

And, of course, it will also be used to weed out missing functions in the CFI filter.

On 7/2/2020 9:38 AM, Alexander Bulekov wrote:
Can't wait to try this out!

On 200702 1459, Paolo Bonzini wrote:
On 02/07/20 14:50, Daniele Buono wrote:
I also wonder if this is something that could be put in the fuzzing
environment. It would probably also help in finding coding error in
corner cases quicker.

Yes, fuzzing and tests/docker/test-debug should enable CFI.  Also,
tests/docker/test-clang should enable LTO.


I believe CFI is most-useful as an active defensive measure. I can't
think of many cases where a fuzzer/test could raise a CFI alert that
wouldn't also be caught by something like canaries, ASan or UBsan,
though maybe I'm missing something. Maybe testing/fuzzing with CFI could
be useful to weed out any errors due to e.g. an incomplete


reply via email to

[Prev in Thread] Current Thread [Next in Thread]