From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no
	version=3.4.4
Received: (qmail 5999 invoked from network); 28 Dec 2020 09:21:42 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 28 Dec 2020 09:21:42 -0000
Received: (qmail 11464 invoked by uid 550); 28 Dec 2020 09:21:36 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 11446 invoked from network); 28 Dec 2020 09:21:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=darkkirb.de; s=mail;
	t=1609147284; bh=8iVuv/O+1b3KzNcnoukmkRRHPKxRo9VY6FdquXcQ3D0=;
	h=Subject:To:References:From:Date:In-Reply-To;
	b=DZxVHzCjSUUmoiR3n0+Cz5IvLraIJTMi3ioAGJvU2Q0RrNUvkpsaUf8WJcK4Nw6U3
	 wVZMa0d4zUGDuu3Kf5F3/YEyi0HmgaIjcepxiZk59LTns/IBkxxwAI6SgUrwm/SwF+
	 erwwNt0hKujVvjC0XrpkYnzIBE3DHVdn+o/UoNes=
To: musl@lists.openwall.com
References: <6106be97-2c82-75c0-ad88-2e49b17c68ee@darkkirb.de>
 <20201227230554.ddflrnbmyvjccj4n@gmail.com>
 <20201228005632.rezxjuehsgmr5ira@gmail.com>
From: Charlotte Delenk <darkkirb@darkkirb.de>
Message-ID: <0326d35a-4c1d-3d25-1917-166e5b580062@darkkirb.de>
Date: Mon, 28 Dec 2020 10:20:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <20201228005632.rezxjuehsgmr5ira@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: [musl] [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.