[PlanetCCRMA] RT and VirtualBox

[Jonathan E. Brickman]

Anyone know if there is hope for VirtualBox under an RT kernel?  In VBox
2.0 it was blazingly fast, but it has been crashing kernels on me since
VBox 3.

J.E.B.


On 12/31/2010 01:32 PM, Fernando Lopez-Lezcano wrote:
> 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).
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20101231/4d941afc/attachment.html