17 Feb
2011
17 Feb
'11
10:27 p.m.
On 02/17/2011 09:48 PM, Paul Davis wrote:
On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi
<list(a)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