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

[Daniele Buono <dbuono@linux.vnet.ibm.com>]

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?

Cheers,
Daniele

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.
>>>
>>> Paolo
>>
>> 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
>> cfi-blacklist.txt
>>
>> -Alex
>>
>