Message ID | a7b9ab2109b5e9d16def6b2f1b706a46cc384469.1593612309.git.szabolcs.nagy@arm.com |
---|---|
State | Committed |
Commit | de9301c02e898fb20a609b459d81afda42f39c61 |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B030C3861862; Wed, 1 Jul 2020 14:40:11 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10067.outbound.protection.outlook.com [40.107.1.67]) by sourceware.org (Postfix) with ESMTPS id 8FDCB3857007 for <libc-alpha@sourceware.org>; Wed, 1 Jul 2020 14:40:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8FDCB3857007 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Szabolcs.Nagy@arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+yIFGeQMIOxAMrIuSPt8b4zXvfXhhUFgdoXr7xPkf8=; b=68BPbdGZloDjQPBBncejk5IObeto8r6AQ8bZuj43++GVoYCwxR4D5PGzAzLL3Z6/ysI0hummekVYPuRFJMaX/L9T0a4+fBgyic230mHvxgmkDZ6hmjWia6STLVPVIUP7LZFd+xrpE9NMGEDdn+swcLdBewz12IOlAMEELW6/XQg= Received: from MRXP264CA0032.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::20) by AM5PR0801MB1873.eurprd08.prod.outlook.com (2603:10a6:203:4b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Wed, 1 Jul 2020 14:40:06 +0000 Received: from VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:14:cafe::e6) by MRXP264CA0032.outlook.office365.com (2603:10a6:500:14::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20 via Frontend Transport; Wed, 1 Jul 2020 14:40:06 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; sourceware.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT032.mail.protection.outlook.com (10.152.18.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 1 Jul 2020 14:40:06 +0000 Received: ("Tessian outbound f7489b7e84a7:v62"); Wed, 01 Jul 2020 14:40:05 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 9dc1309c0525b9a7 X-CR-MTA-TID: 64aa7808 Received: from 2926d023355c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 68148287-AA35-49E2-A4CB-AD028BA7FAF6.1; Wed, 01 Jul 2020 14:39:59 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2926d023355c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jul 2020 14:39:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kbq8+hYPBUNLFQlyMLFOgwe4ZFH1MS+SdJBb+qkEbEKdIMMQWXc0vC7uWnzdrg2SSqHnb0lQps1E9hl0wUSLTy5o2Yy8KlXSAa325s2ozSPIhzavoba8tkxsvr2Eoki8EeoJocNaWfNUcItKyuuJZaILDUbiRNWH4UHfCXgGWK7l+jj2dgEjQu2mDRC/bC3kYxfJb4L6iXTc5TnSBIlsFJ6t1s8XC6Qe8o/NMTRLxzQS94EKSJQbcK7N0ccTVaZjP0N78Nta6zxae2ZvHQ8VU32Tug3I0BmZtVJxOGrr8xI2vT9PP15LM98r0RwzHbPK6svRKIMkM8OT2M/TA02pQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+yIFGeQMIOxAMrIuSPt8b4zXvfXhhUFgdoXr7xPkf8=; b=RPUUnh9cCa9QIj4i0KjOGYs2R4+VsPfZBxsHCqqpFDeQ8HilitIWj2cMzqOklS7k+V/bEijRtg616tsG8I/OB6bRMzwgaS/2D9rdVx9cFFcplSszfkbK7PcEoMEY13MIzWW3PUBPmJUR0BvINaS2FNQQcONR4XyT73J0tYp6K+OaPnwhbo9KKKANvY0K+00dJ8fW9r5SN78Z47/nJKO8JDi00tUVZe6G32OEVY5N+iGpWpSu80rrlppd/cbz9qGHd8loFdyPOvxZcoVDuECKHh3MNHhHK7oRKrwjVsgR/6u1V0BIE0H7CjOw5/LFc4Me46wf/fvrSzzwOvrMwMLKUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+yIFGeQMIOxAMrIuSPt8b4zXvfXhhUFgdoXr7xPkf8=; b=68BPbdGZloDjQPBBncejk5IObeto8r6AQ8bZuj43++GVoYCwxR4D5PGzAzLL3Z6/ysI0hummekVYPuRFJMaX/L9T0a4+fBgyic230mHvxgmkDZ6hmjWia6STLVPVIUP7LZFd+xrpE9NMGEDdn+swcLdBewz12IOlAMEELW6/XQg= Authentication-Results-Original: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com; Received: from AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) by AM6PR08MB3879.eurprd08.prod.outlook.com (2603:10a6:20b:8c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Wed, 1 Jul 2020 14:39:58 +0000 Received: from AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::2404:de9f:78c0:313c]) by AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::2404:de9f:78c0:313c%6]) with mapi id 15.20.3131.033; Wed, 1 Jul 2020 14:39:58 +0000 From: Szabolcs Nagy <szabolcs.nagy@arm.com> To: libc-alpha@sourceware.org Subject: [PATCH v6 09/14] aarch64: ensure objects are BTI compatible Date: Wed, 1 Jul 2020 15:39:52 +0100 Message-Id: <a7b9ab2109b5e9d16def6b2f1b706a46cc384469.1593612309.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1593612309.git.szabolcs.nagy@arm.com> References: <cover.1593612309.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-ClientProxiedBy: CWLP123CA0149.GBRP123.PROD.OUTLOOK.COM (2603:10a6:401:88::17) To AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.53) by CWLP123CA0149.GBRP123.PROD.OUTLOOK.COM (2603:10a6:401:88::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.21 via Frontend Transport; Wed, 1 Jul 2020 14:39:57 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.53] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f6bebc4f-1314-48ae-e539-08d81dcca59a X-MS-TrafficTypeDiagnostic: AM6PR08MB3879:|AM5PR0801MB1873: X-Microsoft-Antispam-PRVS: <AM5PR0801MB187351407D4803BAA68DF3AFED6C0@AM5PR0801MB1873.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8273;OLM:8273; X-Forefront-PRVS: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: X6/wMuAtQymgIjls6ARq1mzv7COnzudfi4qAlyfi3kEJspVZ02Cz2CNHx0nGcqaXDUBSoclpLvqOTJnojMWabq2Vt/DtmS5jLRhPT7HRF/ovEvjyMnUFeg28LRch/edzbNmRhkXayNHwJ5Zd3P+FAQ9h4lVh4/9aPSULcXwN273gjeOrKbQpdFULvDSlIXnF5eOWvOeJMHpyxH+N+hFH6FdfmZJTCyRJJlNsw7dw1n30zewBT7rPV5ZE+k5/fHnjS1I1P0cSmld9KIxWOIqBDG5ZRwo1g23IUOdcDJYWJ7fVLXlrtLdB+RHpSX6OsMef1Dt+KJ7GNj+xhziSYH+5zsf3i4N2nQuV8RTMe2Aj83y+l9L8kQIMy4vg2E7Cq+l7VvAt/dV7rOZmoOkD9BcZC/bTt1uEA3KXi4h+BbFSKc0= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3047.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(346002)(376002)(396003)(186003)(2906002)(52116002)(478600001)(36756003)(956004)(2616005)(6916009)(6512007)(66946007)(66476007)(44832011)(6666004)(66556008)(6486002)(69590400007)(83380400001)(5660300002)(26005)(6506007)(16526019)(86362001)(8936002)(316002)(8676002)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: LaXGTgIktVuedFuyp3Whp+WSdnkAzHaiOMbbFtoWCDAz10l2HeI23/bgiszpx7n4aj7fHlNpSDVxue8JdzM7sREasRv+GrhSpK1gq50tf/RDhujfJZVaEuqLUEtYhT41clyMFvZSNI7g0hjs7XxXkTd6C8JIJQZykGECPrx3pTnP2kxKnYJRXDrMlAb4U4HrE5D6zqBHQsfFt0yrX2XHQA/6WxB7s6KqqRARTX1CW7SwS4g8+1nvS6EIr+SJND3/xfpkdqNp90dHagP5V4EWme9DLCvzul97rxPeuRvVJ5ibg6xwVW/Blk6LiKHzLkFj6ad0Z2Vx7u+iUeAJZQ+jmyxdR3kvFRdAywkUVZ3V0uMhO/Yg36fgPYIMNuksJ4yDFoi3lhQXVbaT2gqcZkzJOtgghg7iPy1UfqveLOSAzmYpWbNzzhf3ppQooUWnH4rmfgAYeGLIoqb7lVrNp+lQLYfQ7a26xGwlbCv6WSeHJ+SVl/6bvFLvWA4z9XY/J1Ta X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3879 Original-Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none; sourceware.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(376002)(396003)(39860400002)(46966005)(83380400001)(8676002)(44832011)(5660300002)(6486002)(2906002)(36906005)(82310400002)(8936002)(316002)(86362001)(81166007)(47076004)(70206006)(6506007)(186003)(956004)(336012)(356005)(2616005)(82740400003)(70586007)(36756003)(6916009)(6666004)(69590400007)(26005)(6512007)(16526019)(478600001)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: b684629a-47a1-4536-7f19-08d81dcca0bd X-Forefront-PRVS: 04519BA941 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UW4I9iQ/cUDSFqQekXNOkJKqeDCwxwH/ppd9EqtgSArpfaP8SBq4i/dC426qIFabLh9mS+J8m++C1PHQ/U3Owb55ziUlmKijN4Nt9+kqcT6Nke+0UTkC58z+piiZ43CbE3zZ7MDgg1YGU+3UveKOGct7pxt8s+S1ED0rJ3c2l0uO9P264cQq/ooKIjQ7muxbNyC3x3kkGkfq4ZQDtT6fhRXZbTUmWpajXklGCrSaE1Ms9XHrRlaIz48/qKV40fvTHkHOm66JYh0666sv/wcd4xyvd7YNDuTMdikdW8UShNRWrv+9dFWxpkLlfauB660HszTBDi57sbU1uV7atenGArTRLX6Znv+hNCXYiUKp8jhhi+uznARkyzE3bx+jBLWiHm9qRcqkySV+0hUJ7n9OUjZvDJYQVkHjmCEqM9+hmLmNED0fNRhPvdv7ykXLNDMTtU6CWBOGo05JYKbJCYbuFA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 14:40:06.0721 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f6bebc4f-1314-48ae-e539-08d81dcca59a X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1873 X-Spam-Status: No, score=-16.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
aarch64: branch protection support
|
|
Commit Message
Szabolcs Nagy
July 1, 2020, 2:39 p.m. UTC
When glibc is built with branch protection (i.e. with a gcc configured with --enable-standard-branch-protection), all glibc binaries should be BTI compatible and marked as such. It is easy to link BTI incompatible objects by accident and this is silent currently which is usually not the expectation, so this is changed into a link error. (There is no linker flag for failing on BTI incompatible inputs so all warnings are turned into fatal errors outside the test system when building glibc with branch protection.) Unfortunately, outlined atomic functions are not BTI compatible in libgcc (PR libgcc/96001), so to build glibc with current gcc use 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon and then glibc can be built and tested without such workarounds. --- sysdeps/aarch64/Makefile | 8 ++++++++ sysdeps/aarch64/configure | 2 ++ sysdeps/aarch64/configure.ac | 1 + 3 files changed, 11 insertions(+)
Comments
On 01/07/2020 11:39, Szabolcs Nagy wrote: > When glibc is built with branch protection (i.e. with a gcc configured > with --enable-standard-branch-protection), all glibc binaries should > be BTI compatible and marked as such. > > It is easy to link BTI incompatible objects by accident and this is > silent currently which is usually not the expectation, so this is > changed into a link error. (There is no linker flag for failing on > BTI incompatible inputs so all warnings are turned into fatal errors > outside the test system when building glibc with branch protection.) > > Unfortunately, outlined atomic functions are not BTI compatible in > libgcc (PR libgcc/96001), so to build glibc with current gcc use > 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon > and then glibc can be built and tested without such workarounds. Is the outlined atomic present in any current released gcc? If so should we add a configure handler to add -mno-outline-atomics for such cases? Besides that LGTM, thanks. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > --- > sysdeps/aarch64/Makefile | 8 ++++++++ > sysdeps/aarch64/configure | 2 ++ > sysdeps/aarch64/configure.ac | 1 + > 3 files changed, 11 insertions(+) > > diff --git a/sysdeps/aarch64/Makefile b/sysdeps/aarch64/Makefile > index 5ae8b082b0..7f82fc055e 100644 > --- a/sysdeps/aarch64/Makefile > +++ b/sysdeps/aarch64/Makefile > @@ -1,5 +1,13 @@ > long-double-fcts = yes > > +ifeq (yes,$(aarch64-bti)) > +# Mark linker output BTI compatible, it warns on non-BTI inputs. > +sysdep-LDFLAGS += -Wl,-z,force-bti > +# Make warnings fatal outside the test system. > +LDFLAGS-lib.so += -Wl,--fatal-warnings > +LDFLAGS-rtld += -Wl,-z,force-bti,--fatal-warnings > +endif > + > ifeq ($(subdir),elf) > sysdep-dl-routines += dl-bti > endif Ok. > diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure > index 70477a7fa5..c637540436 100644 > --- a/sysdeps/aarch64/configure > +++ b/sysdeps/aarch64/configure > @@ -210,6 +210,8 @@ EOF > fi > { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_bti" >&5 > $as_echo "$libc_cv_aarch64_bti" >&6; } > +config_vars="$config_vars > +aarch64-bti = $libc_cv_aarch64_bti" > if test $libc_cv_aarch64_bti = yes; then > $as_echo "#define HAVE_AARCH64_BTI 1" >>confdefs.h > > diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac > index 798f494740..2c2817514d 100644 > --- a/sysdeps/aarch64/configure.ac > +++ b/sysdeps/aarch64/configure.ac > @@ -36,6 +36,7 @@ EOF > libc_cv_aarch64_bti=yes > fi > rm -rf conftest.*]) > +LIBC_CONFIG_VAR([aarch64-bti], [$libc_cv_aarch64_bti]) > if test $libc_cv_aarch64_bti = yes; then > AC_DEFINE(HAVE_AARCH64_BTI) > fi > Ok.
The 07/06/2020 14:37, Adhemerval Zanella via Libc-alpha wrote: > On 01/07/2020 11:39, Szabolcs Nagy wrote: > > When glibc is built with branch protection (i.e. with a gcc configured > > with --enable-standard-branch-protection), all glibc binaries should > > be BTI compatible and marked as such. > > > > It is easy to link BTI incompatible objects by accident and this is > > silent currently which is usually not the expectation, so this is > > changed into a link error. (There is no linker flag for failing on > > BTI incompatible inputs so all warnings are turned into fatal errors > > outside the test system when building glibc with branch protection.) > > > > Unfortunately, outlined atomic functions are not BTI compatible in > > libgcc (PR libgcc/96001), so to build glibc with current gcc use > > 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon > > and then glibc can be built and tested without such workarounds. > > Is the outlined atomic present in any current released gcc? If so > should we add a configure handler to add -mno-outline-atomics for > such cases? outlined atomics is supported for a while now (since gcc-9 i think) but it is now the default in gcc-10. i am testing patches to fix libgcc in gcc trunk and then backport to gcc-10 branch. my preference is to only support fixed gcc and use the -mno-outline-atomics as a temporary workaround so we can test the patches with gcc-10.1.0 it's not a good workaround for using the resulting toolchain for building user code with branch protection (which will have the same problem: silently dropping bti protection) so i think it's better to fail the build. > > Besides that LGTM, thanks. > > Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > > > --- > > sysdeps/aarch64/Makefile | 8 ++++++++ > > sysdeps/aarch64/configure | 2 ++ > > sysdeps/aarch64/configure.ac | 1 + > > 3 files changed, 11 insertions(+) > > > > diff --git a/sysdeps/aarch64/Makefile b/sysdeps/aarch64/Makefile > > index 5ae8b082b0..7f82fc055e 100644 > > --- a/sysdeps/aarch64/Makefile > > +++ b/sysdeps/aarch64/Makefile > > @@ -1,5 +1,13 @@ > > long-double-fcts = yes > > > > +ifeq (yes,$(aarch64-bti)) > > +# Mark linker output BTI compatible, it warns on non-BTI inputs. > > +sysdep-LDFLAGS += -Wl,-z,force-bti > > +# Make warnings fatal outside the test system. > > +LDFLAGS-lib.so += -Wl,--fatal-warnings > > +LDFLAGS-rtld += -Wl,-z,force-bti,--fatal-warnings > > +endif > > + > > ifeq ($(subdir),elf) > > sysdep-dl-routines += dl-bti > > endif > > Ok. > > > diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure > > index 70477a7fa5..c637540436 100644 > > --- a/sysdeps/aarch64/configure > > +++ b/sysdeps/aarch64/configure > > @@ -210,6 +210,8 @@ EOF > > fi > > { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_bti" >&5 > > $as_echo "$libc_cv_aarch64_bti" >&6; } > > +config_vars="$config_vars > > +aarch64-bti = $libc_cv_aarch64_bti" > > if test $libc_cv_aarch64_bti = yes; then > > $as_echo "#define HAVE_AARCH64_BTI 1" >>confdefs.h > > > > diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac > > index 798f494740..2c2817514d 100644 > > --- a/sysdeps/aarch64/configure.ac > > +++ b/sysdeps/aarch64/configure.ac > > @@ -36,6 +36,7 @@ EOF > > libc_cv_aarch64_bti=yes > > fi > > rm -rf conftest.*]) > > +LIBC_CONFIG_VAR([aarch64-bti], [$libc_cv_aarch64_bti]) > > if test $libc_cv_aarch64_bti = yes; then > > AC_DEFINE(HAVE_AARCH64_BTI) > > fi > > > > Ok. --
On 06/07/2020 15:01, Szabolcs Nagy wrote: > The 07/06/2020 14:37, Adhemerval Zanella via Libc-alpha wrote: >> On 01/07/2020 11:39, Szabolcs Nagy wrote: >>> When glibc is built with branch protection (i.e. with a gcc configured >>> with --enable-standard-branch-protection), all glibc binaries should >>> be BTI compatible and marked as such. >>> >>> It is easy to link BTI incompatible objects by accident and this is >>> silent currently which is usually not the expectation, so this is >>> changed into a link error. (There is no linker flag for failing on >>> BTI incompatible inputs so all warnings are turned into fatal errors >>> outside the test system when building glibc with branch protection.) >>> >>> Unfortunately, outlined atomic functions are not BTI compatible in >>> libgcc (PR libgcc/96001), so to build glibc with current gcc use >>> 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon >>> and then glibc can be built and tested without such workarounds. >> >> Is the outlined atomic present in any current released gcc? If so >> should we add a configure handler to add -mno-outline-atomics for >> such cases? > > outlined atomics is supported for a while now (since > gcc-9 i think) but it is now the default in gcc-10. > > i am testing patches to fix libgcc in gcc trunk and > then backport to gcc-10 branch. > > my preference is to only support fixed gcc and use > the -mno-outline-atomics as a temporary workaround > so we can test the patches with gcc-10.1.0 > > it's not a good workaround for using the resulting > toolchain for building user code with branch protection > (which will have the same problem: silently dropping > bti protection) so i think it's better to fail the build. Right, I think it should be ok to sign it with a build failure.
diff --git a/sysdeps/aarch64/Makefile b/sysdeps/aarch64/Makefile index 5ae8b082b0..7f82fc055e 100644 --- a/sysdeps/aarch64/Makefile +++ b/sysdeps/aarch64/Makefile @@ -1,5 +1,13 @@ long-double-fcts = yes +ifeq (yes,$(aarch64-bti)) +# Mark linker output BTI compatible, it warns on non-BTI inputs. +sysdep-LDFLAGS += -Wl,-z,force-bti +# Make warnings fatal outside the test system. +LDFLAGS-lib.so += -Wl,--fatal-warnings +LDFLAGS-rtld += -Wl,-z,force-bti,--fatal-warnings +endif + ifeq ($(subdir),elf) sysdep-dl-routines += dl-bti endif diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure index 70477a7fa5..c637540436 100644 --- a/sysdeps/aarch64/configure +++ b/sysdeps/aarch64/configure @@ -210,6 +210,8 @@ EOF fi { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_bti" >&5 $as_echo "$libc_cv_aarch64_bti" >&6; } +config_vars="$config_vars +aarch64-bti = $libc_cv_aarch64_bti" if test $libc_cv_aarch64_bti = yes; then $as_echo "#define HAVE_AARCH64_BTI 1" >>confdefs.h diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac index 798f494740..2c2817514d 100644 --- a/sysdeps/aarch64/configure.ac +++ b/sysdeps/aarch64/configure.ac @@ -36,6 +36,7 @@ EOF libc_cv_aarch64_bti=yes fi rm -rf conftest.*]) +LIBC_CONFIG_VAR([aarch64-bti], [$libc_cv_aarch64_bti]) if test $libc_cv_aarch64_bti = yes; then AC_DEFINE(HAVE_AARCH64_BTI) fi