Re: [LAD] Realtime threads and security

From: Robin Gareus <robin@email-addr-hidden>
Date: Thu Feb 17 2011 - 23:53:54 EET

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@email-addr-hidden> 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Feb 18 00:15:06 2011

This archive was generated by hypermail 2.1.8 : Fri Feb 18 2011 - 00:15:06 EET