Subject: Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: Mon Sep 02 2002 - 21:43:00 EEST
On Sunday 01 September 2002 18.50, Paul Davis wrote:
> [I wrote:]
> >The only thing the sound servers need to be able to handle
> >RT audio are:
> >* one of the RT scheduling methods.
> >* locked memory. (Not protected at the moment - hard limits?)
>
> >This can be archived with a wrapper that drops ALL other priorities
> >before running the real application.
>
> this is, alas, not true. to use RT scheduling, you need either root
> uid or CAP_RESOURCE. if you have CAP_RESOURCE or root uid, you can do
> many, many things (such as write to /dev/kmem) that can lead to a DOS.
So this code from artswrapper.c does not work then?
(hmm, shouldn't it should do setegid too...)
/* drop root privileges if running setuid root
(due to realtime priority stuff) */
if (geteuid() != getuid())
{
#if defined (HAVE_SETEUID) && !defined (HAVE_SETEUID_FAKE)
seteuid(getuid());
#else
setreuid(-1, getuid());
#endif
}
But we can play safer than that!
Since the priorities can be set by another process, we can let the monitor do
it! (In the same way as it can reduce the priorities). And if we do it this
way we can build a higher level interface - requesting C cycles or MACs every
T microseconds. Or is ther a better interface?
Problems:
* it is hard to lock the memory... since mlockall does not work
over forks...
* How to prevent ANY program to request this? Might not be a problem since we
will not give away more cycles than available...
This might be a very good thing - giving the ability to request RT prio for
any program.
>
> the central problem is that there is no way to tell the kernel "this
> thread should get to run whenever it wants, but do nothing else that a
> normal process cannot do", and likewise, "this vm address space can
> lock down up to 128MB of memory". we don't have sufficiently
> granularity to do this, so we have to grant overly broad access. that
> in turns means that anything granted such access has many, many more
> ways of attacking the system than burning CPU cycles or locking down
> too much memory (and, BTW, i'm not sure if this latter issue is a
> problem or not with the emergence of process killing logic in the
> kernel these days).
The OOM killer might be fooled into killing an other random process...
(I have to check the code to be sure what will happen in this unnormal
situation)
My feeling is that this should be handled by the monitor aswell.
Maybe by sharing locked memory with the processes or by introducing
a new system call. Anyway - on a computer with enough memory this
should not be a problem. (but it might since several kernel versions might
swap out pages rather than flushing a recently read or written file...)
>
> to make this situation better means recognizing the utility of
> granting very specific resources to be used or more or less
> exclusively by a single task, even when those resources more or less
> mean "all of the machine". this is not something that POSIX or Linux
> provides at this time.
>
> --p
>
>
I will give this monitor addition a try tonight.
/RogerL
-- Roger Larsson Skellefteċ Sweden
This archive was generated by hypermail 2b28 : Mon Sep 02 2002 - 21:55:41 EEST