Re: [LAD] Realtime threads and security

On 02/17/2011 11:04 PM, Fons Adriaensen wrote:
> On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus wrote:
>
>> /proc/sys/kernel/sched_rt_runtime_us
>> /proc/sys/kernel/sched_rt_period_us
>>
>>> I've been told than on OSX, when a process runs in realtime, it is only allowed
>>> to use a certain ratio of CPU time. And if it goes over this limit, it loses its
>>> priority. Is there something comparable on Linux? Maybe with the files in
>>> /proc/sys that you mention?
>> not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime
>> scheduling time. To limit it per process you'll need cgroups.

Thank you. This, as described in Documentation/scheduler/sched-rt-group.txt is
exactly what I was looking for. A cgroup may indeed be required for all clients,
with another cgroup for the sound server.

> Still this provides protection against any RT-process that goes
> out of control. If the limit is exceeded, all RT procs will be
> blocked for the next sched_rt_period_us (default seems to be 1s),
> which should give you the opportunity to kill the offending process.

Reading sched-rt-group.txt it seems to me like if the limit is exceeded, RT
processes are preempted until the end of the period, which sounds very good. I
assume that's what you mean by "blocked".

If the sound server is in its own cgroup then system audio shouldn't be affected
by bogus user-space clients. But, in the context of Android, I'm a bit worried
about the fact that one bogus realtime app could affect all other running
realtime apps. On Android, there are background processes, and users could be
misled if they see that a foreground app starts to malfunction, when it's
actually caused by a background process.

I think that ideally, the system should detect the offending app, freeze it, and
pop up a dialog to inform the user. That's already the way it works when an
application is not responding or crashes.

I am not sure how that would be feasible. Maybe with das_watchdog as mentioned
by Paul or something custom/similar?

Alternatively, the system could refuse to run more than one realtime client at
the same time. But how to do that? Maybe by having the sound server dynamically
assign the client to a cgroup only if possible, or refuse and report an error to
the client otherwise?

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