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.
> and whatever you do, the moment the user loads a user-defined plugin
It does not depend on having a list of trusted applications.
> or am i missing something fundamental here? in which case please
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 :-):
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
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.
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).
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...)
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
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
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...
> btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you
Linux-audio-dev mailing list