From: Chris Kennelly <ckennelly@google.com>
To: libc-coord@lists.openwall.com
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"carlos@redhat.com" <carlos@redhat.com>,
libc-alpha <libc-alpha@sourceware.org>,
szabolcs.nagy@arm.com
Subject: Re: [libc-coord] Re: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size
Date: Fri, 16 Sep 2022 11:41:39 -0400 [thread overview]
Message-ID: <CAEE+ybkXCYoX73ksO0yutpc+4QZ_RuKnLxquVymzwj01d0=x-g@mail.gmail.com> (raw)
In-Reply-To: <87y1uj49t4.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]
On Fri, Sep 16, 2022 at 11:29 AM Florian Weimer <fw@deneb.enyo.de> 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
next prev parent reply other threads:[~2022-09-16 15:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 14:36 Mathieu Desnoyers
2022-09-16 14:44 ` Mathieu Desnoyers
2022-09-16 15:29 ` Florian Weimer
2022-09-16 15:41 ` Chris Kennelly [this message]
2022-09-16 21:32 ` [libc-coord] " Florian Weimer
2022-09-17 11:51 ` Mathieu Desnoyers
2022-09-17 14:45 ` Florian Weimer
2022-09-17 15:25 ` Mathieu Desnoyers
2022-09-20 11:51 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEE+ybkXCYoX73ksO0yutpc+4QZ_RuKnLxquVymzwj01d0=x-g@mail.gmail.com' \
--to=ckennelly@google.com \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-coord@lists.openwall.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=szabolcs.nagy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).