[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0326d35a-4c1d-3d25-1917-166e5b580062@darkkirb.de>
Date: Mon, 28 Dec 2020 10:20:54 +0100
From: Charlotte Delenk <darkkirb@...kkirb.de>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add support for LLVM's Control Flow Integrity
Hi,
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.
