linux-kernel - Re: [PATCH V7 02/11] sched: Indicate if thread got rescheduled

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: <871ppd7ojh.ffs@tglx>
Date: Thu, 14 Aug 2025 20:20:50 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Prakash Sangappa <prakash.sangappa@...cle.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "peterz@...radead.org" <peterz@...radead.org>, "rostedt@...dmis.org"
 <rostedt@...dmis.org>, "mathieu.desnoyers@...icios.com"
 <mathieu.desnoyers@...icios.com>, "bigeasy@...utronix.de"
 <bigeasy@...utronix.de>, "kprateek.nayak@....com"
 <kprateek.nayak@....com>, "vineethr@...ux.ibm.com"
 <vineethr@...ux.ibm.com>
Subject: Re: [PATCH V7 02/11] sched: Indicate if thread got rescheduled

On Thu, Aug 14 2025 at 07:18, Prakash Sangappa wrote:
>> On Aug 11, 2025, at 2:45 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> Is it ok to fail the sched_yield(2) syscall? The man page says
> sched_yield(2) always succeeds(returns 0).

I used it because it's simple. In practice we need a new syscall w/o
side effects.

> Also, is it necessary to force kill the process here with SIGSEGV, if
> some other system call was made?

Yes, because we do not trust user space and any violation of the
contract has consequences. Any kernel facility which interacts in such a
way with user space has to be defensive by design. Assuming that user
space is neither stupid nor malicious is naive at best and has been a
source of big gaping holes forever.

> Ideally it would be expected that the process should not be making any
> system call while in the critical section and is using time slice
> extension, other then sched_yield(2) to relinquish the cpu. However an
> application process could have a signal handler that gets invoked
> while in the critical section which can potentially be making some
> system call that is not sched_yield(2).

The timeslice extension is canceled when a signal is pending, so nothing
bad happens. The kernel already revoked it similar to how rseq aborts
the critical section on signal delivery.

If it doesn't work with the POC, that may be. With the stuff I'm
polishing now it works because I tested it :)

Thanks

        tglx