linux-kernel - Re: High Resolution Timer DOS

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]

Message-ID: <4634C2F0.8050101@free.fr>
Date:	Sun, 29 Apr 2007 18:08:16 +0200
From:	matthieu castet <castet.matthieu@...e.fr>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Lee Revell <rlrevell@...-job.com>, tglx@...utronix.de,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: High Resolution Timer DOS

Ingo Molnar wrote:
> * Lee Revell <rlrevell@...-job.com> wrote:
> 
>>> Well, it is not really a DoS. The rescheduling of the process is 
>>> limited by the scheduler and the available CPU time (depending on 
>>> the number of runnable tasks in the system).
>> Shouldn't an unprivileged process be rate limited somehow to avoid 
>> flooding the machine with interrupts?  We restrict nonroot users from 
>> setting the RTC interrupt rate higher than 64Hz for a similar reason 
>> (granted, this limit dates back to the 486 days and should probably be 
>> increased to 1024 Hz).
> 
> No. An interrupt in this case is really just 'CPU time used up', and an 
> unprivileged process can take up as much CPU time as the scheduler 
> allows. So it's _not_ a DoS, and neither is any other unprivileged 
> infinit loop (or high-rate context-switching task) a DoS.
Ok, may be DOS was not the correct term, but with the 2.6.21 hrt there 
is a great difference between an infinite loop and the high-rate 
context-switching task (you can try attached programs).
With the first I the system is still responsive, with the latter it 
isn't (new process take lot's of time to get created, other process are 
very slow).
If it is "just 'CPU time used up'", why I see a such difference between 
the 2 cases ?

Maybe the current scheduler failed to handle correctly this case ?


Matthieu

View attachment "infinite_loop.c" of type "text/x-csrc" (134 bytes)

View attachment "small_sleep.c" of type "text/x-csrc" (40 bytes)