[PlanetCCRMA] FC14

[Fernando Lopez-Lezcano]

On 12/31/2010 08:23 AM, Janina Sajka wrote:
> Fernando Lopez-Lezcano writes:
>> ... ... most probably you
>> have to add your user to the proper group to be able to get realtime
>> scheduling enabled. Hmmm, maybe I should add an extra package in Planet
>> CCRMA to enable all users (although some will complain about the
>> security risks of doing so).
>
> I've never understood those purported risks. Seems to me there's far
> more risk of inoperative systems than of actual privacy violations.

The risks (quite low IMHO) are related to the way realtime scheduling 
works. When a process aquires privileges to start executing in the 
realtime scheduling ring (SCHED_FIFO or SCHED_RR instead of the regular 
SCHED_OTHER), it owns the processor it is running on until it decides to 
relinquish it voluntarily. Normal SCHED_OTHER processes can get 
preempted by the scheduler even if they are not done with their work.

If the rt process does not yield the processor then that processor can't 
do anything else. It is, in a way, hung. If that happens on all 
processors the whole computer is "hung" (technically it is not, but it 
will be only running the rt processes and nothing else - I would not 
call that a "crash" although the user does not see the difference).

So, a program with a bug (or an intentional bad design) can hang the 
computer. This can lead to "denial of service" attacks where your 
computer stops responding and has to be reset due to a program that 
intentionally seeks to hang it.

If everybody can access this feature it opens the possibility of bugs 
(or intentional bad design) in any program in the computer (including 
all daemons) hanging the computer. If only a group of accounts has 
access to this feature then the risk is less.

That is the risk. As usual it is a tradeoff between convenience and 
security.

[BTW and to be more precise, the current realtime kernel does not allow, 
on purpose, for SCHED_FIFO processes to actually use up _all_ of a 
processor time, if I remember correctly usage is limited to 95% of the 
processor time so that you can recover from errant rt processes - that 
is also never mentioned in the context of security and DOS attacks]

> And, it also strikes me that there's some kind of heavy prejudice
> underlying it all. Everyone takes for granted the notion that a user
> who sits down at a computer will interact with a monitor, yet there's all
> kinds of  falderal about who gets to hear audio from it. Am I alone in
> seeing a disconnect here?

No, you are not. I agree. In particular the warnings in the "Fedora 
Musician's Guide" against using realtime patched kernels are blown out 
of proportion, IMO. The paragraphs about security and stability fail to 
convey adequately the tradeoffs of using an rt patched kernel (ie: they 
concentrate on what can go wrong as opposed to the very big performance 
gains for professional audio you get out of it).

In particular they dedicate a whole paragraph warning users that CCRMA 
is small compared to Fedora (which is true) but they conveniently ignore 
the fact that the realtime patch is _not_ created at CCRMA, but is 
written, developed and debugged by kernel gurus (some employed full time 
by RedHat - a big enough company I presume - and other companies just to 
do realtime kernel development!). The guide also mentions that you 
should not run realtime processes in server machines because of the 
risks. Ha ha ha, very funny considering that the realtime patch is being 
sold by RedHat in their MRG product line for use in __servers__[*] and 
is being developed because of that reason (not because it benefits audio 
performance in workstations!). It is also right to say that if you buy 
that product you will get support from Redhat you can't get from CCRMA 
and a lot more quality control of the product. Doh!

So, yes, there are more risks. But it is necessary to be exposed to 
those risks if you intend to do low latency audio processing with any 
degree of confidence. As usual YMMV depending on your needs.

-- Fernando

[*] I understand it is being used for doing very fast transaction 
processing in the financial industry (ie: creating money out of nothing 
by gaming the stock markets a bit faster than others can).