From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 9883C3851C12 for ; Tue, 14 Jul 2020 14:04:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9883C3851C12 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 594752BEB4C; Tue, 14 Jul 2020 10:04:05 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0q54z4DO8jYJ; Tue, 14 Jul 2020 10:04:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 267772BECBD; Tue, 14 Jul 2020 10:04:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 267772BECBD X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zt8BgYIsu9ZB; Tue, 14 Jul 2020 10:04:05 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 193EA2BE77D; Tue, 14 Jul 2020 10:04:05 -0400 (EDT) Date: Tue, 14 Jul 2020 10:04:05 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: Christian Brauner , libc-alpha , Joseph Myers Message-ID: <1165023597.11584.1594735445006.JavaMail.zimbra@efficios.com> In-Reply-To: <87v9iq6w25.fsf@oldenburg2.str.redhat.com> 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> <20200714133352.ykv6qg6brzqlrc26@wittgenstein> <87v9iq6w25.fsf@oldenburg2.str.redhat.com> Subject: Re: [RFC PATCH glibc] Linux: Use fixed rseq_len value for rseq registration MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3955 (ZimbraWebClient - FF78 (Linux)/8.8.15_GA_3953) Thread-Topic: Linux: Use fixed rseq_len value for rseq registration Thread-Index: VpdONG91a7J9yC8fvhr/oBI00Yl9dg== X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Tue, 14 Jul 2020 14:04:06 -0000 ----- On Jul 14, 2020, at 9:54 AM, Florian Weimer fweimer@redhat.com wrote: > * Christian Brauner: > >>> 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? > > We are expected to support interposers with their own definition > __rseq_abi, which could be smaller. In this scenario, the interposers would have to follow the UAPI rules: The size should at least cover the original struct rseq fields, up to and including the flags field. This just means glibc would internally abide by the same rules as the other users if it want to use an extended rseq structure, and not expect to be the only possible library defining the __rseq_abi symbol. If glibc wants to use the extension feature, it would have to validate that the RSEQ_TLS_FLAG_SIZE flag is set in the __rseq_abi.flags, and then validate that __rseq_abi.kernel_size covers the feature it needs before accessing the feature field. It would have to do something similar anyway to make sure the kernel supports those extensions. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com