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

On Sun, 21.06.09 21:16, Paul Davis (paul@email-addr-hidden) wrote:

>
> On Sun, Jun 21, 2009 at 7:52 PM, Lennart Poettering<mzynq@email-addr-hidden> 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?

What I am saying is that the current system is too "binary": Either
you have RT sched and then for *everything*. Or you haven't, and then
you haven't got it for *anything*.

For the desktop case you need something in between: RT that cannot be
misused, basically. Doing that securely is particularly hard, which is
the reason why we still haven't got it. Only if this solution "in
between" is found, we can enable RT by default for normal users.

Now, a lot of suggestions have been made to fix this over the
years. RLIMIT_RTPRIO, isochronous scheduling, using cgroups and so
on. All of those solutions turned out to be suboptimal and never got
adopted by the distros in a wide scale, or haven't even made into the
kernel.

Now, rtkit is another approach, a lot simpler, and something that was
in the end implementable in just a few days of work, with only minor
changes necessary on the kernel side. Something "good enough", to for
being adopted for the next few years.

Since it enforces all kinds of policy on its clients this little tool
lives in userspace, so that the policy parameters don't have to be
encoded in the kernel.

Now, as mentioned rtkit might not be a solution for eternity. However
it is a solution that should be good enough for quite some time.

Maybe one day we get isochronous scheduling in the kernel with all the
"adding up" issues fixed in a clean way. That day we can kill rtkit
again from the distros. Should be easy enough given how minimal the
interfacing between apps and rtkit actually is.

> >> 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 ...

I wasn't around at those discussions back then, and neither was I in
the position I am in now. My views on that story is that back then RT
for audio was only relevant for audio _production_, and the folks
involved didn't see a problem with asking the user to become a member
of some group.

Nowadays, RT for audio is relevant for the normal desktop use case,
too. And asking for group membership or some other way to bump
RLIMIT_RTPRIO is very bad UI. Almost no user can make a properly
informed decision before agreeing to that.

So, the situation changed since then. What was a bit of a niche
feature in those days is now something that should be exposed by
default. And this asks for reinvestigating the whole story, and making
RT less "binary", as mentioned above, and supervising its use.

> > 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.

Back then desktop folks were not involved. polkit was not around and
it was a bit of a nichey special-purpose feature. All that changed
now.

> > 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.

The kernel patch was discussed publicly on lkml. I discussed this on
IRC with a couple of folks involved, whose OK I was looking for.

Also, the kind of anti-desktop fud war that errupted as a result to
this little announcement on lad is not really a convincing argument for
always keeping all of LAD in the loop.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev