From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by sourceware.org (Postfix) with ESMTPS id CB84A3851C12 for ; Tue, 14 Jul 2020 13:33:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CB84A3851C12 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=christian.brauner@ubuntu.com Received: from ip5f5af08c.dynamic.kabel-deutschland.de ([95.90.240.140] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jvL4C-0004ze-Og; Tue, 14 Jul 2020 13:33:52 +0000 Date: Tue, 14 Jul 2020 15:33:52 +0200 From: Christian Brauner To: Florian Weimer Cc: Mathieu Desnoyers , libc-alpha , Joseph Myers Subject: Re: [RFC PATCH glibc] Linux: Use fixed rseq_len value for rseq registration Message-ID: <20200714133352.ykv6qg6brzqlrc26@wittgenstein> References: <20200713193434.30440-1-mathieu.desnoyers@efficios.com> <87zh82bhsl.fsf@oldenburg2.str.redhat.com> <2077401180.11408.1594729873506.JavaMail.zimbra@efficios.com> <87zh826x9s.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87zh826x9s.fsf@oldenburg2.str.redhat.com> X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_ABUSEAT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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: Tue, 14 Jul 2020 13:33:58 -0000 On Tue, Jul 14, 2020 at 03:28:47PM +0200, Florian Weimer via Libc-alpha wrote: > * Mathieu Desnoyers: > > > ----- On Jul 14, 2020, at 4:51 AM, Florian Weimer fweimer@redhat.com wrote: > > > >> * Mathieu Desnoyers: > >> > >>> + /* The rseq_len parameter does not allow extending struct rseq. Fix its > >>> + value to 32 as expected by the Linux kernel. */ > >>> + ret = INTERNAL_SYSCALL_CALL (rseq, &__rseq_abi, 32, 0, RSEQ_SIG); > >> > >> If the layout of struct rseq can change in the kernel headers, than far > >> more significant changes are needed. glibc cannot change its ABI > >> depending on the version of the kernel headers it is compiled against. > > > > What I have in mind for struct rseq is that the current structure layout > > is guaranteed as a "minimum" requirement. It can then be extended by the > > kernel UAPI in a backward compatible way: if user-space provides enough > > room for extension, and the kernel supports the additional features, then > > user-space can use those additional features. > > > > Adding extra room in the __rseq_abi can be done though: > > > > - Upgrading glibc with knowledge of the extra layout, > > - Preloading an interposition library which defines __rseq_abi with the > > extended layout, > > - Defining __rseq_abi with extended layout in the application binary. > > > > What I suspect is your concern here is that two glibc-2.32 builds against > > different versions of kernel headers could lead to different __rseq_abi > > size, which is unexpected. > > Indeed. > > > Would using the internal struct rseq all the time in glibc (rather than > > uapi linux/rseq.h) resolve your concern ? This way, glibc could integrate > > extended layouts on version bump (e.g. 2.33). > > It works reliably as long as glibc only ever uses the minimum rseq size. > And since glibc monopolizes the rseq registration, applications cannot > register a larger area. So there is no way to make use of any future > kernel extensions. But when you bump ABI in glibc you can switch to a new rseq size, no? Christian