linux-kernel - once again SCHED

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>] [day] [month] [year] [list]

Date:	Fri, 29 Dec 2006 16:57:16 +0100
From:	spam@...enjodel.de
To:	linux-kernel@...r.kernel.org
Subject: once again SCHED_IDLE

Hi all,

I know there have been some discussions regarding an IDLE scheduler
priority, but by now this is about 4 years ago without any major
results besides the new SCHED_BATCH priority, which works quite
differently from the original idle priority. (Or did I miss something?)
So I wanted to restart this discussion and emphasize that such a feature
is worthwhile, because - just for example - there are so many projects
out there, where you can donate your cpu time to something good. We
certainly do not want Linux to become known as the OS, whose users
don't dare to support "cure for cancer/aids" project, because such
clients won't release the cpu when its owner needs it himself, would
you? ;-) Just overdoing, but I think you see my point. As I recently
read, FreeBSD also has it. So why not Linux?
The only point I got from the early discussions are your concerns about
"priority inversion". Probably there is no simple solution to it. But
let's have closer look at the problem: If I got that right, there is an
unimportant Process A which has a lock on something (call it R) that
important Process B needs from time to time. We assume, that A sometimes
releases its lock on R, so that B can run. But now evil Process C comes
into play. C maliciously blocks a resource (the CPU) that A would need,
before A can release its lock. Now A and B are blocked, but this can
happen with any other resource (not only CPU) as well! Or did I miss
something? Even if A is scheduled regularly (nice +19), a malicious
process C could request so much CPU, that A needs more than 20 times the
time until it can release R. Isn't that similarly bad?
So would SCHED_IDLE really be that bad? No, I don't think so. C could
block R right away, you wouldn't even need A for this.
Additionally, idle priority is not the root cause of the priority
inversion problem. B could get the cpu, but it does not want it, because
of A, because of C.
Trading off the benefits and risks of an IDLE priority I would rather
vote for it. And when security matters: You always have the choice of
not running any process as an idle process. You simply don't have to.
Don't run processes (as idle) that could lock vital resources or live
with the consequences. I think "priority inversion" is not a problem of
a normal user's every day life, but not being able to spend cpu time on
something "nice to have", because it would always eat up its share of
cpu even if the system is under full load, is quite a bit annoying.

Please let me know about your opinions on this topic or if I missed
something.

Looking forward to further discussion,
Christian

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/