From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129063 invoked by alias); 10 Jan 2019 16:49:57 -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 129054 invoked by uid 89); 10 Jan 2019 16:49:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: EUR04-VI1-obe.outbound.protection.outlook.com Received: from mail-eopbgr80055.outbound.protection.outlook.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (40.107.8.55) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 16:49:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1WUdsoM7O/XPdsFmZwcAiL36rWN1pVgR9kcmE+b07Nk=; b=Kf8qAXkcSGuXU+0Fn/YH8K5e26Wp0t7u4ML0dvqPHKzTkLVVRycllR11MmFCX7Iu3n3RiD3V280wt18FrXRZ6k7drCh+SFqBE5iyimlm84M4fg64jIce4tAFV6uZnOkrD5p4KDyVHJa9sD+wKn1g32nGY7e5MC9mGDJiAKAz8u8= Received: from AM6PR08MB3783.eurprd08.prod.outlook.com (20.178.90.77) by AM6PR08MB3765.eurprd08.prod.outlook.com (20.178.88.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.13; Thu, 10 Jan 2019 16:49:51 +0000 Received: from AM6PR08MB3783.eurprd08.prod.outlook.com ([fe80::ed0f:db31:e579:44f0]) by AM6PR08MB3783.eurprd08.prod.outlook.com ([fe80::ed0f:db31:e579:44f0%3]) with mapi id 15.20.1495.011; Thu, 10 Jan 2019 16:49:51 +0000 From: Ramana Radhakrishnan To: James Greenhalgh CC: 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 Date: Thu, 10 Jan 2019 16:49:00 -0000 Message-ID: <499a4346-ad04-62a9-965a-2009d323fd0c@arm.com> References: <7a5a57fa-629d-d2ff-6292-e0893647ec8a@arm.com> <20190110154927.GA37554@arm.com> In-Reply-To: <20190110154927.GA37554@arm.com> user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ramana.Radhakrishnan@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-01/txt/msg00559.txt.bz2 On 10/01/2019 15:49, James Greenhalgh wrote: > On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote: >> For quite sometime the kernel guys, (more specifically Ard) have been >> talking about using a system register (sp_el0) and an offset from that >> for a canary based access. This patchset adds support for a new set of >> command line options similar to how powerpc has done this. >> >> 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. >> >> I did consider sticking this all under a mcmodel=3Dkernel-small option b= ut >> thought that would be a bit too aggressive. There is very little error >> checking I can do in terms of the system register being used and really >> the assembler would barf quite quickly in case things go wrong. I've >> managed to rebuild Ard's kernel tree with an additional patch that >> I will send to him. I haven't managed to boot this kernel. >> >> There was an additional question asked about the performance >> characteristics of this but it's a security feature and the kernel >> doesn't have the luxury of a hidden symbol. Further since the kernel >> uses sp_el0 for access everywhere and if they choose to use the same >> register I don't think the performance characteristics would be too bad, >> but that's a decision for the kernel folks to make when taking in the >> feature into the kernel. >> >> I still need to add some tests and documentation in invoke.texi but >> this is at the stage where it would be nice for some other folks >> to look at this. >> >> The difference in code generated is as below. >> >> extern void bar (char *); >> int foo (void) >> { >> char a[100]; >> bar (&a); >> } >> >> $GCC -O2 -fstack-protector-strong vs >> -mstack-protector-guard-reg=3Dsp_el0 -mstack-protector-guard=3Dsysreg >> -mstack-protector-guard-offset=3D1024 -fstack-protector-strong >> >>=20=09 >> --- tst.s 2018-12-03 09:46:21.174167443 +0000 >> +++ tst.s.1 2018-12-03 09:46:03.546257203 +0000 >> @@ -15,15 +15,14 @@ >> mov x29, sp >> str x19, [sp, 16] >> .cfi_offset 19, -128 >> - adrp x19, __stack_chk_guard >> - add x19, x19, :lo12:__stack_chk_guard >> - ldr x0, [x19] >> - str x0, [sp, 136] >> - mov x0,0 >> + mrs x19, sp_el0 >> add x0, sp, 32 >> + ldr x1, [x19, 1024] >> + str x1, [sp, 136] >> + mov x1,0 >> bl bar >> ldr x0, [sp, 136] >> - ldr x1, [x19] >> + ldr x1, [x19, 1024] >> eor x1, x0, x1 >> cbnz x1, .L5 >> >> >> >> >> I will be afk tomorrow and day after but this is to elicit some comments >> and for Ard to try this out with his kernel patches. >> >> Thoughts ? >=20 > I didn't see ananswer on list to Ard's questions about the command-line l= ogic. Ah I must have missed that - will take that up separately. > Remember to also fix up the error message concerns Florian raised. >=20 > That said, if Jakub is happy with this in Stage 4, I am too. >=20 > My biggest concern is the -mstack-protector-guard-reg interface, which > is unchecked user input and so opens up nasty ways to force the compiler > towards out of bounds accesses (e.g. > -mstack-protector-guard-reg=3D"What memory is at %10") >=20 -mstack-protector-guard-reg is fine - it's a system register , if the=20 assembler doesn't recognize it , it will barf. -mstack-protector-guard-offset=3D I assume is what you are=20 concerned about. I don't have a good answer to that one and am going to=20 chicken out and say this is the same interface as x86 and power and=20 while I accept it's an access to any location, the user can still do=20 that with a C program and any arbitrary inline asm :-/ regards Ramana > Thanks, > James >=20 >> >> regards >> Ramana >> >> gcc/ChangeLog: >> >> 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): Ne= w. >> (-mstack-protector-guard): Likewise. >> (-mstack-protector-guard-offset): Likewise. >> * doc/invoke.texi: Document new AArch64 options. >=20