Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes
From: Paul Davis (pbd_AT_op.net)
Date: Fri Aug 30 2002 - 00:45:09 EEST


>> a side note: JACK, when run in RT mode, launches its own maximal
>> priority thread to perform exactly this function. all other RT threads
>> run at lower priorities. i believe that it is not possible to use JACK
>> to perform DOS attacks like this unless the client modifies its
>> scheduling priority itself.
>
>which is still an issue. relying on the courtesy of user programs is
>probably not optimal (as i'm sure you're all well aware).
>
>this issue bugs me especially because people go on and on about the
>stability of *nix, and yet here we have an easy way in which a user
>(albeit root) program can bring the system to its knees. all it takes
>is one small bug in a reasonably complex program--not exactly
>uncommon.

i just don't agree with this.

there are two issues:

1) a bug in the code that causes a DOS to occur
2) an intentional DOS attack

the bug-in-the-code case is handled using the monitor thread approach,
since we know that the monitored threads run at lower priority.

the intentional DOS attack can't be handled in any reasonable way to
start with, since the DOS attack can shutdown the monitoring system
without your suggested fix:

>i've been working on a kernel patch that will allow a program to use
>the entire cpu up to some percentage of cycles which are reserved.
>(this is a common approach in RT literature). preliminary testing
>seems to indicate its workable, but a number of issues need to be
>cleared up (>1 cpu, what happens if more than one process wants fifo
>scheduling, etc). i will probably add a new scheduling policy,
>something like SCHED_USER_FIFO.

this is not a "small patch", believe me. it might end up being not
much code, but i am certain that to be done correctly, it will have to
be very subtle and probably very elegant.

trying to stop an intentional attack that uses RT priority to launch a
DOS seems like a waste of time: the relevant process already has
either CAP_RESOURCE and/or root priviledge, and can do more or less
*anything* it wants already.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Aug 30 2002 - 00:54:23 EEST