[LAD] Realtime threads and security

Olivier Guilyardi list at samalyse.com
Thu Feb 17 21:27:15 UTC 2011


On 02/17/2011 09:48 PM, Paul Davis wrote:
> On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi <list at samalyse.com> wrote:
> 
> in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
> everyone was incredibly simple. i recall kjetil posting a couple of
> lines, at most.
> 
> whether this a security risk depends on which other parts of the
> kernel android uses. on regular linux, its no longer possible for any
> process to steal all the CPU time. there are files in the /proc/sys
> filesystem that control the amount available.
> 
> note that patching the kernel in this way means that any process by
> any user can get SCHED_FIFO so its hardly clear that this is actually
> any better than using rlimits from a security perspective.

I know that patching is not a requirement anymore for realtime on Linux. But I
was just asking about some possible security enhancement patch.

What are those files in /proc/sys that you mention?

Also I'm a bit confused about rlimits. IIUC, realtime processes always run
before non-realtime processes. And the realtime priority as set with
set_rlimits() only affects the priority of realtime processes between each
other. It doesn't seem to affect the priority between realtime and non-realtime
processes.

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?

What I'm looking for is some way to say: ok, this thread can run in realtime,
but if it ever uses more than 10% of CPU time it will lose realtime priority.

Aside of that, what about locks? I've many times been told that one mustn't do
anything that could block in a realtime thread. What are the consequences of
that? Could a malicious app freeze the system by blocking in a realtime thread?

--
  Olivier



More information about the Linux-audio-dev mailing list