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