linuxaudio.org

> > > i'd be interested to hear from fernando about this kind of thing. many

quoted text
> > > of us on LAD work on what are to all effects and purposes single user

> > > machines. i'd like to hear how policies like 1-4 above, or others,

> > > appear in the context of an academic "shared resource" environment.

> >

> > ["academic" is probably irrelevant, a commercial studio should see the

> > advantages of the security model if educated]

> >

> > As far as I understand these are the current options:

> >

> > a) capabilities

> > b) simple sysctl patch to the kernel (like the one that Kjetil posted)

> > c) security module, with possible additional control through sysctl

>

> What about:

> d) redefining sched_setscheduler using LD_PRELOAD with running rt_monitor

Yes, sorry, I forgot about this one... (you posted it no long ago). 
> + No change in kernel.

quoted text
> + No change in application code. (Like capabilities - do not check uid,

>   but it can fake uids too!)

> + Can use whatever kernel provides

> + Only requires the rt_monitor to be started by root - can be done by init

Not a problem so far (but I don't like to use LD_PRELOAD at all, just a

personal preference). 
> + Protects the system from overuse (and lockups) due to bugs in code.
Very good. 
> - Can not provide mlockall since it has no pid parameter - the monitor

quoted text
>   can't do it for another process. (I would say that it is unlikely that pages

>   used in a tight audio loop would be thrown out - big buffers might...

>   Add additional page reads?)

Well, I'd say this is the showstopper. We really need this. "Unlikely"

is not enough. Eventually memory will run out and the wrong page will

fault and we get a click. We have to be able to lock memory......
BUT, I think a userspace daemon that starts at boot time and protects

against lockups (rt_monitor) would be a very good thing to have. 
-- Fernando