From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00050.outbound.protection.outlook.com [40.107.0.50]) by sourceware.org (Postfix) with ESMTPS id CD87A385E444 for ; Thu, 24 Sep 2020 08:04:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CD87A385E444 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=BuVzX+loPYvIsq6YIoIfNKMtnvDg+R9ZBpfRL8yxFPQ=; b=PL581i43Q6typPqFI7163aLXSCeZ3yMyu6vmY7bx6oCOVRRkA0QPPTOVN5/OetJ2RW0Bk+eZ8BhOcl49uK0DaWFvP6IMGYOf/XhQYACSq7/hVY0vejllpWCs0GPyJtdJeOlZRF5P5AsrfnuFN9E4BPqUOIRrUMh4jOce8B8b89s= Received: from DB6PR07CA0161.eurprd07.prod.outlook.com (2603:10a6:6:43::15) by DB7PR08MB3387.eurprd08.prod.outlook.com (2603:10a6:10:45::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Thu, 24 Sep 2020 08:04:31 +0000 Received: from DB5EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:43:cafe::b0) by DB6PR07CA0161.outlook.office365.com (2603:10a6:6:43::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.14 via Frontend Transport; Thu, 24 Sep 2020 08:04:31 +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 DB5EUR03FT016.mail.protection.outlook.com (10.152.20.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Thu, 24 Sep 2020 08:04:31 +0000 Received: ("Tessian outbound 7a6fb63c1e64:v64"); Thu, 24 Sep 2020 08:04:30 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: becd3aa53f6035de X-CR-MTA-TID: 64aa7808 Received: from 834df5438945.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 83134CAF-3E47-47B0-A0BD-B6A219B946A2.1; Thu, 24 Sep 2020 08:04:09 +0000 Received: from EUR02-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 834df5438945.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 24 Sep 2020 08:04:09 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZaI64XW8YeJ9DVTtYq4mtUtmRUH6R3qr61mF5LRvKXBtZ+mwGRef+6I3fcliUkszS6R72gDL9xRgKIJ3lXwDdVakdf5p5LyZB6+/+loC6ALhnvksL1L/6+PRu3qzt0QFqLpA7cOQPiVdVwwuNoxyX7PJ1dr2kAzJEbSBQGZqCseTAG+TLbetbe5EtBLcFNapb9tUqH6MsBmyb6q4J7LyG03/QaFJr1ww8EQuahgyBL517EFRK/vGlT+tdak1khSkX/lzk9ZCH6ZiY1Ocvg7V7xXmqeT4T1MfOhCKLb9SIYUGB6tymj2TWwDP7HhRXX7axlWCBWeeJrpoRVC7HS3VTQ== 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=BuVzX+loPYvIsq6YIoIfNKMtnvDg+R9ZBpfRL8yxFPQ=; b=O2gju9TqnSgBZ3wS3vNKvwIGrtT5cEgG1ISH8AL9LExhgKyb3VxwDLVmXVBVWbU5y29Qot5GJO6IGunfPBGA5Ux/sGZgl7pihd1ScOluTM2ohFT/hYnVo2QyrrjbsMJ94aqd9aQriLkUBP6+IN22Sx2evH045JjVV1F4+o3QyEiSjPcaCjfUjgzSlP8E+I7EvRTbfwLz+EWStQt5CtX/82G1n1H+Ub+rz/KB0yBULoEJJlOB0o1qBZ1WVaO2vYcpzBFcYEFWW4OPqQDSFOFo7vVomw9qfqTNY3NOXl1JMW/02QU0fDOz7tIRmRuY7deRlUZZhpB4GtlVkVD+QVhCag== 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=BuVzX+loPYvIsq6YIoIfNKMtnvDg+R9ZBpfRL8yxFPQ=; b=PL581i43Q6typPqFI7163aLXSCeZ3yMyu6vmY7bx6oCOVRRkA0QPPTOVN5/OetJ2RW0Bk+eZ8BhOcl49uK0DaWFvP6IMGYOf/XhQYACSq7/hVY0vejllpWCs0GPyJtdJeOlZRF5P5AsrfnuFN9E4BPqUOIRrUMh4jOce8B8b89s= Authentication-Results-Original: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; Received: from PR3PR08MB5564.eurprd08.prod.outlook.com (2603:10a6:102:87::18) by PR3PR08MB5787.eurprd08.prod.outlook.com (2603:10a6:102:90::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Thu, 24 Sep 2020 08:04:08 +0000 Received: from PR3PR08MB5564.eurprd08.prod.outlook.com ([fe80::784a:eb50:9684:50fe]) by PR3PR08MB5564.eurprd08.prod.outlook.com ([fe80::784a:eb50:9684:50fe%7]) with mapi id 15.20.3412.022; Thu, 24 Sep 2020 08:04:08 +0000 Date: Thu, 24 Sep 2020 09:04:06 +0100 From: Szabolcs Nagy To: Ben Coyote Woodard Cc: Carlos O'Donell , libc-alpha@sourceware.org Subject: Re: [PATCH] Fix runtime linker auditing on aarch64 Message-ID: <20200924080405.GA20097@arm.com> References: <20200923011613.2243151-1-woodard@redhat.com> <6dd83348-3f97-fd42-2b7d-d482ab42aa77@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: LO2P265CA0047.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:61::35) To PR3PR08MB5564.eurprd08.prod.outlook.com (2603:10a6:102:87::18) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.54) by LO2P265CA0047.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:61::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Thu, 24 Sep 2020 08:04:07 +0000 X-Originating-IP: [217.140.106.54] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a5d8ad98-696d-48b0-d029-08d860607776 X-MS-TrafficTypeDiagnostic: PR3PR08MB5787:|DB7PR08MB3387: X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8882;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: TTyoz5I9eayGjVUAGL8JQ5TUsb/XR9OyeNsl8klyR60jeMefYHYg7oP+VQrSlmTNBFC0wqVi9k6bl5WxAGbqQHI8ole4v9EJq8RsuN3+gNLixao6wTzPVuasjqsL2Y0bw+gbuDTPqt2QtVj2RLBxqvQLwN95e6qJ4FMhmi6QuVxvSPtHVQn9Iaub4+ixeA7jwG7bcTBE8AtYhEb4YOgh8u/wWXPZkXOzLD4bOD9+/RlQx7IUDsrAy6JShl7FKI1Amg6erGNkzRMCsJD97+eDvmzQ8lU3M4Fr5pCC2/TPydhV7+fdt5GsDlQlqVBoCsL6cxDM8CbyYR/HOujOIEQk606Bc0P3EgCea8zhgzUuRa/tM4jaawkDtQtQVPXtz4glXaUJC6KstyhVVxu8Zj7D63cST78J+DbQcbhYb5GraB3x0O7Jqp6i05KYrOO3/omv5wzoLF2PZeme/E0xWznnuw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR08MB5564.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(346002)(366004)(376002)(136003)(66946007)(186003)(26005)(44832011)(16526019)(36756003)(316002)(8936002)(6916009)(66556008)(66476007)(2616005)(956004)(478600001)(4326008)(52116002)(966005)(33656002)(7696005)(8676002)(2906002)(83380400001)(86362001)(55016002)(8886007)(5660300002)(1076003)(53546011); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: opp+pPLo7XSt+QjiiFDluooOkDUqhwYOAEkXc4MpbiMeyOAV7K3u3E48Pyuw+Q867P7kPkSFrNXszQDuCs0XupUjxvXk9xUKLKX4/HJQobBzl2BWO08NC2CGH/Prdl/zQ1PRRnWzXY+IBCc5sJ09W9SnJKLmmjfI6V1P4DkXXuaRxDGLOhRX9UKsgvGM3YM8MHX5MOSHp/jZ4mm1cQC0KW6B3dikUI7UDa2jbzrRW0u3S3/OdlbwE6Ef2fJh7x/vVboVnR77reLWAP7Tbv5tmWqgoM/hAq8SZYl8IxN2EDvy9Ww6/IUYPsmZcJswJGOxzqP0bJy7S4m8mQaFt/If41glx3nUnnYpjHa2RSpIHwfoa8z9kFZ4cxMrj8LxaHrl//gEy+HrxRGKgPhVUvfHcLC0IkBCFu5bQj0XqFRNXjliNMTB4yB90qoJqgxGLtlMQYD4OlnaZRH0Y3zIthUO6RvDC8lddCdU5GNnc4hkqY/EVi/7/3XsMozq1fmDCGsnwip9qJnlr3MOySky9G3g6OLO9wFolJIEDF5dvWsZk8HYQmonh4MEcl7Do3TuWxjFrd+3LWE9VmF4lAOUfFgdcxHVFzUUa4n1nzIyw+uRxksQZqpK7+HCtgBgy79kpTUmOC1llb1euBdE7o5INdwdSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5787 Original-Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 714c7400-c8c6-437b-cfd1-08d86060699f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2CIGYAlwF2359O8gN300qAtUPRd6a49UJGiKEIG1W9thHgQhXOJz+nExSyJD0PoNyksaIgdWNHyQFUkrEhSvpdoSseY5OAHijdNqsKLFPNYsXNe4+AL40h06UmRLE10XnmxarOuOVrP+qweOdlXcDvAD2SIve4YtYD5SOumlOm4QEQI+8pXN8wu5cMrYoTehmcZpRv1CzZLJFX6anRdMvByLllBh2NbM5AzZEh5ObQjCqfm6XTQqjgQ1UP+XXx/t6noWgi4x6fpBnZv/UlmOk76ouYBe20cJy3DwtYREhkDe+HP8y4qeKgRXCG0eI5gV4FL/R56IVjbpJiCCbSvQ+3p2MyN0+KZaVFVOBoks0Ay9WkxHnck2xJ7cU6XaS1Qk24amB6CuH1Tbn4CxUN19aSGzFl1fpxwHqKSYUPfU21iGkEW8en+qOWt2maHANSLzAuMsRPTqbfn0QAqXi9ON8IqF0Bjq/BJeiaXKllujlik= 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)(396003)(39850400004)(346002)(136003)(376002)(46966005)(478600001)(8676002)(82740400003)(70206006)(4326008)(70586007)(336012)(8936002)(44832011)(956004)(36756003)(55016002)(7696005)(186003)(2616005)(16526019)(33656002)(53546011)(26005)(86362001)(6862004)(82310400003)(1076003)(5660300002)(316002)(47076004)(2906002)(83380400001)(966005)(8886007)(356005)(81166007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2020 08:04:31.0247 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a5d8ad98-696d-48b0-d029-08d860607776 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: DB5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3387 X-Spam-Status: No, score=-14.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_NUMSUBJECT, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 08:04:40 -0000 The 09/23/2020 20:14, Ben Coyote Woodard wrote: > > On 9/23/20 5:30 PM, Carlos O'Donell wrote: > > On 9/22/20 9:16 PM, Ben Woodard via Libc-alpha wrote: > > > The dynamic linker's auditing was not working on aarch64. See PR#26643 > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26643 > > > > > > There were two distinct problems: > > > * _dl_runtime_resolve was not preserving x8 the indirect result location > > > register. > > > * The NEON Q registers pushed onto the stack by _dl_runtime_resolve > > > were twice the size of D registers extracted from the stack frame by > > > _dl_runtime_profile. > > > > > > To fix this > > > * The La_aarch64_regs structure was expanded to include x8 and the full > > > sized NEON V registers that are required to be preserved by the ABI. > > > * _dl_runtime_profile needed to extract registers saved by > > > _dl_runtime_resolve and put them into the new correctly sized > > > La_aarch64_regs structure. > > > * The return value structure La_aarch64_retval also didn't have the correctly > > > sized NEON V registers. > > > > > > As a couple of additional cleanups > > > * The names of the NEON registers saved within the La_aarch64_regs and the > > > La_aarch_retval structures referred to the old D registers which were > > > doubles. Now the registers are quads and are called V for vector registers. > > > So the name of the field in the structure and the names of the offsets > > > within that structure were named to use the more modern names. > > > * The ABI specification says that r0-r7 + r8 the indirect result location > > > register as well as the NEON v0-v7 registers can be used to return values > > > from a function. Therefore, I addded those to the La_aarch64_retval > > > structure so that it also correctly matches the ABI. > > > > > > An additional problem not addressed by this patch is what to do about the > > > changes to the aarch64 ABI needed to support SVE. A discussion about what to > > > do about that was begun on libc-alpha here: > > > https://sourceware.org/pipermail/libc-alpha/2020-September/117797.html > > > --- > > > sysdeps/aarch64/bits/link.h | 17 ++++---- > > > sysdeps/aarch64/dl-link.sym | 4 +- > > > sysdeps/aarch64/dl-trampoline.S | 75 +++++++++++++++++++++------------ > > > 3 files changed, 59 insertions(+), 37 deletions(-) > > > > > > diff --git a/sysdeps/aarch64/bits/link.h b/sysdeps/aarch64/bits/link.h > > > index 0c54e6ea7b..2b43ace57c 100644 > > > --- a/sysdeps/aarch64/bits/link.h > > > +++ b/sysdeps/aarch64/bits/link.h > > > @@ -23,19 +23,20 @@ > > > /* Registers for entry into PLT on AArch64. */ > > > typedef struct La_aarch64_regs > > > { > > > - uint64_t lr_xreg[8]; > > > - uint64_t lr_dreg[8]; > > > - uint64_t lr_sp; > > > - uint64_t lr_lr; > > > + uint64_t lr_xreg[9]; > > > + __uint128_t lr_vreg[8]; > > > + uint64_t lr_sp; > > > + uint64_t lr_lr; > > This breaks ABI and does not address what to do about SVE. > > > > If you argue that LD_AUDIT was always broken for AArch64 then > > you get away with breaking ABI *once* and that one time you > > break it to fix the ABI should include all the currently known > > breakages that are out there. > > I agree with this and that was literally why I didn't submit this patch > until you encouraged me to submit it. > > LD_AUDIT has always broken for AArch64. I think that we are currently up to > four cases where it it wouldn't work: > - functions that used x8 for indirect parameter references > - long double parameters > - NEON registers for parameters > - NEON registers for return values > > Szabolcs did point out an interesting twist to the question which I think is > worth considering: > > Currently the SVE functions are not handled by the PLT/GOT subsystem and are > therefore unauditable due to them having a different linkage type. It will > take some additional code to make them auditable. This will also likely > require changes to compilers and binutils and likely additional kernel > support. it can be done with only changing glibc (but it may not be the best solution). however the problem is not just with sve calls: variant pcs is there for a reason, there are other call conventions (vector pcs using advanced simd and future/custom extensions and those are all handled by the same mechanism), so whatever hook we introduce has to deal with a more general problem. solutions i can see: 0) proposed patch: only solve auditing for base pcs. users who care about sve pcs will have to use a different solution. 1) audit entry always saves *all* registers and one extra bit (== is the symbol variant pcs) and then the user hook has to deal with that. this requires no toolchain changes, but potentially slows down the common case for auditing and the abi has to be versioned: new reg state needs libc update. (and auditing will require more stack space) 2) same, but with two separate audit hooks (dispatch can be in libc or linker generated), then the base pcs hook is fast and reliable and only the variant pcs hook needs complications. (dispatch in libc is ugly because the asm entry code has to inspect elf symbol table flags without clobbering registers) 3) introduce separate elf symbol table markings for sve, vector pcs etc and have separate hooks for them so user can deal with the different call conventions more easily. this needs more toolchain and elf abi work, and i think there are not enough symbol table bits for this (i.e. may require significant elf extension to make it work). > > He also says that there is no architecturally defined way to save or restore > these registers even though ARM did specify an ABI that included saving > them. He's much more of an expert on the ARM architecture than I am but I > have yet to convince myself that is true. but I'm just starting to tinker > with SVE assembly instructions (how does the kernel context swap?) sorry i was probably not clear: there is of course way to save and restore sve registers, but there is no *future proof* way, i.e. if new register state is introduced for whatever cpu extension then we will have to update code in glibc again. in principle there could be save/restore instructions that save all registers that are commonly required for a context switch in a defined format (which can be versioned and specified in the architecture) then the audit hooks would just directly expose that to the user. > > With all those things being true, even though there are currently SVE > enabled processors currently for sale, it seems like the full hardware > enablement of SVE including making functions auditable is a long way off. > This seems like it should allow time to implement the code necessary to > allow bumps of LAV_CURRENT on a per arch level. > > So a reasonable plan may be: > 1) fix the problems with aarch64 auditing now. We literally have tool > authors impacted by the broken audit interface now. > 2) add per arch LAV_CURRENT bumps to accommodate ABI changes > 3) do the backend work in the kernel, the compilers and binutils to make SVE > auditable > 4) then finally do the work needed wire up auditing of SVE functions > including potentially changing the ABI again and bumping LAV_CURRENT in > glibc. > > > > > I think we'll need feedback from Arm on this to get their input > > on the direction to take here. > > More than just feedback, I would personally love it if ARM actually did the > work of 2-4 as part of their enablement of ARMv8.4 or whichever minor > version of the v8 ISA makes SVE mandatory rather than an optional feature. (sve is currently optional in all arch versions.) i have no experience with auditing and expected that hooking base pcs function calls is enough. note that currently the tooling does not guarantee that all extern calls go via a PLT, so auditing cannot reliably hook all calls, which tells me it is enough to do it on a best effort basis. if users really want reliable audit PLT hooks, then that's even more work that goes beyond sve. this has to be justified for arm to care fixing it. > > Granted we always have LAV_CURRENT we can bump to change the > > interface, but that's a lot of code to write to handle that > > and it would require struct-copying to support a newer larger > > sized structure. > >