linux-kernel - Re: [patch 00/12] rseq: Implement time slice extension mechanism

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 for Android: free password hash cracker in your pocket

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

Message-ID: <827c26cd-3924-4556-a36d-da42b23a9a17@efficios.com>
Date: Mon, 22 Sep 2025 10:09:44 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Prakash Sangappa <prakash.sangappa@...cle.com>,
 Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zilstra
 <peterz@...radead.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>,
 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" <linux-arch@...r.kernel.org>,
 Florian Weimer <fweimer@...hat.com>, "carlos@...hat.com"
 <carlos@...hat.com>,
 "libc-coord@...ts.openwall.com" <libc-coord@...ts.openwall.com>
Subject: Re: [patch 00/12] rseq: Implement time slice extension mechanism

On 2025-09-19 13:30, Prakash Sangappa wrote:
> 
> 
>> On Sep 13, 2025, at 6:02 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> On Fri, Sep 12 2025 at 15:26, Mathieu Desnoyers wrote:
>>> On 2025-09-12 12:31, Thomas Gleixner wrote:
>>>>> 2) Slice requests are a good fit for locking. Locking typically
>>>>>      has nesting ability.
>>>>>
>>>>>      We should consider making the slice request ABI a 8-bit
>>>>>      or 16-bit nesting counter to allow nesting of its users.
>>>>
>>>> Making request a counter requires to keep request set when the
>>>> extension is granted. So the states would be:
>>>>
>>>>       request    granted
>>>>       0          0               Neutral
>>>>> 0         0               Requested
>>>>> =0        1               Granted
>>>
>>
>> Second thoughts on this.
>>
[...]
> 
>>
>> If user space wants nesting, then it can do so on its own without
>> creating an ill defined and fragile kernel/user ABI. We created enough
>> of them in the past and all of them resulted in long term headaches.
> 
> Guess user space should be able to handle nesting, possibly without the need of a counter?
> 
> AFAICS can’t the nested request, to extend the slice, be handled by checking
> if both ‘REQUEST’ & ‘GRANTED’ bits are zero?  If so,  attempt to request
> slice extension.  Otherwise If either REQUEST or GRANTED bit Is set, then a slice
> extension has been already requested or granted.

I think you are onto something here. If we want independent pieces of
software (e.g. libc and application) to allow nesting of time slice
extension requests, without having to deal with a counter and the
inevitable unbalance bugs (leak and underflow), we could require
userspace to check the value of the request and granted flags. If both
are zero, then it can set the request.

Then when userspace exits its critical section, it needs to remember
whether it has set a request or not, so it does not clear a request
too early if the request was set by an outer context. This requires
handing over additional state (one bit) from "lock" to "unlock" though.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com