Re: [LAD] Realtime threads and security

On 02/25/2011 04:29 PM, Paul Davis wrote:
> On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <list@email-addr-hidden> wrote:
>
>> But let's take JACK for example. It handles setting up realtime scheduling
>> transparently when one creates a jack client. There isn't any extra step
>> necessary. As a supposition, could you imagine that ulatencyd integrates tightly
>> into JACK to provide fine-grained per-client realtime permissions?
>
> ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
> with what JACK does. ulatencyd appearst to me concerned entirely with
> desktop latency and the notion that the "current app" (as represented
> by some form of ongoing user interaction) should be the most
> responsive. this has nothing whatsoever to do with the realtime
> scheduling that JACK is concerned with.

I was only supposing the integration of ulatencyd with JACK to illustrate my
points. I was not saying that it's necessary a good idea.

> specifically, what JACK does is per-thread, and more significantly its either:
>
> * for threads that it creates (inside libjack) AND knows that they
> need to be RT
> * for threads that the client specifically asks to be RT
>
> you can't do this stuff on a per-process level.

Let me rephrase my idea.

Let's imagine that JACK runs as a privilege user, which in addition of having
realtime privileges, is also able to assign other processes to given cgroups and
adjust their sched_rt_runtime_us and sched_rt_period_us dynamically. Which is
the kind of thing which ulatencyd does IIUC.

But let's forget about ulatencyd for a second.

Let's now consider that clients runs as user(s) which do not have realtime
privileges by default, but that it's JACK which grant them such privileges and
assign them a certain CPU time share dynamically. In this scenario could also
refuse connections if it considers that there isn't enough resources.

Doesn't this make sense to a certain extent?

Wouldn't this be an improvement in regard to security?

--
  Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev