On Sunday 01 September 2002 18.50, Paul Davis wrote:
[I wrote:]
The only thing the sound servers need to be able to handle
RT audio are:
* one of the RT scheduling methods.
* locked memory. (Not protected at the moment - hard limits?)
This can be archived with a wrapper that drops ALL
I noticed that I was not on the list...
But I have now read the archives.
Kernel changes are not workable - at least not short testm!
It will take ages until that change is available on most computers.
(But if it is the only solution then it is...)
Local DOS/security exploits has traditionally
The only thing the sound servers need to be able to handle
RT audio are:
* one of the RT scheduling methods.
* locked memory. (Not protected at the moment - hard limits?)
This can be archived with a wrapper that drops ALL other priorities
before running the real application.
this is,
I noticed that I was not on the list...
But I have now read the archives.
Kernel changes are not workable - at least not short testm!
It will take ages until that change is available on most computers.
(But if it is the only solution then it is...)
Local DOS/security exploits has traditionally
On Thu, Aug 29, 2002 at 09:12:07PM +0200, Stefan Westerfeld wrote:
I am very interested in that. In all the discussions we had
about the RT issue in aRts, things usually came to the point:
basically, it is a kernel bug, that as soon as you use RT prio,
your system becomes unstable. Especially
Hi!
On Wed, Aug 28, 2002 at 12:47:41PM -0400, rm wrote:
which is still an issue. relying on the courtesy of user programs is
probably not optimal (as i'm sure you're all well aware).
[...]
i've been working on a kernel patch that will allow a program to use
the entire cpu up to
Hi!
On Wed, Aug 28, 2002 at 10:15:54AM -0400, Paul Davis wrote:
a side note: JACK, when run in RT mode, launches its own maximal
priority thread to perform exactly this function. all other RT threads
run at lower priorities. i believe that it is not possible to use JACK
to perform DOS
/wrote Stefan Westerfeld [EMAIL PROTECTED] [Thu, 29 Aug 2002 21:16:59
+0200]
| Hi!
|
|On Wed, Aug 28, 2002 at 10:15:54AM -0400, Paul Davis wrote:
| a side note: JACK, when run in RT mode, launches its own maximal
| priority thread to perform exactly this function. all other RT threads
| run at
a side note: JACK, when run in RT mode, launches its own maximal
priority thread to perform exactly this function. all other RT threads
run at lower priorities. i believe that it is not possible to use JACK
to perform DOS attacks like this unless the client modifies its
scheduling priority
On Thu, Aug 29, 2002 at 05:45:09PM -0400, Paul Davis wrote:
the bug-in-the-code case is handled using the monitor thread approach,
since we know that the monitored threads run at lower priority.
assuming the bug isn't in the monitor thread itself (or which affects
it).
you can argue that you
Hi,
One problem with audio systems that
a) runs as RT processes
b) allows user loaded plugins
Is that it is very simple to make a DOS (Denial of service) attack.
This has resulted in that the feature to run arts in RT mode has been
disabled... see artswrapper.c, search for
One problem with audio systems that
a) runs as RT processes
b) allows user loaded plugins
Is that it is very simple to make a DOS (Denial of service) attack.
This has resulted in that the feature to run arts in RT mode has been
disabled... see artswrapper.c, search for NO_MORE_LOCAL_DOS_HOLE
I
12 matches
Mail list logo
