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 > > (netti...@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
