Re: [LAD] Realtime threads and security

On 02/23/2011 06:24 PM, Daniel Poelzleithner wrote:
> On 02/23/2011 11:10 AM, Olivier Guilyardi wrote:
>
>> The dynamic cgroups solution seems good.
>>
>> On Android there basically is one priviledged and trusted audio process,
>> audioflinger, the sound server, which performs mixing and access the hardware.
>> All audio clients are untrusted. I think there is a need to both assign a
>> careful cpu.rt_runtime_us to each client but also to limit the number of clients
>> which can run at the same time. This would allow to keep the CPU time assigned
>> to all clients within a certain quota, but also to prevent clients from fighting
>> with each other for realtime bandwidth.
>>
>> Can you limit the maximum number of realtime processes with ulatencyd?
>
> Yes, that should be possible, even i never used that. So, you want a
> first come first get policy ?

Yes, that's the idea. Maybe limit the number of audio clients to a few ones.

> There is no nice api for detecting the number of processes in a group
> but i will add one as i think it's a valid decision to consider. There
> is no per se limit of processes in a group, in fact: there is no way to
> limit processes numbers anyhow, unfortunately. Makes it very hard to
> write write a fork bomb protector ;-)
>
> But, you can of course just stop moving processes into a group.
>
> Yesterday i added a instant filter functionality that allows you with
> witelists to move processes extremly quickly. This is required for some
> daemons that request realtime and then messure the cpu time they get to
> test if it's enough for running smoothly. Those problematic processes
> must be whitelisted because the normal delay mechanism would schedule
> them to late, as many processes started are just short running and
> looking at them is just a waste of cpu time.

In the case of Android, here's what I imagine:

- a client program asks for (realtime) audio access
- the audio server verifies if there aren't too many clients
- from that, the server either allows or denies access
- in case of a denial the client program can display a meaningful error

One thing is that each client runs under a different UID. This is part of app
sandboxing. There isn't any predetermined groups of users who can or can't
access audio (oh well there is a permission system for that, but it's another
question).

Basically, any app could request audio access, and ulatencyd or whatever does
the same job would have to be rather tightly integrated into the sound server,
and move the requesting app to a realtime cgroup if it's possible, or deny
access and return an error.

Well, you could imagine that ulatencyd and the sound server are distinct and
that the client program must connect to both to achieve realtime + audio access.

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?

This would for example result in a new error reported by jack_client_open() in
case realtime permissions can't be granted because there are too many clients, etc..

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