lkml.org 
[lkml]   [1996]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Dumping /dev/zero to the console

I was a bit curious, so I did my own little test with this approach.
First, I found just running a whole bunch of "cat /dev/zero &" processes
is a great way to consume some CPU, but on my system it does not make the
system unusable or even terribly slow. "cat /dev/zero > /dev/console" has
the same effect as "cat /dev/zero" in whatever window I choose; perhaps
some windows which interpret nulls would be more vulnerable. Something
like
while :; do
echo
done

...is at least as bad. And that does not require a device to take input
from. Better yet, run 15 Netscapes!

Here's what the system looked like as I was running about 15 of these "cat
/dev/zero" processes. I did not start them all at once, either, hence the
disparities in priority and run time:

11:51pm up 3 days, 20:41, 8 users, load average: 16.65, 9.28, 4.41
72 processes: 68 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 25.8% user, 74.4% system, 0.0% nice, 0.2% idle
Mem: 14592K av, 14320K used, 272K free, 11112K shrd, 828K buff
Swap: 66528K av, 11684K used, 54844K free 4004K cached

PID USER PRI NI SIZE RES SHRD STAT %CPU %MEM TIME COMMAND
250 root 19 0 6232 1836 620 R 17.7 12.5 9:16 X :0
1401 niemi 20 0 9660 28 20 R 16.4 0.1 82H netscape
5428 root 5 0 2352 804 592 S 8.0 5.5 0:17 xterm
12377 niemi 4 0 764 240 184 D 4.1 1.6 0:13 cat /dev/zero
12385 niemi 4 0 764 240 184 D 4.1 1.6 0:10 cat /dev/zero
12376 niemi 4 0 764 224 168 D 3.9 1.5 0:14 cat /dev/zero
12392 niemi 4 0 764 228 172 D 3.9 1.5 0:09 cat /dev/zero
12379 niemi 4 0 764 240 184 D 3.7 1.6 0:13 cat /dev/zero
12380 niemi 4 0 764 240 184 D 3.7 1.6 0:13 cat /dev/zero
12383 niemi 4 0 764 240 184 D 3.7 1.6 0:10 cat /dev/zero
12387 niemi 4 0 764 240 184 D 3.5 1.6 0:09 cat /dev/zero
12388 niemi 3 0 764 240 184 D 3.5 1.6 0:09 cat /dev/zero
12390 niemi 3 0 764 240 184 D 3.5 1.6 0:09 cat /dev/zero
12378 niemi 3 0 764 240 184 D 3.3 1.6 0:13 cat /dev/zero
12386 niemi 4 0 764 240 184 D 3.3 1.6 0:09 cat /dev/zero
12391 niemi 4 0 764 240 184 D 3.3 1.6 0:09 cat /dev/zero
12384 niemi 4 0 764 240 184 D 3.1 1.6 0:09 cat /dev/zero
12389 niemi 3 0 764 240 184 D 3.1 1.6 0:10 cat /dev/zero
12375 niemi 3 0 876 468 320 R 2.3 3.2 0:05 top
12413 niemi 2 0 780 296 224 S 1.7 2.0 0:00 du /opt/src
1 root 0 0 776 20 20 S 0.0 0.1 0:03 init

Certainly the difference is noticeable, but I have been on much slower
systems which had no denial-of-service attacks running! The du /opt/src
process is an attempt to do some intensive real work, and it went just
fine. Admittedly, this is a pretty happy system, but cat /dev/zero is not
a terribly fearsome attack.

DCN

--------------------------------------------------

Ted Ts'o wrote:
From: lilo <TaRDiS@mail.utexas.edu>
Date: Sun, 21 Jul 1996 10:44:25 -0500 (CDT)

/dev/zero can be used for a variety of things. It contains no
sensitive
information (only binary zeroes :) and hence conceptually its access
should
not be restricted.

There are a lot of other denial-of-service attacks that users can
employ on
Linux. If there's any interest in reducing the effectiveness of
denial-of-service attacks (and improving Linux's handling of
resource-exhaustion situations) that might be a better approach than
simply
denying access to this device.

It's also not hard thwart fix this sort of denial-of-service attack;
just put in code to periodically check to see if need_resched is true,
and call schedule() to yield control of the process. You should also
check to see if a signal has been posted, and exit appropriately:

if (need_resched)
schedule();
if (current->signal & ~current->blocked)
return (bytes_written ? bytes_written : -ERESTARTSYS);

Any kernel system call which might be long-lived should definitely be
doing something like this, just for robustness's sake.

- Ted

David
Niemi@wauug.erols.com 703-810-5538 Reston, Virginia, USA
------ Money talks, but it is wrong half of the time. -----



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.028 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site