From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19254 invoked by alias); 10 Jan 2019 12:51:41 -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 19238 invoked by uid 89); 10 Jan 2019 12:51:40 -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=tomorrow X-HELO: mail-ua1-f67.google.com Received: from mail-ua1-f67.google.com (HELO mail-ua1-f67.google.com) (209.85.222.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 12:51:38 +0000 Received: by mail-ua1-f67.google.com with SMTP id t8so3562675uap.0 for ; Thu, 10 Jan 2019 04:51:38 -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=YMwpARWc5fPXMAyvF0AaTpi7BMm2q51hBMss/whjrSk=; b=QQCm7fY8iR8DFzlGLwX9jKMSxMBpJkSoBLkDWHB9sDKZBlOWXcMNT5h4lE8KLcA9hy Cvmr2CD1rAg/yEsz+D3uAEP5KFzN+h1UMmN5VaxvytmyXaKoS15s1CFpylVAy5oZWvWw FyZA+IPfw9owLg8qXmkC+lME4UUtTQc4MiWVC6h6gzAIxg9dp6eHg+18HzHjZMhtNtFj P1Ko0LAqRblxWHOYRKjdCm/jZMiqdwlxB2OwEXq+ffLcTheJ4Sr5GYc5xFIFd+Cj/mXB 2LJawL9T2iNDhBD98/i/UJ2NoibTriFcuFKYzwTZO85rckspAtc6V87UT0cCcacjwrlw KXFQ== MIME-Version: 1.0 References: <7a5a57fa-629d-d2ff-6292-e0893647ec8a@arm.com> <20190110110540.GW30353@tucnak> In-Reply-To: <20190110110540.GW30353@tucnak> From: Ramana Radhakrishnan Date: Thu, 10 Jan 2019 12:51:00 -0000 Message-ID: Subject: Re: [RFC][AArch64] Add support for system register based stack protector canary access To: Jakub Jelinek Cc: Ramana Radhakrishnan , James Greenhalgh , Richard Earnshaw , Marcus Shawcroft , "gcc-patches@gcc.gnu.org" , Ard Biesheuvel , Will Deacon , Mark Rutland , nd Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00536.txt.bz2 On Thu, Jan 10, 2019 at 11:05 AM Jakub Jelinek wrote: > > On Thu, Jan 10, 2019 at 10:53:32AM +0000, Ramana Radhakrishnan wrote: > > > 2018-11-23 Ramana Radhakrishnan > > > > > > * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New > > > * config/aarch64/aarch64.c (aarch64_override_options_internal): > > > Handle > > > and put in error checks for stack protector guard options. > > > (aarch64_stack_protect_guard): New. > > > (TARGET_STACK_PROTECT_GUARD): Define. > > > * config/aarch64/aarch64.md (UNSPEC_SSP_SYSREG): New. > > > (reg_stack_protect_address): New. > > > (stack_protect_set): Adjust for SSP_GLOBAL. > > > (stack_protect_test): Likewise. > > > * config/aarch64/aarch64.opt (-mstack-protector-guard-reg): New. > > > (-mstack-protector-guard): Likewise. > > > (-mstack-protector-guard-offset): Likewise. > > > * doc/invoke.texi: Document new AArch64 options. > > > > Any further thoughts or is it just Jakub's comments that I need to > > address on this patch ? It looks like the kernel folks have queued > > this for the next kernel release and given this is helping the kernel > > with a security feature, can we move this forward ? > > From RM POV this is ok in stage4 if you commit it RSN. > Both x86 and powerpc have -mstack-protector-guard{,-reg,-offset}= options, > x86 even has -mstack-protector-guard-symbol=. So it would be nice if the > aarch64 options are compatible with those other arches. > Thanks Jakub. I haven't added the -mstack-protector-guard-symbol as there is no requirement to do so now and I don't want to add an option that isn't being used. IIRC, the other options seem to be in sync with x86 and powerpc. > Please make sure you don't regress non-glibc SSP support (don't repeat > PR85644/PR86832). > That should be ok as I'm not changing any defaults. I would expect that non-glibc based libraries that support SSP must be mimicking glibc support for this using the global symbol as there is nothing special in the backend for this today. I guess there is freebsd as a non-glibc target or musl that I can look at but I don't expect that to be an issue. I'll wait until tomorrow to respin just to see if I can get any further feedback. regards Ramana > Jakub