From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7828 invoked by alias); 7 Dec 2018 14:51:53 -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 7819 invoked by uid 89); 7 Dec 2018 14:51:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=armv8.3-a, Armv8.3-A, Armv83A, armv83a X-HELO: mail-vs1-f43.google.com Received: from mail-vs1-f43.google.com (HELO mail-vs1-f43.google.com) (209.85.217.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Dec 2018 14:51:50 +0000 Received: by mail-vs1-f43.google.com with SMTP id v205so2596422vsc.3 for ; Fri, 07 Dec 2018 06:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cUfU6rnkPz+ewXxuYWHvm6NlQ5SYZCLQlYtgoB4n3iM=; b=W5rfG5L/fYINpGH1UPZFCqVC/wJnmiCoyQ0p/F/KBKL6m1ATh1pTKCMaE9S1Vk2aFP W/zX+mu1Oe3HxIpPmJqySg6i1Gin9iXp86d/UN2PAAadQUU8DeYXUEFjuw4+/v+BIRQi E5wXbOXVqYNJ5r/pR59uYL4nGNqMS5CggIAnxKGgyZSgP/UWaVLZM5bIVvsBxj5NQrXF BUdSBQ+wTQKjL6jIdt1DmAE5YsuvABVoawMEm82RbwTeHvA0Xjd8NcteC1vBHsBv4D4u XfynpyehnCSAP8WIzY+n6+ZbOTYp4usW4Yhb9UqOQTztGuturPiptu5Py0PO0gBLMl24 HfGw== MIME-Version: 1.0 References: <87va49ih3j.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87va49ih3j.fsf@oldenburg2.str.redhat.com> From: Ramana Radhakrishnan Date: Fri, 07 Dec 2018 14:51:00 -0000 Message-ID: Subject: Re: [RFC][AArch64] Add support for system register based stack protector canary access To: Florian Weimer Cc: Wilco Dijkstra , gcc-patches , nd Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00458.txt.bz2 On Tue, Dec 4, 2018 at 12:58 PM Florian Weimer wrote: > > * 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). On AArch64 as well we've split .rodata. I think I did this with GCC 5. All the addressing of global data is through PC relative access and in the small model which is the default in Linux userland, I think we'll just be fine. > 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. Indeed. until the default goes up to Armv8.3-A it's going to be default to this. regards Ramana > > Thanks, > Florian