Subject: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.stanford.edu)
Date: Tue Nov 18 2003 - 01:47:30 EET
> > > i'd be interested to hear from fernando about this kind of thing. many
> > > 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.
> + 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
> 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
This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 01:49:19 EET