linux-kernel - Re: sched: horrible way to detect whether a task has been preempted

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]

Date:	Thu, 7 Apr 2016 23:37:19 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Jessica Yu <jeyu@...hat.com>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Miroslav Benes <mbenes@...e.cz>, linux-kernel@...r.kernel.org,
	live-patching@...r.kernel.org, Vojtech Pavlik <vojtech@...e.com>
Subject: Re: sched: horrible way to detect whether a task has been
 preempted

On Thu, 7 Apr 2016, Jessica Yu wrote:

> Been sort of rattling my head over the scheduler code :-) Just following 
> the calls in and out of __schedule() it doesn't look like there is a 
> current flag/mechanism to tell whether or not a task has been 
> preempted..

Performing the complete stack unwind just to determine whether task has 
been preempted non-volutarily is a slight overkill indeed :/

> Is there any reason why you didn't just create a new task flag, 
> something like TIF_PREEMPTED_IRQ, which would be set once 
> preempt_schedule_irq() is entered and unset after __schedule() returns 
> (for that task)? This would roughly correspond to setting the task flag 
> when the frame for preempt_schedule_irq() is pushed and unsetting it 
> just before the frame preempt_schedule_irq() is popped for that task. 
> This seems simpler than walking through all the frames just to see if 
> in_preempt_schedule_irq() had been called. Would that work?

Alternatively, without eating up a TIF_ space, it'd be possible to push a 
magic contents on top of the stack in preempt_schedule_irq() (and pop it 
once we are returning from there), and if such magic value is detected, we 
just don't bother and claim unreliability.

That has advantages of both aproaches combined, i.e. it's relatively 
low-cost in terms of performance penalty, and it's reliable (in a sense 
that you don't have false positives).

The small disadvantage is that you can (very rarely, depending on the 
chosen magic) have false negatives. That probably doesn't hurt too much, 
given the high inprobability and non-lethal consequences.

How does that sound?

-- 
Jiri Kosina
SUSE Labs