From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63028 invoked by alias); 4 Dec 2018 12:58:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 63006 invoked by uid 89); 4 Dec 2018 12:58:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:sk:dhcp-19, H*RU:sk:dhcp-19, H*r:sk:dhcp-19, fedora X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Dec 2018 12:58:27 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 734F73084293; Tue, 4 Dec 2018 12:58:26 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-219.str.redhat.com [10.33.192.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A2D97611D2; Tue, 4 Dec 2018 12:58:25 +0000 (UTC) From: Florian Weimer To: Wilco Dijkstra Cc: GCC Patches , nd Subject: Re: [RFC][AArch64] Add support for system register based stack protector canary access References: Date: Tue, 04 Dec 2018 12:58:00 -0000 In-Reply-To: (Wilco Dijkstra's message of "Tue, 4 Dec 2018 03:51:02 +0000") Message-ID: <87va49ih3j.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00167.txt.bz2 * Wilco Dijkstra: >> For userland, I would like to eventually copy the OpenBSD approach for >> architectures which have some form of PC-relative addressing: we can >> have multiple random canaries in (RELRO) .rodata in sufficiently close >> to the code that needs them (assuming that we have split .rodata). At >> least for x86-64, I expect this to be a small win. It's also a slight >> hardening improvement if the reference canary is not stored in writable >> memory. > > On AArch64 hardware pointer signing already provides a free and more robust > implementation of stack canaries, so we could change -fstack-protector to > use that when pointer signing is enabled. I expected to use both because not all AArch64 implementations support pointer signing, and we'd use the stack protector to get some coverage for the legacy implementations. (I'm still waiting for a request to enable pointer signing in Fedora rawhide, BTW.) Thanks, Florian