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: <1177798389.7646.320.camel@localhost.localdomain>
Date:	Sun, 29 Apr 2007 00:13:09 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	matthieu castet <castet.matthieu@...e.fr>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: High Resolution Timer DOS

On Sat, 2007-04-28 at 23:53 +0200, matthieu castet wrote:
> Hi,
> 
> some programs need to do some short of busyloop. It was often 
> implemented as :
> 
> while (1) {
> 	if (can_do_stuff) {
> 		do_stuff();
> 	}
> 	else
> 		//sleep a very short of time
> 		usleep(1);
> }
> 
> usleep(1) or equivalent where used instead of sched_yield, because of 
> some priority issue. IIRC doing sched_yield, make the process appears 
> like an interactive process, so it has better priority and get call more 
> often.
> 
> But now if high res timer are enabled, these programs while cause 
> something like a DOS : the context switch per second will be bigger than 
> 500 000 and the cpu usage will be very high.

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).

>>From the spec:

Implementations may place limitations on the granularity of timer
values. For each interval timer, if the requested timer value requires a
finer granularity than the implementation supports, the actual timer
value shall be rounded up to the next supported value.

The !HIGHRES enabled kernel rounds this up to the HZ interval, the
HIGHRES enabled kernel grants the request for this short sleep.

The program gets what it asked for: a stupid sleep value.

	tglx

-
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/