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.