On Tue, 2009-06-23 at 10:44 +0200, Jörn Nettingsmeier wrote:
> Lennart Poettering wrote:
> > On Mon, 22.06.09 23:46, Jörn Nettingsmeier (nettings@folkwang-hochschule.de) wrote:
> >
> >>> What is so difficult to understand that rtkit is not intended to be a
> >>> solution for hardcore rt users?
> >>>
> >>> rtkit is not for you!
> >>>
> >>> Let me repeat this:
> >>>
> >>> RTKIT IS NOT FOR YOU!
> >> this is getting childish. my claim is: if you give rt to a user, you
> >> enable him to fuck the machine up. that's a law of nature. you can do
> >> all kinds of very clever things and try to have a very fast watchdog,
> >> but it doesn't prevent abuse.
> >
> > That is simply bogus.
> >
> > With the reset-on-fork kernel patch in place you can perfectly
> > supervise an RT process and it cannot evade you. If the system becomes
> > unresponsive (which is all that we try to detect), then we can
> > demote/kill everyone who's misbehaving.
>
> you don't need to fork in order to do wreak havoc.
> how do you make sure you know which processes (i.e. which executables)
> deserve rt rights? hash them?
As far as I can tell any executable can get rt rights.
> and whatever you do, the moment the user loads a user-defined plugin
> from a user-controlled location (such as a privately installed LADSPA
> plugin), you are utterly hosed.
It does not depend on having a list of trusted applications.
> or am i missing something fundamental here? in which case please
> enlighten me.
I __think__ it goes like this - if this is wrong any gurus out there
please correct me (and I'm also writing this to help myself understand
the issues - it does not mean that I agree with everything :-):
<in the kernel present>
You need SCHED_FIFO/SCHED_RR to get your audio processing thread to be
scheduled in time, but any program can wedge the machine by going into a
tight loop without yielding the processor (deliberately or through a
bug).
So RLIMIT_RTTIME is introduced to limit the time a process/user/whatever
(I don't know the details of how this works) can hog the cpu. So that
the machine now does not wedge permanently, and at least other processes
have a chance to run so that you/the system can kill the buggy program.
<in the kernel future>
A buggy or malicious program that is given rt scheduling can still fork
processes very fast and DOS the computer anyway. So another kernel
feature is added to prevent _that_ by making a process drop rt
scheduling when it forks if the right option is selected (this is the
new feature that will be part of 2.6.31).
<but>
Existing userland mechanisms that authorize non-root use of SCHED_FIFO|
SCHED_RR don't/can't force use of RLIMIT_RTTIME or the new SCHED_OTHER
on fork flag. So __something__ is needed on userland...
(AFAIK nobody has written something addressing this before rtkit, I may
be wrong about this...)
<in userland>
An additional way of granting rt access is needed that will at least
give programs access to rt and at the same time force them to use the
flags that make it less likely a user process can hang the machine. I
think that is part of the goal of rtkit. It does that by honoring
requests from any program that wants to go rt only if the request has an
appropriate value for RLIMIT_RTTIME. And then rtkit grants the right but
it additionally forces the SCHED_OTHER on fork flag on the process
requesting rt.
Still not enough of course
[[not enough for a general purpose desktop that is _reasonably safe_
from hanging from either bugs in programs or malicious attacks]]
But a process could fork processes that actually request rt and then DOS
the computer in the same way as before...
But then, as you have a single point of entry that intercepts requests
to have rt scheduling you can deliberately throttle down buggy or
malicious programs that would still hang the machine. This is
necessarily heuristics driven (how many times per second, how many
requests total, etc, etc). As it is heuristics then a sufficiently
clever program might be able to get around that, I don't know. As a last
resort a watchdog system is there to help.
I think that's about it (at least what I can understand).
As this is userland there is no silver bullet that will kill the problem
for good. At least not one I can think of. And I can't think of anything
in kernel land either that will get rid of the basic problem (but I have
not thought very hard about either, I try and very soon it starts to
hurt :-)
I guess there would be many other ways of doing this in userland, but
that would need somebody to go ahead and write them!
In a desktop world, as a plain user, I would like to have a system where
I can play sound without excessive latency and without clicks and be
reasonably safe from buggy or malicious programs being able to crash my
computer, and without having to configure things by hand to get that.
That would seem to require both kernel and userland support. I would
also like to be able to use whatever system is in place to be able to
get Jack to work as designed, without whatever software is in place
interfering with it. In the end both regular desktop apps and jack would
work out of the box...
-- Fernando
> btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you
> define a maximum amount of time that can be spent in rt mode, per user?
> or per process? or per group?
> if per user, how is scheduling fairness accomplished? does the first rt
> process grab as much as it wants, and then another rt process gets
> demoted by rtkit because the user used up their rt slice?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 20:15:04 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 20:15:04 EEST