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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <82BDDCE0-1611-4A03-A46C-62EE844A8E70@oracle.com>
Date: Tue, 23 Sep 2025 01:01:59 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC: Thomas Gleixner <tglx@...utronix.de>, 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 Sep 22, 2025, at 7:09 AM, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
> 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.

Yes that is correct. Additional state will be required to track if slice extension
was requested in that context. 

-Prakash

> 
> Thoughts ?
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com