<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<style>
blockquote { margin-bottom: 7pt; margin-top: 7pt; }
</style>
</head>
<body style="color: rgb(0, 0, 102); background-color: rgb(210, 255,
255);" bgcolor="#d2ffff">
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.<br>
<br>
J.E.B.<br>
<br>
<br>
On 12/31/2010 01:32 PM, Fernando Lopez-Lezcano wrote:
<blockquote id="mid_4D1E2FDF_2090602_localhost"
cite="mid:4D1E2FDF.2090602@localhost" type="cite">
<pre wrap="">On 12/31/2010 08:23 AM, Janina Sajka wrote:
</pre>
<blockquote id="StationeryCiteGenerated_2" type="cite">
<pre wrap="">Fernando Lopez-Lezcano writes:
</pre>
<blockquote id="StationeryCiteGenerated_3" type="cite">
<pre wrap="">... ... 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).
</pre>
</blockquote>
<pre wrap="">
I've never understood those purported risks. Seems to me there's far
more risk of inoperative systems than of actual privacy violations.
</pre>
</blockquote>
<pre wrap="">
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]
</pre>
<blockquote id="StationeryCiteGenerated_4" type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:PlanetCCRMA@ccrma.stanford.edu">PlanetCCRMA@ccrma.stanford.edu</a>
<a class="moz-txt-link-freetext" href="http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma">http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma</a>
</pre>
</blockquote>
<br>
</body>
</html>