[LAD] Realtime threads and security

Robin Gareus robin at gareus.org
Thu Feb 17 21:53:54 UTC 2011


On 02/17/2011 10:27 PM, Olivier Guilyardi wrote:
> 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?

Hi Olivier,

Paul must have been talking about

/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us

<kernel-source>/Documentation/scheduler/sched-rt-group.txt

> 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?

not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime
scheduling time. To limit it per process you'll need cgroups.

> 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
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev



More information about the Linux-audio-dev mailing list