Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 28 Dec 2020 10:20:54 +0100
From: Charlotte Delenk <>
Subject: Re: [PATCH] Add support for LLVM's Control Flow Integrity


On 12/28/20 1:56 AM, Fangrui Song wrote:
>> tl;dr This is insufficient.
Yes, I'm aware that this only covers the few things that I have tested.
>> For libc, we can ignore all the other CFI checks.
>> ldso/ has several indirect function calls which are incompatible with 
>> -fsanitize=cfi-icall
Use of CFI together with dynamic loading wasn't one of my priorities but 
it certainly might be for others
>> ldso/dlstart.c
>> In _dlstart_c, dls2((void *)base, sp); The address is obtained via 
>> GETFUNCSYM (inline asm) - Clang does not know the original function 
>> type and thus the llvm.type.test check will fail.
I'm going to disable cfi for that one as well.
>> (Another problem: Clang tracks undefined symbols in module-level 
>> inline asm but does not know undefined symbols in function-scope 
>> inline asm.
I think you can also add an __attribute__((used)) to the declaration; I 
have successfully used that hack in other low-level software that calls 
otherwise unused functions from inline asm.
> I wrote a clang-tidy check (attached) to find all indirect function
> calls. Here is the list. cfi-icall can protect them. Very few like
> __libc_start_main.c:64 may need __attribute__((__no_sanitize__("cfi"))).
Thank you for writing this! I'll look through the list and see if I spot 
other issues.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.