Message ID | bfb7e82c231aec375aceeb517ba070a63e47576d.1611572339.git.szabolcs.nagy@arm.com |
---|---|
State | Committed |
Commit | c3c4a25e651d4d78b1751664a613807b7140ed7e |
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 1E0043947C3A; Mon, 25 Jan 2021 11:04:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E0043947C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611572645; bh=OoxasUT/ZaUTVNXIqDuxiHJo7NdWWyJBhxHLHWF2fBk=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=rLYb9ddw+VbuZdxAOYs53IRtX1ETfTGOnNyAcoODHzN6zyUnM9KbWUVWzK7Zc5kFI vp+hNgNd8YeVpZRFpqMZuD9qOjWJuYojW9eoQK90ieAs51qgM8W/SyiCMMpbFFyMWv RdvZ+XNIEvEnw2ozxLatzRRnaTiyXX2AFdO9+Rcs= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2060.outbound.protection.outlook.com [40.107.21.60]) by sourceware.org (Postfix) with ESMTPS id 462DD3840C23 for <libc-alpha@sourceware.org>; Mon, 25 Jan 2021 11:04:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 462DD3840C23 Received: from AM6PR10CA0105.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::46) by AM0PR08MB3490.eurprd08.prod.outlook.com (2603:10a6:208:e4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Mon, 25 Jan 2021 11:03:52 +0000 Received: from AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8c:cafe::fb) by AM6PR10CA0105.outlook.office365.com (2603:10a6:209:8c::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Mon, 25 Jan 2021 11:03:52 +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=pass 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 AM5EUR03FT032.mail.protection.outlook.com (10.152.16.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Mon, 25 Jan 2021 11:03:52 +0000 Received: ("Tessian outbound 8418c949a3fa:v71"); Mon, 25 Jan 2021 11:03:52 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1dda3ed76794958d X-CR-MTA-TID: 64aa7808 Received: from 5f048b128740.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 881970AB-BD9D-4567-A0E2-A580CA69DEC7.1; Mon, 25 Jan 2021 11:03:46 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5f048b128740.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 25 Jan 2021 11:03:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kd/NkI1eWfzRSfmcFWpAApPOAbtrz1NyY42TrOjMjvX6a4jLKrCdTYL2vonz0Oo7mOTfnj4xFHa9NXLiklBGcg4tRUnAVqU6CR3KQ92D+8gGf5MWFjnECdqFy4TStULdwZ+Wd6UbFg1pndzT3Lveb+aQ2MNhT6yN7IHqG0AaEnzoyeF2N5Z9adlrvRgrcpKreVmBMi5+fOxES5vdX6I9CrNqB2E0Z24h6CpZJfgyTIGFxns8LT0JEh0AkZ1XWku8kFz7IkOUZKcnoBGQKauKI/HI5HVF9+6OvSGLBtbAHXShP4xoOKwiXIcer9ejgN2FyYEfEgMJ/pwfZCa6qFzn/w== 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=OoxasUT/ZaUTVNXIqDuxiHJo7NdWWyJBhxHLHWF2fBk=; b=L0elTOID3OmsMWAHZouNgecZdz+EF3LwvVxc+D89+EJonZxFeZc5dmxGlvoqMedn4gHtcET+rBY5kIXiv5MWcSjFlLnIDs93fW45HBBeuxsG1NcBk+/WscZSUYFNFa4ynKFmIbcOdGbGPJhjqD62Io5SShaYe6LaYm/E1jl1rBfJAwd4vu6xgaCR1W+JUeCtr2f7stITcONVj0pI+ov3t4DQ4tdx41wEBPpyAolOhOzB0rXBGZYqDjO4SHK5HO1oG0w0pNzgU+hSte5Km9h7sGHLchXM9O8Qcy/CTiYKhBg61sio4+B7bdOPiS1uHi9JXefPDlXk/g763L/2aaablA== 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 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 PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PR3PR08MB5722.eurprd08.prod.outlook.com (2603:10a6:102:8f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.15; Mon, 25 Jan 2021 11:03:45 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::941:f3b7:c753:21f8]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::941:f3b7:c753:21f8%5]) with mapi id 15.20.3784.017; Mon, 25 Jan 2021 11:03:45 +0000 To: libc-alpha@sourceware.org Subject: [PATCH 1/2] aarch64: Move and update the definition of MTE_ENABLED Date: Mon, 25 Jan 2021 11:03:39 +0000 Message-Id: <bfb7e82c231aec375aceeb517ba070a63e47576d.1611572339.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1611572339.git.szabolcs.nagy@arm.com> References: <cover.1611572339.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-Originating-IP: [217.140.106.55] X-ClientProxiedBy: LO4P123CA0473.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a8::10) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.55) by LO4P123CA0473.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Mon, 25 Jan 2021 11:03:44 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 584f7a8d-2fcc-42b9-ccb5-08d8c120e675 X-MS-TrafficTypeDiagnostic: PR3PR08MB5722:|AM0PR08MB3490: X-Microsoft-Antispam-PRVS: <AM0PR08MB3490891D67086E36A9B1B03DEDBD0@AM0PR08MB3490.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: LMq+Xsd15ew/HYWN4fQB//i48q6JLUSm07+7C3F2eG4Qf0gASuWn/gJ5B00T/RJI+bcV23rhZ0wA//ehyOS8X47NmFs3D90LVcvmTsTA8x6kig/F6A+t7qqUM0UxxoZ6xrtP7mxFUX/00Ur3z9rvhoiIKwO/dHwBH7OF28JHJmYc6b2CmN30gTHYNX904XjBaY0/ZEhKZxUcUoQvgv3IamTzd1S05ZfZ5n1wp+5Jc+wlSwMl3PBCojiST0aDznvchIEO3dvbUvYRru3K47+ZHEA4UuJ7Q11Cid9VSKuv40aHx/KdwVxpieqGCRte6m1dCaRbQlIx+yaWGtLGs69zgjLyYnutcCSVmZYht+aDkw6gBaJwLe3J+OC/Jk9YiUDbCxcLCqZ7XfF+ZsUf0vnAlHTfp93ZEks8AAyM5VuyNXhfENYINLukaUKBtvcXvS/sKRzAsl4dW/i2/9BN5jewgdwco6+ZlyAedfH29xsBTiknSaudIFrEeWGba0VspVVX62r4HYyYSF722LuaB1XsdA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR08MB6320.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(186003)(2616005)(26005)(8676002)(956004)(44832011)(66476007)(2906002)(316002)(6486002)(16526019)(83380400001)(66946007)(66556008)(69590400011)(6666004)(478600001)(6506007)(6512007)(86362001)(6916009)(52116002)(36756003)(5660300002)(8936002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 0m9c92wPTlnZap6I/lM3aKgVyabeGjOwXqI6p8mdj33NQ142PI9C/dL2Q3dtH71mj8YtJy+ra8IdsEHxv9XPRSwN2M46rEjqY5vRiNTpEgmNYI+yOxSsZmLxD1egEhEzjFlqiwYVm/JYX4Rl07WemSVkZ9uDtiMz8pb/F4uE8cQdFVnbCsVW7LZtZ5ijrqCGHM/bcBu+Oa99DFDI24hdO1PQeOroeBjeFlNLXkguiQsA1TWrzjZd9G022bKvG08vENQUtb1Q5pbPBdUeHoC9Cjd5xXaErrPJx9shWlSEUmIE8/4RfyycBLSad9F/LN4geLL9hg8dsqL18iQphS7JBwHpBDxNul2+pUrgHeDpefTcjHR9nblmGYy5/U4QKREihyfMpARPLtGI1gwvhrQIab5JbrgeMF+pgzJz8qAlRWQ71VCiSuih/VBcxU/Us/ZXBqsILboRk0SOF9/Wf9bl6Edls20TgekZ7DcVdOZRzZXyeMRz498IWwMn/463uPqivAIuRvNn05oMLj+ZhwUE79fEm3In+ad6BR6YsvGhVdu9jWLz+4Yz2xC4Y3SmI5zjajRxOsvga+LtQ+Vt3NPtytgfRKarhI17daX8tNC1JqQOEFWVhmqZ0018zVfz4g+5UMGDaWw+uhn50zqaM9f3LNQPBTrlEQTWqDPHbU4h9ddy8E6qpawUJXeDWNYAXTXa0gLFixuh0/uzzO9GNqK2q8URT4poErGZUeofj+nGW9KZwVJsux1NFM/0ChoZZcbEdW5+vV6u5x3XvLKf89ym1wYPRGhcE2UnDIoNWd6DEcDa7597puoiPhxx1n4BXEB4CblpXobOnmZRusd4o2H6IB5PKiQMeOQUV32zmVf3EhmXwK2k5icYFi43tTJjOLtBIqFQnRHCd4HbseQFQly6x0GiIxpis21b4ZIsMjD43x4J5kEdZEnNJmqbcFw0R9JdNPMjxl1ES1o9URphv7gr7TeGqXntoUTwP5UxNwzgBHw+HY7k9SjCK6P8jc/HnYEd X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5722 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: AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: ea7c64b1-2132-464a-042a-08d8c120e220 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: U1p38p9Jv0WohASrlrHi1lrhAERM0u/JDKbdgUqVwMtRryxCc8wpNZwc+x8mdFeJJ09y+uVyh4igqpsHUqXaEtXQW/dfm+6yfhmvE6tQCD2hG//IxJnlh4rutDQdHM+0u/pBhgWBso8BG4C+c89j7trMkPmNKD7pThsugew7hCE8DNsjLemEm5hoDRRSk2dp2704cKXpcwvyRdOTNjB8KbMEBbPbB87MHVMsLjhF7hE+pUJ1/JJ6gigbwVfp2HLk7GsR3Jk+bGEXuNLi+fZK3T9dTBg630gF1wogWpf6xt4rr0DNFsoXwJHr8GbR1uZ7NvBB6ozMb5mI1YQWO3ZdLXbi1BQXx34tab+EutgyOWM7lBcnTS6LjHLu/711NJrmCUM3KudcjCQrWExWjurysmRVnkoAMFwb7Ve2JBy4YuNGUowwWmdLyVRtgogR3Y4oi+dsh48AiAsFCn/n4A4lmqSbB3Z29vqJFcjzTYJ8sG4oV4Loqnuvsk45j0WydV6R2v0cEcppXvkZgCTa1DsLPZWOFIdB1LmbBab3cTySKEhbgNSKsdAZRCd4/6A3yelkIA/FILSISlUY8eflmpEPIA== 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; SFS:(4636009)(136003)(346002)(376002)(396003)(39860400002)(46966006)(36756003)(6666004)(69590400011)(478600001)(956004)(336012)(82740400003)(47076005)(316002)(5660300002)(186003)(8936002)(6512007)(356005)(16526019)(26005)(2616005)(83380400001)(86362001)(6916009)(44832011)(81166007)(82310400003)(70206006)(2906002)(6486002)(70586007)(6506007)(8676002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2021 11:03:52.1919 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 584f7a8d-2fcc-42b9-ccb5-08d8c120e675 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: AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3490 X-Spam-Status: No, score=-14.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_SHORT, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, 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: <https://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: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Szabolcs Nagy <szabolcs.nagy@arm.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
aarch64: fix string tests [BZ #26818]
|
|
Commit Message
Szabolcs Nagy
Jan. 25, 2021, 11:03 a.m. UTC
The hwcap value is now in linux 5.10 and in glibc bits/hwcap.h, so use that definition. Move the definition to init-arch.h so all ifunc selectors can use it and expose an "mte" shorthand for mte enabled runtime. For now we allow user code to enable tag checks and use PROT_MTE mappings without libc involvment, this is not guaranteed ABI, but can be useful for testing and debugging with MTE. --- sysdeps/aarch64/multiarch/init-arch.h | 11 ++++++++++- sysdeps/aarch64/multiarch/strlen.c | 11 +---------- 2 files changed, 11 insertions(+), 11 deletions(-)
Comments
On 25/01/2021 08:03, Szabolcs Nagy via Libc-alpha wrote: > The hwcap value is now in linux 5.10 and in glibc bits/hwcap.h, so use > that definition. > > Move the definition to init-arch.h so all ifunc selectors can use it > and expose an "mte" shorthand for mte enabled runtime. > > For now we allow user code to enable tag checks and use PROT_MTE > mappings without libc involvment, this is not guaranteed ABI, but > can be useful for testing and debugging with MTE. > --- > sysdeps/aarch64/multiarch/init-arch.h | 11 ++++++++++- > sysdeps/aarch64/multiarch/strlen.c | 11 +---------- > 2 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/sysdeps/aarch64/multiarch/init-arch.h b/sysdeps/aarch64/multiarch/init-arch.h > index bf8264b561..fce260d168 100644 > --- a/sysdeps/aarch64/multiarch/init-arch.h > +++ b/sysdeps/aarch64/multiarch/init-arch.h > @@ -17,9 +17,18 @@ > <https://www.gnu.org/licenses/>. */ > > #include <ldsodefs.h> > +#include <sys/auxv.h> > + > +/* Make glibc MTE-safe on a system that supports MTE in case user code > + enables tag checks independently of the mte_status of glibc. There > + is currently no ABI contract for enabling tag checks in user code, > + but this can be useful for debugging with MTE. */ > +#define MTE_ENABLED() (GLRO(dl_hwcap2) & HWCAP2_MTE) > > #define INIT_ARCH() \ > uint64_t __attribute__((unused)) midr = \ > GLRO(dl_aarch64_cpu_features).midr_el1; \ > unsigned __attribute__((unused)) zva_size = \ > - GLRO(dl_aarch64_cpu_features).zva_size; > + GLRO(dl_aarch64_cpu_features).zva_size; \ > + bool __attribute__((unused)) mte = \ > + MTE_ENABLED (); Why not use mte_state and thus also enable MTE selection for the case of tunables force enable it for USE_MTAG support? > diff --git a/sysdeps/aarch64/multiarch/strlen.c b/sysdeps/aarch64/multiarch/strlen.c > index f3c018aab4..8f38de69b5 100644 > --- a/sysdeps/aarch64/multiarch/strlen.c > +++ b/sysdeps/aarch64/multiarch/strlen.c > @@ -26,21 +26,12 @@ > # include <string.h> > # include <init-arch.h> > > -/* This should check HWCAP2_MTE when it is available: current > - linux kernel does not expose it, but its value is reserved. > - This is needed to make glibc MTE-safe on future systems in > - case user code enables MTE. The ABI contract for enabling > - MTE is not yet specified, but it can be useful for at least > - debugging which does not need a contract. */ > -#define FUTURE_HWCAP2_MTE (1 << 18) > -#define MTE_ENABLED() (GLRO(dl_hwcap2) & FUTURE_HWCAP2_MTE) > - > extern __typeof (__redirect_strlen) __strlen; > > extern __typeof (__redirect_strlen) __strlen_mte attribute_hidden; > extern __typeof (__redirect_strlen) __strlen_asimd attribute_hidden; > > -libc_ifunc (__strlen, (MTE_ENABLED () ? __strlen_mte : __strlen_asimd)); > +libc_ifunc (__strlen, (mte ? __strlen_mte : __strlen_asimd)); > > # undef strlen > strong_alias (__strlen, strlen); >
The 01/25/2021 10:08, Adhemerval Zanella wrote: > On 25/01/2021 08:03, Szabolcs Nagy via Libc-alpha wrote: > > The hwcap value is now in linux 5.10 and in glibc bits/hwcap.h, so use > > that definition. > > > > Move the definition to init-arch.h so all ifunc selectors can use it > > and expose an "mte" shorthand for mte enabled runtime. > > > > For now we allow user code to enable tag checks and use PROT_MTE > > mappings without libc involvment, this is not guaranteed ABI, but > > can be useful for testing and debugging with MTE. > > --- > > sysdeps/aarch64/multiarch/init-arch.h | 11 ++++++++++- > > sysdeps/aarch64/multiarch/strlen.c | 11 +---------- > > 2 files changed, 11 insertions(+), 11 deletions(-) > > > > diff --git a/sysdeps/aarch64/multiarch/init-arch.h b/sysdeps/aarch64/multiarch/init-arch.h > > index bf8264b561..fce260d168 100644 > > --- a/sysdeps/aarch64/multiarch/init-arch.h > > +++ b/sysdeps/aarch64/multiarch/init-arch.h > > @@ -17,9 +17,18 @@ > > <https://www.gnu.org/licenses/>. */ > > > > #include <ldsodefs.h> > > +#include <sys/auxv.h> > > + > > +/* Make glibc MTE-safe on a system that supports MTE in case user code > > + enables tag checks independently of the mte_status of glibc. There > > + is currently no ABI contract for enabling tag checks in user code, > > + but this can be useful for debugging with MTE. */ > > +#define MTE_ENABLED() (GLRO(dl_hwcap2) & HWCAP2_MTE) > > > > #define INIT_ARCH() \ > > uint64_t __attribute__((unused)) midr = \ > > GLRO(dl_aarch64_cpu_features).midr_el1; \ > > unsigned __attribute__((unused)) zva_size = \ > > - GLRO(dl_aarch64_cpu_features).zva_size; > > + GLRO(dl_aarch64_cpu_features).zva_size; \ > > + bool __attribute__((unused)) mte = \ > > + MTE_ENABLED (); > > Why not use mte_state and thus also enable MTE selection for the case > of tunables force enable it for USE_MTAG support? that's what the comment is meant to explain. mte is enabled via a prctl, in principle user code can do that (e.g. i have test code that does that as well as ld_preloaded malloc implementation, this only works if glibc is mte safe independently of whether glibc has heap tagging or not. no ABI contract means that we don't guarantee that glibc will be mte safe because we don't know yet how this will be used, the plan is to have some form of opt-in/out mechanism eventually to request particular mte state, but for now i want glibc to be mte safe on any mte system)
On 25/01/2021 10:42, Szabolcs Nagy wrote: > The 01/25/2021 10:08, Adhemerval Zanella wrote: >> On 25/01/2021 08:03, Szabolcs Nagy via Libc-alpha wrote: >>> The hwcap value is now in linux 5.10 and in glibc bits/hwcap.h, so use >>> that definition. >>> >>> Move the definition to init-arch.h so all ifunc selectors can use it >>> and expose an "mte" shorthand for mte enabled runtime. >>> >>> For now we allow user code to enable tag checks and use PROT_MTE >>> mappings without libc involvment, this is not guaranteed ABI, but >>> can be useful for testing and debugging with MTE. >>> --- >>> sysdeps/aarch64/multiarch/init-arch.h | 11 ++++++++++- >>> sysdeps/aarch64/multiarch/strlen.c | 11 +---------- >>> 2 files changed, 11 insertions(+), 11 deletions(-) >>> >>> diff --git a/sysdeps/aarch64/multiarch/init-arch.h b/sysdeps/aarch64/multiarch/init-arch.h >>> index bf8264b561..fce260d168 100644 >>> --- a/sysdeps/aarch64/multiarch/init-arch.h >>> +++ b/sysdeps/aarch64/multiarch/init-arch.h >>> @@ -17,9 +17,18 @@ >>> <https://www.gnu.org/licenses/>. */ >>> >>> #include <ldsodefs.h> >>> +#include <sys/auxv.h> >>> + >>> +/* Make glibc MTE-safe on a system that supports MTE in case user code >>> + enables tag checks independently of the mte_status of glibc. There >>> + is currently no ABI contract for enabling tag checks in user code, >>> + but this can be useful for debugging with MTE. */ >>> +#define MTE_ENABLED() (GLRO(dl_hwcap2) & HWCAP2_MTE) >>> >>> #define INIT_ARCH() \ >>> uint64_t __attribute__((unused)) midr = \ >>> GLRO(dl_aarch64_cpu_features).midr_el1; \ >>> unsigned __attribute__((unused)) zva_size = \ >>> - GLRO(dl_aarch64_cpu_features).zva_size; >>> + GLRO(dl_aarch64_cpu_features).zva_size; \ >>> + bool __attribute__((unused)) mte = \ >>> + MTE_ENABLED (); >> >> Why not use mte_state and thus also enable MTE selection for the case >> of tunables force enable it for USE_MTAG support? > > that's what the comment is meant to explain. > > mte is enabled via a prctl, in principle user code can do that > (e.g. i have test code that does that as well as ld_preloaded > malloc implementation, this only works if glibc is mte safe > independently of whether glibc has heap tagging or not. no ABI > contract means that we don't guarantee that glibc will be > mte safe because we don't know yet how this will be used, the > plan is to have some form of opt-in/out mechanism eventually > to request particular mte state, but for now i want glibc to > be mte safe on any mte system) > Ok, fair enough. The patch looks ok for 2.33.
diff --git a/sysdeps/aarch64/multiarch/init-arch.h b/sysdeps/aarch64/multiarch/init-arch.h index bf8264b561..fce260d168 100644 --- a/sysdeps/aarch64/multiarch/init-arch.h +++ b/sysdeps/aarch64/multiarch/init-arch.h @@ -17,9 +17,18 @@ <https://www.gnu.org/licenses/>. */ #include <ldsodefs.h> +#include <sys/auxv.h> + +/* Make glibc MTE-safe on a system that supports MTE in case user code + enables tag checks independently of the mte_status of glibc. There + is currently no ABI contract for enabling tag checks in user code, + but this can be useful for debugging with MTE. */ +#define MTE_ENABLED() (GLRO(dl_hwcap2) & HWCAP2_MTE) #define INIT_ARCH() \ uint64_t __attribute__((unused)) midr = \ GLRO(dl_aarch64_cpu_features).midr_el1; \ unsigned __attribute__((unused)) zva_size = \ - GLRO(dl_aarch64_cpu_features).zva_size; + GLRO(dl_aarch64_cpu_features).zva_size; \ + bool __attribute__((unused)) mte = \ + MTE_ENABLED (); diff --git a/sysdeps/aarch64/multiarch/strlen.c b/sysdeps/aarch64/multiarch/strlen.c index f3c018aab4..8f38de69b5 100644 --- a/sysdeps/aarch64/multiarch/strlen.c +++ b/sysdeps/aarch64/multiarch/strlen.c @@ -26,21 +26,12 @@ # include <string.h> # include <init-arch.h> -/* This should check HWCAP2_MTE when it is available: current - linux kernel does not expose it, but its value is reserved. - This is needed to make glibc MTE-safe on future systems in - case user code enables MTE. The ABI contract for enabling - MTE is not yet specified, but it can be useful for at least - debugging which does not need a contract. */ -#define FUTURE_HWCAP2_MTE (1 << 18) -#define MTE_ENABLED() (GLRO(dl_hwcap2) & FUTURE_HWCAP2_MTE) - extern __typeof (__redirect_strlen) __strlen; extern __typeof (__redirect_strlen) __strlen_mte attribute_hidden; extern __typeof (__redirect_strlen) __strlen_asimd attribute_hidden; -libc_ifunc (__strlen, (MTE_ENABLED () ? __strlen_mte : __strlen_asimd)); +libc_ifunc (__strlen, (mte ? __strlen_mte : __strlen_asimd)); # undef strlen strong_alias (__strlen, strlen);