From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 8DCEC3895FF7 for ; Fri, 16 Sep 2022 15:41:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8DCEC3895FF7 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-wr1-x434.google.com with SMTP id cc5so26794327wrb.6 for ; Fri, 16 Sep 2022 08:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Uv4IyUiH//E579ewfvf7oGFM8qimIg/GUBsy+hxCp2w=; b=CUr+O2/I9Ilp1b9JiZ50yPtcpUoJk5imSSMBRWbWas4Oao0mMHzy6HJ6yW8apizkG7 ABsTvLNfPPIe+f3hQEI6IYnWSBpXjUfj2ybCsnfQqTDl4XlXSitIgXnRxLjD23psfGPx rtd/a9ArNa6ANFyGwoppvbKtFDvCKI953kBZZK7VKSHnJOtIiiLEVMj//AJ/kBWyvx7Y idMrfV+WkrkuZYEKFJG511SjQ8O7kxH/j2P4Rdxa7WVXlYiiyxrFXifl81gM8iTbecbl zIyE1g1Xmef4kyPO6r9g4YY3rxCHJZ62lcha1+KWoKvwVUpnmTyxoY132j1NXgkrMneh CpsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Uv4IyUiH//E579ewfvf7oGFM8qimIg/GUBsy+hxCp2w=; b=J6qaIUrIN+mMJJ0axcb6QBOmF3SMULH7RalQ1REwbu1eEp4KAb/tCIXF3I1Sj0iyx1 7x31OnyPBYkzWSl4LHDxOY1IHQeQy3xoXk8LzJ+EKnKjn9KRZ9ATsCAVe6DmNnL+9HWi EZZ+nx0SZghQfBjVdVZpVmjW2F86wJeLpgVESGGUuWvsx7vwcVWHPyvN+6BoHXp1EAI/ NAGFM9+LgUJvpNsjm4TN57VBkzQG2LkretYPq+Vd3reREw9tyUFCmkKKJXgSOAV2KPLa A9BzG+du4zDQZVA/iTXJ4Z/I667gTzYPOLfv5BYj5eN6QesZucNa0oS8GCOTGctPk1IJ zyqw== X-Gm-Message-State: ACrzQf2Yafc/Pfem8S++L+00PypCoObFrQVDbMXc3R8OOiWMsl78zCj6 CHuWAerJBQcTea9abcRBzucWR1Hw1T6UzAqqNNymQg== X-Google-Smtp-Source: AMsMyM5D7c9cMPIfHceutnvvsZFheuInb3DsqaErpXc6gBJBwuse21Rtv3NwYJdZOXE01B8gLv3wC5wwCDUV2H2Tfmo= X-Received: by 2002:adf:f2cf:0:b0:228:646f:216f with SMTP id d15-20020adff2cf000000b00228646f216fmr3298366wrp.199.1663342912206; Fri, 16 Sep 2022 08:41:52 -0700 (PDT) MIME-Version: 1.0 References: <87y1uj49t4.fsf@mid.deneb.enyo.de> In-Reply-To: <87y1uj49t4.fsf@mid.deneb.enyo.de> From: Chris Kennelly Date: Fri, 16 Sep 2022 11:41:39 -0400 Message-ID: Subject: Re: [libc-coord] Re: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size To: libc-coord@lists.openwall.com Cc: Mathieu Desnoyers , "carlos@redhat.com" , libc-alpha , szabolcs.nagy@arm.com Content-Type: multipart/alternative; boundary="0000000000006cd95205e8cd33af" X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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: --0000000000006cd95205e8cd33af Content-Type: text/plain; charset="UTF-8" On Fri, Sep 16, 2022 at 11:29 AM Florian Weimer wrote: > * 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. > TCMalloc, which has an implementation of this, uses an offset to adjust which field it reads (cpu_id versus vcpu_id). > > > > 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. > IFUNC has significant performance overheads as well. For frequently used code (like memcpy), avoiding them has been an optimization for us ( https://research.google/pubs/pub50338/) even if it leaves some nominal microbenchmark performance on the table. > > > 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. > If a user program updates to a new kernel before glibc does, would it be able to easily take advantage of it? Chris --0000000000006cd95205e8cd33af--