linux-kernel - Re: [patch V3 02/12] rseq: Add fields and constants for time slice extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lhu8qgm7wkt.fsf@oldenburg.str.redhat.com>
Date: Mon, 03 Nov 2025 20:19:46 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,  LKML
 <linux-kernel@...r.kernel.org>,  Peter Zijlstra <peterz@...radead.org>,
  "Paul E. McKenney" <paulmck@...nel.org>,  Boqun Feng
 <boqun.feng@...il.com>,  Jonathan Corbet <corbet@....net>,  Prakash
 Sangappa <prakash.sangappa@...cle.com>,  Madadi Vineeth Reddy
 <vineethr@...ux.ibm.com>,  K Prateek Nayak <kprateek.nayak@....com>,
  Steven Rostedt <rostedt@...dmis.org>,  Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>,  Arnd Bergmann <arnd@...db.de>,
  linux-arch@...r.kernel.org,  "carlos@...hat.com" <carlos@...hat.com>,
  Dmitry Vyukov <dvyukov@...gle.com>,  Marco Elver <elver@...gle.com>,
  Peter Oskolkov <posk@...k.io>
Subject: Re: [patch V3 02/12] rseq: Add fields and constants for time slice
 extension

* Mathieu Desnoyers:

> On 2025-10-31 16:58, Thomas Gleixner wrote:
>> On Fri, Oct 31 2025 at 15:31, Mathieu Desnoyers wrote:
>>> On 2025-10-29 09:22, Thomas Gleixner wrote:
>>> [...]
>>>> +
>>>> +The thread has to enable the functionality via prctl(2)::
>>>> +
>>>> +    prctl(PR_RSEQ_SLICE_EXTENSION, PR_RSEQ_SLICE_EXTENSION_SET,
>>>> +          PR_RSEQ_SLICE_EXT_ENABLE, 0, 0);
>>>
>>> Enabling specifically for each thread requires hooking into thread
>>> creation, and is not a good fit for enabling this from executable or
>>> library constructor function.
>> Where is the problem? It's not rocket science to handle that in user
>> space.
>
> Overhead at thread creation is a metric that is closely followed
> by glibc developers. If we want a fine-grained per-thread control over
> the slice extension mechanism, it would be good if we can think of a way
> to allow userspace to enable it through either clone3 or rseq so
> we don't add another round-trip to the kernel at thread creation.
> This could be done either as an addition to this prctl, or as a
> replacement if we don't want to add two ways to do the same thing.

I think this is a bit exaggerated. 8-)

I'm more concerned about this: If it's a separate system call like the
quoted prctl, we'll likely have cases where the program launches and
this feature automatically gets enabled for the main thread by glibc.
Then the application installs a seccomp filter that doesn't allow the
prctl, and calls pthread_create.  At this point we either end up with a
partially enabled feature (depending on which thread the code runs), or
we have to fail the pthread_create call.  Neither option is great.

So something enabled by rseq flags seems better to me.  Maybe
default-enable and disable with a non-zero flag if backwards
compatibility is sufficient?  As far I understand it, this series has
performance improvements that more than offset the slice extension cost?

Thanks,
Florian