Subject: Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes
From: rm (async_AT_cc.gatech.edu)
Date: Fri Aug 30 2002 - 05:52:32 EEST
On Thu, Aug 29, 2002 at 05:45:09PM -0400, Paul Davis wrote:
> the bug-in-the-code case is handled using the monitor thread approach,
> since we know that the monitored threads run at lower priority.
assuming the bug isn't in the monitor thread itself (or which affects
it).
you can argue that you can make the monitor small enough that it's
unlikely, and fork it to protect its address space, and that the user
shouldn't do 'killall blah' and accidently kill the monitor before the
rest, but the all around more robust solution is a scheduler change.
> 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.
you are probably correct and even if i fix it at all; i doubt it will be
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.
what i would like to do is allow SCHED_USER_FIFO to be a non-root
thing, since you won't have the potential to take down the machine
(although you can certainly arbitrarily affect performance). the win i
think would be not giving the program any capabilities in the first
place.
rob
----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async_AT_cc.gatech.edu
This archive was generated by hypermail 2b28 : Fri Aug 30 2002 - 06:06:53 EEST