From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD3E6C3DA7D for ; Thu, 5 Jan 2023 16:19:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234923AbjAEQTs (ORCPT ); Thu, 5 Jan 2023 11:19:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234918AbjAEQTq (ORCPT ); Thu, 5 Jan 2023 11:19:46 -0500 Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5825652756; Thu, 5 Jan 2023 08:19:43 -0800 (PST) Received: from [172.17.203.2] (port=58125 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pDSxr-009StN-7D; Thu, 05 Jan 2023 16:19:35 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1pDSxq-000GBT-P4; Thu, 05 Jan 2023 17:19:34 +0100 From: Florian Weimer To: Mathieu Desnoyers Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Thomas Gleixner , "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, Christian Brauner , David.Laight@ACULAB.COM, carlos@redhat.com, Peter Oskolkov , Alexander Mikhalitsyn , Chris Kennelly Subject: Re: [PATCH 05/30] selftests/rseq: Use ELF auxiliary vector for extensible rseq References: <20221122203932.231377-1-mathieu.desnoyers@efficios.com> <20221122203932.231377-6-mathieu.desnoyers@efficios.com> <87a62yun6l.fsf@mid.deneb.enyo.de> Date: Thu, 05 Jan 2023 17:19:34 +0100 In-Reply-To: (Mathieu Desnoyers's message of "Wed, 4 Jan 2023 14:51:22 -0500") Message-ID: <87tu15rm21.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mathieu Desnoyers: > 2- Now about applications (and libc) use of rseq fields: > > Using both __rseq_size (from libc) and the result of > getauxval(AT_RSEQ_FEATURE_SIZE), a rseq user can figure which rseq > fields can indeed be used. The important part is how > get_rseq_feature_size() is called in the rseq selftests: > > > rseq_feature_size = get_rseq_feature_size(); > if (rseq_feature_size > rseq_size) > rseq_feature_size = rseq_size; > > which basically sets rseq_feature_size to the feature size exposed > by the kernel, except if libc's __rseq_size is smaller than the > feature size exposed by the kernel, in which case it will truncate > the rseq_feature_size to __rseq_size. Ahh, this happens to work because we pass 32 today from glibc, and there is nothing left to do in glibc to enable these new fields. If true, that really argues in favor of this approach. >> Maybe we should just skip the existing padding and use it only for >> some vaguely kernel-internal purpose (say through a vDSO helper), so >> that it is less of an issue how to communicate the presence of these >> fields to userspace. > > The fact that libc's __rseq_size is included the original struct > rseq padding is unfortunate, but I really see this as a purely > userspace ABI concern, which should not dictate the layout of the > kernel ABI exposed to user-space, especially given that all the > information required to allow rseq users to know which fields can be > used is readily available by combining the value loaded from > __rseq_size and the result of getauxval(AT_RSEQ_FEATURE_SIZE). But we must pass size 32 to the kernel today, otherwise rseq registration fails. It's a kernel-mandated value, not something that's purely a userspace concern.