[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Paul Davis paul at linuxaudiosystems.com
Mon Jun 22 01:16:26 UTC 2009


On Sun, Jun 21, 2009 at 7:52 PM, Lennart Poettering<mzynq at 0pointer.de> wrote:
>
>> so, sched_setschedparam(), a documented, implemented and demonstrably
>> functional call fails in some cases. and your proposal is to replace
>> this well-established API with a new API that doesn't actually
>> accomplish anything new except *WORKING* ?
>
> No. I am not talking about *replacing*. I have asked for adding
> support for rtkit to it.

this is quibbling over details. sched_setschedparam() *should* work -
its documented as working, the kernel and the higher levels of the OS
provide a mechanism to grant priviledge but ... it isn't.  so the fix
is to add a new call? is this really what are you saying?

> The thing is that we cannot safely hand out RT privileges to user
> processes without doing acess/rate limiting, watchdog support, calls
> into policy systems and so on and so on.

hence my comment: RTKit is a baroque solution to a problem that really
needs a much more sophisticated solution.

>> go and ask linus or ingo and/or whoever is deputized to handle (a)
>> scheduling and (b) priviledge control mechanisms. if they come back

> Now, if you think you have a better insight into how things should be
> done than all of us, then hey, be my guest, why don't you make some
> *proper* suggestions how an alternative should be looking like? Asking
> for "creative use" and giving the fault to the distributors just
> doesn't cut it.

you seem to have missed the fact that we went through just such a
discussion about 3 years ago when RLIMIT_RTPRIO was first added. there
was wide discussion about how to do this. there was specific
expectation that distros would provide mechanisms for enabling (and
disabling) its use. it was *explicitly* intended to be
group-controllable. now you inform us that "it has been decided" that
this is bad design. ok, we learn from mistakes and we move on. but
everytime this happens, it makes it harder to trust the next choice.
and what happened after the last decision was made about how to
support/configure this ...

almost every media-centric distro enables it out of the box (by user
group); no "mainstream" distro does. nobody has created any
user-accessible mechanisms to configure it. everything that expected
to happen after it went into the kernel has not happened. distro
maintainers argue that its a security/robustness problem, and i'm not
arguing with this. but there are many things you can configure on any
mainstream distro that create security/robustness problems, this one
just happens to come with only a text file to configure it and no
support from any distro (media centric ones included).

> The big problem with RLIMIT_RTPRIO is that it is vulnerable to a
> combined fork bomb/busy loop attack. Which I btw documented in the
> README (which I figure you didn't read?). Because that is the way it
> is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What
> did happen is that some distros added an ugly unsecure kludge by
> adding "jackuser" group or suchlike that you can add a user to that
> had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also
> leaves the "out-of-the-box" issue unresolved.

except that i could find you posts from people on the l-k mailing list
3 years ago that argued precisely the opposite: that this was
*exactly* the solution that was in keeping with other kernel security
policy/design issues.

> You seem to suggest that I wasn't talking to the kernel folks before I
> do something like this. That is wrong. This announcement of mine was
> just the last step in doing all this, not the first step.

so, who of the half-dozen people from the LAD world who contributed to
the discussion that led to RLIMIT_RTPRIO did you include? there seem
to be some remarkably short-lived memories in kernel land if people
there are so ready to support what is essentially a workaround to what
used to be the Right Answer.

> Gah. This discussion is so pointless. If you don't want to use in
> Jack then fine. The distributions will ship the API and if you don't
> make use of it, so be it. It's certainly disappointing, but ultimately
> it's not my problem.

Lennart, I am not *that* self-centered. I've been confronting issues
with Linux support for RT for more than 10 years. I don't give a damn
about whether JACK uses this or not. What I care about is the more or
less complete failure of the Linux community (by which I include
myself, and all of the rest of us) to come with solutions to this
problem that actually work and will be supported over more than a
couple of years before we move on to the "next approach".  I totally
understand the goal you have with RTKit, and I applaud you strongly
for trying to get this situation fixed. But your solution appears out
of the blue in front of one of the two communities most affected by
this stuff, and basically ditches the last solution, in which we were
quite involved and invested, for a totally different (service/IPC
based) solution. Can you not understand why there is some resistance?



More information about the Linux-audio-dev mailing list