From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 746E93857C4C for ; Wed, 23 Sep 2020 12:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 746E93857C4C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-495-BVqpANc0MkqllupqoPOueg-1; Wed, 23 Sep 2020 08:56:57 -0400 X-MC-Unique: BVqpANc0MkqllupqoPOueg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 13B768ECE60; Wed, 23 Sep 2020 12:56:56 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-108.ams2.redhat.com [10.36.114.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5860D9CBA; Wed, 23 Sep 2020 12:56:55 +0000 (UTC) From: Florian Weimer To: Szabolcs Nagy Cc: Ben Woodard via Libc-alpha Subject: Re: [PATCH] Fix runtime linker auditing on aarch64 References: <20200923011613.2243151-1-woodard@redhat.com> <87d02cr8bp.fsf@oldenburg2.str.redhat.com> <20200923124848.GE16385@arm.com> Date: Wed, 23 Sep 2020 14:56:53 +0200 In-Reply-To: <20200923124848.GE16385@arm.com> (Szabolcs Nagy's message of "Wed, 23 Sep 2020 13:48:49 +0100") Message-ID: <87r1qsps6i.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Wed, 23 Sep 2020 12:57:00 -0000 * Szabolcs Nagy: > The 09/23/2020 14:22, Florian Weimer via Libc-alpha wrote: >> * Ben Woodard via Libc-alpha: >> >> > 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. >> >> Off-list, you said that the audit interface was completely broken on >> AArch64. But it seems to be working enough for sotruss. So I do wonder >> if we have to do a proper ABI transition here after all (bumping >> LAV_CURRENT and all the consequences of that). > > i think plt hooks currently don't work for functions > that take neon vector arguments because the save/restore > logic clobbers the top bits (but such extern calls are > not common since they need to use non-portable types) > > but i agree if it's not too intrusive to bump the audit > abi then we should do so and then the incompatibility > can be detected at least. The other question I had if we can do this once and make sure that the CPU state is represented in such a way that we can efficiently save and load it for later SVE support, so that we do not have to create two copies (the architecture state and the audit representation), or bump LAV_CURRENT for a new CPU. (I'm aware that AArch64 would be pioneering audit support for vector calling conventions.) Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill