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 dr
> >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.
>
>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 traditi
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 b
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. Especia
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 yo
>> 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 p
/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
|> ru
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
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
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 attacks
>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_HO
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 NO_MORE_LOCAL_DOS_HOLE
13 matches
Mail list logo
