From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 2D182381DC35 for ; Fri, 16 Sep 2022 15:29:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D182381DC35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=57897 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 1oZDHT-001jLC-L2; Fri, 16 Sep 2022 15:29:27 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1oZDHT-000GuP-BH; Fri, 16 Sep 2022 17:29:27 +0200 From: Florian Weimer To: Mathieu Desnoyers Cc: "carlos@redhat.com" , libc-alpha , szabolcs.nagy@arm.com, libc-coord@lists.openwall.com Subject: Re: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size References: Date: Fri, 16 Sep 2022 17:29:27 +0200 In-Reply-To: (Mathieu Desnoyers's message of "Fri, 16 Sep 2022 16:36:46 +0200") Message-ID: <87y1uj49t4.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Mathieu Desnoyers: > /* > * C) Check only rseq flags. 32 features at most. One mask and one > * comparison. > */ > > void fC(void) > { > if (likely(__rseq_flags & __RSEQ_FLAG_FEATURE_VM_VCPU_ID)) { > /* Use rseq with vcpu_id. */ > asm volatile ("ud2\n\t"); > } else { > /* Fallback. */ > asm volatile ("int3\n\t"); > } I think it has to be this because we cannot lower __rseq_flags below 32 now, not if rseq is active. If you don't find a better use fot the remaining 32 bits of padding, maybe put the PID or TID there, so that we can create a system-call-less version of getpid/gettid. So the flag would just say that the padding is now completely used. Going forward, we can use the size increasing above 32 as a support indicator. > I can think of 4 approaches that applications will use to detect > availability of their specific rseq feature for each rseq critical > section: > > 1) Dynamically check whether the feature is implemented at runtime > with conditional branches. Those using this approach will probably > not want to have the overhead of the two comparisons in approach (A) > above. Applications and libraries should probably use their own copy > of the glibc symbols for speed purposes. > > 2) Implement the entire function as IFUNC and select whether a rseq or > non-rseq implementation should be used at C startup. The tradeoff > here is code size vs speed, and using IFUNC for things like malloc > may add additional constraints on the startup order. > > 3) Code rewrite (dynamic code patching) between rseq and non-rseq code. > This may be frowned upon in the security area and may not always be > possible depending on the context. > > 3) JIT compilation of specialized rseq vs non-rseq code. Not generally > available in C. > > I suspect that glibc may rely on approaches 1+2 depending on the > situation, and many applications may use approach (1) for simplicity > reasons. If the kernel does not currently overwrite the padding, glibc can do its own per-thread initialization there to support its malloc implementation (because the padding is undefined today from an application perspective). That is, we would initialize these invisible vCPU IDs the same way we assign arenas today. That would cover this specific malloc use case only, of course.