From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62567 invoked by alias); 3 Dec 2018 15:31:16 -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 62552 invoked by uid 89); 3 Dec 2018 15:31:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=slight 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; Mon, 03 Dec 2018 15:31:06 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 23B953082B72; Mon, 3 Dec 2018 15:31:05 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3726A19C7D; Mon, 3 Dec 2018 15:31:03 +0000 (UTC) From: Florian Weimer To: Ramana Radhakrishnan Cc: James Greenhalgh , Richard Earnshaw , Marcus Shawcroft , "gcc-patches\@gcc.gnu.org" , Ard Biesheuvel , Will Deacon , Mark Rutland , nd Subject: Re: [RFC][AArch64] Add support for system register based stack protector canary access References: <7a5a57fa-629d-d2ff-6292-e0893647ec8a@arm.com> Date: Mon, 03 Dec 2018 15:31:00 -0000 In-Reply-To: <7a5a57fa-629d-d2ff-6292-e0893647ec8a@arm.com> (Ramana Radhakrishnan's message of "Mon, 3 Dec 2018 09:55:36 +0000") Message-ID: <875zwad3v6.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00084.txt.bz2 * Ramana Radhakrishnan: > I don't intend to change the defaults in userland, we've discussed this > for user-land in the past and as far as glibc and userland is concerned > we stick to the options as currently existing. The system register > option is really for the kernel to use along with an offset as they > control their ABI and this is a decision for them to make. 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. Thanks, Florian