Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

On Tue, 2009-06-23 at 10:44 +0200, Jörn Nettingsmeier wrote: As far as I can tell any executable can get rt rights. It does not depend on having a list of trusted applications. 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