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

2009-06-19 Thread Lennart Poettering
Heya,

Just a quick announcement:

I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.

So what does this do? It's a simple policy daemon that hands out
SCHED_RR scheduling to normal user processes/threads that ask for it.

So what's so fancy about it? Nothing. Except that is hopefully a good
solution for handing out RT scheduling and is also actually secure.

What's wrong with using RLIMIT_RPRIO? The simple fact that we cannot
enable that by default since it basically empowers the user to freeze
the machine. Also, asking the user to edit /etc/security/limits.conf
is certainly not user-friendly. We want to enable RT scheduling for
media aplications out-of-the-box.

But what's wrong with relying on RLIMIT_RTTIME? Being a process limit
it can very easily be circumvented for freezing the machine by
combining an RT busy loop with a fork bomb.

But what's wrong with relying on on a canary watchdog to avoid
freezing systems? It's racy: an evildoer could fork more quickly than
the canary watchdog daemon could demote its children. So a canary is
not really a protection against a frozen system.

Why not use cgroups for this? Because it's simply a horrible API, and
using this for media applications has non-obvious consequences on
using cgroups for their originally intended purpose -- which are
containers.

So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31. You
can set that flag when entering SCHED_RR scheduling and this will then
make sure that after forking a child will be reset to
SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand out
RT to a process we can be sure it won't "leak", and if we decide to
take it away again we can be sure we can do that without having to be
afraid of races around forking.

rtkit enforces limits on the the number of threads/processes/users
that get RT sched. It also does rate limiting, and calls into
PolicyKit before handing out RT. Finally, as extra a-posteriori
protection it also includes a canary watchdog.

So what does that mean for you?

If you don't do RT development or doing RT development only for
embedded cases, or if you are a 
Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy
then it doesn't mean anything for you.

However, if you are a desktop developer interested to get your stuff
working out-of-the-box on modern distributions then you should think
about calling into RealtimeKit for acquiring RT scheduling.
RealtimeKit has a trivial API, to make a thread SCHED_RR it's just one
D-Bus method you need to call. You can either code that call yourself
or alternatively just copy the reference client implementation rtkit
includes into your sources:

http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.h
http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.c

For more information see this:

http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

So yepp, it would be great if folks would adopt this in their apps, so
that a user doesn't need to know about all those Unix intricacies such
as resource limits and so on, but still get good perfomance in his
media applications by default.

This is now in Fedora Rawhide which will still take a few months to be
released as F12. The other distros probably need a bit more time for
this. This means this is not a burning issue yet, so this is mostly
intended as a heads-up right now.  Unless of course you are one of
those cool dudes who are living on the bleeding edge.

Packagers, you might want to steal this .spec file for you work:

http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?revision=1.1&view=markup

Questions?

Lennart

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


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

2009-06-19 Thread Ralf Mardorf
Lennart Poettering wrote:
> So what does RealtimeKit do that previous solutions didn't do? rtkit
> relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
> merged into Ingo's tree and will hence shortly appear in 2.6.31.

Is it proved not to negative affect MIDI jitter? It seems to be an up 
and down with kernel versions. Audio always seems to be fine, while MIDI 
jitter increases or decreases randomly from version to version. It 
should been proved that it won't have unwanted effects, before it's 
included to the rt patch's tree. I'm a user only, it's not an 
assumption, just a question.

Best,
Ralf

-- 
http://www.dailywav.com/1002/beginning.wav

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-19 Thread Lennart Poettering
On Fri, 19.06.09 20:32, Ralf Mardorf (ralf.mard...@alice-dsl.net) wrote:

>
> Lennart Poettering wrote:
>> So what does RealtimeKit do that previous solutions didn't do? rtkit
>> relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
>> merged into Ingo's tree and will hence shortly appear in 2.6.31.
>
> Is it proved not to negative affect MIDI jitter? It seems to be an up  
> and down with kernel versions. Audio always seems to be fine, while MIDI  
> jitter increases or decreases randomly from version to version. It  
> should been proved that it won't have unwanted effects, before it's  
> included to the rt patch's tree. I'm a user only, it's not an  
> assumption, just a question.

This should have no such impact. The flag is only checked for on
fork(), i.e. almost never.

Lennart

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


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

2009-06-19 Thread Ralf Mardorf
Lennart Poettering wrote:
> On Fri, 19.06.09 20:32, Ralf Mardorf (ralf.mard...@alice-dsl.net) wrote:
>
>   
>> Lennart Poettering wrote:
>> 
>>> So what does RealtimeKit do that previous solutions didn't do? rtkit
>>> relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
>>> merged into Ingo's tree and will hence shortly appear in 2.6.31.
>>>   
>> Is it proved not to negative affect MIDI jitter? It seems to be an up  
>> and down with kernel versions. Audio always seems to be fine, while MIDI  
>> jitter increases or decreases randomly from version to version. It  
>> should been proved that it won't have unwanted effects, before it's  
>> included to the rt patch's tree. I'm a user only, it's not an  
>> assumption, just a question.
>> 
>
> This should have no such impact. The flag is only checked for on
> fork(), i.e. almost never.
>
> Lennart
>   

That's good Lennart. Thank you for the information. I always fear that 
things can have impact to the poor relation rt-MIDI.

Best,
Ralf

-- 
http://www.dailywav.com/1002/beginning.wav

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-19 Thread Chris Cannam
On Fri, Jun 19, 2009 at 7:13 PM, Lennart Poettering wrote:
> Questions?

Is it safe to assume that the PulseAudio libraries will use this
method to acquire real-time scheduling for the audio callback thread
of any application that uses the PulseAudio callback API directly?


Chrs
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-19 Thread Lennart Poettering
On Fri, 19.06.09 20:39, Chris Cannam (can...@all-day-breakfast.com) wrote:

> 
> On Fri, Jun 19, 2009 at 7:13 PM, Lennart Poettering wrote:
> > Questions?
> 
> Is it safe to assume that the PulseAudio libraries will use this
> method to acquire real-time scheduling for the audio callback thread
> of any application that uses the PulseAudio callback API directly?

Uh. I thought about that. Not sure if we really should do that
though. In many cases, the app's IO callback might not really be that
well suited for execution in RT. And then it might end up being killed
by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
and we could just make all IO threads RT at prio 1 or so. I am a bit
afraid that such a thing might backfire and we fuck up the scheduling
for everyone else too.

I really don't know. Maybe just make it easily accessible would be a
good idea, but not enable by default. But OTOH RT is not a magic wand,
so I wouldn't want to create the illusion that just making a broken
app RT fixes all issues magically.

Lennart

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


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

2009-06-19 Thread Chris Cannam
On Fri, Jun 19, 2009 at 9:03 PM, Lennart Poettering wrote:
> On Fri, 19.06.09 20:39, Chris Cannam (can...@all-day-breakfast.com) wrote:
>> Is it safe to assume that the PulseAudio libraries will use this
>> method to acquire real-time scheduling for the audio callback thread
>> of any application that uses the PulseAudio callback API directly?
>
> Uh. I thought about that. Not sure if we really should do that
> though. In many cases, the app's IO callback might not really be that
> well suited for execution in RT. And then it might end up being killed
> by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
> and we could just make all IO threads RT at prio 1 or so. I am a bit
> afraid that such a thing might backfire and we fuck up the scheduling
> for everyone else too.

That's a fair point.  Given history, I expect the last thing we want
is to create an impression that providing good audio services in a
distribution must be seriously detrimental to anyone's server
workload.

For my part, I have applications that use JACK if available, falling
back first to PulseAudio's callback API and then to ALSA via
PortAudio, using effectively the same callback code in each case.

I'd be happy to add another couple of lines to improve the scheduling
of my callback thread when using Pulse in a "desktop" context.  A bit
more code is no problem; there's already quite a lot of logic there:
arguably too much, but I don't want to lose PortAudio because it
provides portability, I don't want to lose the direct Pulse layer
since it works best of the three for me in most desktop situations,
and I don't want to lose JACK because, well, it's JACK.

But I probably would mind having to explicitly include and link
against DBUS libraries.  I appreciate that my code is already using
DBUS somewhere under the covers, but another explicit build dependency
for two lines of code doesn't seem ideal.  So a way to do this through
the PulseAudio API would be very welcome to me.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-20 Thread Lee Revell
On Fri, Jun 19, 2009 at 4:03 PM, Lennart Poettering wrote:
> On Fri, 19.06.09 20:39, Chris Cannam (can...@all-day-breakfast.com) wrote:
>
>>
>> On Fri, Jun 19, 2009 at 7:13 PM, Lennart Poettering wrote:
>> > Questions?
>>
>> Is it safe to assume that the PulseAudio libraries will use this
>> method to acquire real-time scheduling for the audio callback thread
>> of any application that uses the PulseAudio callback API directly?
>
> Uh. I thought about that. Not sure if we really should do that
> though. In many cases, the app's IO callback might not really be that
> well suited for execution in RT. And then it might end up being killed
> by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
> and we could just make all IO threads RT at prio 1 or so. I am a bit
> afraid that such a thing might backfire and we fuck up the scheduling
> for everyone else too.

Sorry if this is too many questions, i have read the Pulse code and
the LKML thread and was wondering:

I was under the impression that SCHED_RESET_ON_FORK was needed to
safely enable RT mode in Pulse because Pulse runs untrusted client
code.  If that's not the case then why is it needed?

What does RealtimeKit set the RR interval to?  IIRC the default is
100ms, seems like this could cause desktop interactivity issues.  What
determines the upper bound on the amount of work Pulse's RT threads
can do?

Without mlock(), what happens when the SCHED_RR thread starts taking
page faults?  AFAICT, it will be scheduled out, but as long as it has
time slice left, it will be immediately rescheduled.

Lee
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Paul Davis
On Fri, Jun 19, 2009 at 2:13 PM, Lennart Poettering wrote:
> Heya,
>
> Just a quick announcement:
>
> I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> which will be enabled by default, and since it is now a dependency of
> PulseAudio and things work how they work this will then not only be
> available in Fedora 12 but also sooner or later in the other
> distributions as well, installed by default.
>
> So what does this do? It's a simple policy daemon that hands out
> SCHED_RR scheduling to normal user processes/threads that ask for it.

This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions. Alternatively, one could see
it as a baroque mechanism designed to solve to solve a problem that
really needs a much more sophisticated solution (i.e. better
scheduling policies). Either way, it seems like something that makes
things more complex on every level, not less. Take a look at the code
in libjack/thread.c and compare and contrast what is necessary to get
a realtime thread on Linux (already) compared to OS X. You're adding a
new API for this that will not be backwards compatible beyond a kernel
change that has only just been made. I cannot imagine wanting to use
this mechanism. You also seem to have assumed that everyone agrees
that SCHED_RR is the correct policy, rather than SCHED_FIFO.
Reasonable people still disagree about this. Finally, as Chris said -
many of us are writing apps that target multiple platforms, and adding
a new dependency on non-POSIX systems like DBus in order to get done
things that are supposed to be possible with the POSIX API ... well,
it gives some of us a slightly wierd feeling at the very least.

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Lennart Poettering
On Sat, 20.06.09 03:42, Lee Revell (rlrev...@joe-job.com) wrote:

> > Uh. I thought about that. Not sure if we really should do that
> > though. In many cases, the app's IO callback might not really be that
> > well suited for execution in RT. And then it might end up being killed
> > by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
> > and we could just make all IO threads RT at prio 1 or so. I am a bit
> > afraid that such a thing might backfire and we fuck up the scheduling
> > for everyone else too.
> 
> Sorry if this is too many questions, i have read the Pulse code and
> the LKML thread and was wondering:
> 
> I was under the impression that SCHED_RESET_ON_FORK was needed to
> safely enable RT mode in Pulse because Pulse runs untrusted client
> code.  If that's not the case then why is it needed?

PA runs as user process. That's why this is needed. If a process is a
user process the user can do with it whatever he wants, in the PA case
this is even especially easy since all he needs to do is load some
module he wrote into the daemon.

> What does RealtimeKit set the RR interval to?  IIRC the default is
> 100ms, seems like this could cause desktop interactivity issues.  What
> determines the upper bound on the amount of work Pulse's RT threads
> can do?

We leave the RR interval at the default. I have some doubts that
fiddling with the RR interval is a good idea. First of all the API to
do that is messy and changed across kernel versions a few
times. Secondly, rtkit is not really useful beyond desktop media
stuff, and a desktop media application that wants to take a
substantial CPU share while being RT (where the interval would matter)
is uh, suspicious to say the least.

The CPU time is limited by RLIMIT_RTTIME and also simply by the fact
that on system overload (the definition of which can be configured in
rtkit) the RT threads are demoted.

I mean, if fiddling with the rr interval turns out to be necessary, we
can still add an interfaces this. Dunno. I kinda have the idea that
this is mostly a theoretical question anyway, since at least in the
audio case in the usual case only one process is runnable anyway, ...

If someone wants this, and has a good use case we can certainly add
this, but I'd not think too much about stuff we don't need right now.

> Without mlock(), what happens when the SCHED_RR thread starts taking
> page faults?  AFAICT, it will be scheduled out, but as long as it has
> time slice left, it will be immediately rescheduled.

To my knowledge while the process is waiting for IO to complete for
the page fault other processes will be scheduled. The time
spent in page faults is not counted as process time.

Lennart

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


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

2009-06-21 Thread Lennart Poettering
On Sun, 21.06.09 11:09, Paul Davis (p...@linuxaudiosystems.com) wrote:

> > Just a quick announcement:
> >
> > I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> > which will be enabled by default, and since it is now a dependency of
> > PulseAudio and things work how they work this will then not only be
> > available in Fedora 12 but also sooner or later in the other
> > distributions as well, installed by default.
> >
> > So what does this do? It's a simple policy daemon that hands out
> > SCHED_RR scheduling to normal user processes/threads that ask for it.
> 
> This appears to be a baroque mechanism designed to solve a problem
> suspectible to vastly simpler solutions. 

Simpler solutions? I am listening! What would a "simpler solution" be,
that doesn't suffer by all the issues I pointed out in the README? 

Also, what's baroque with this? I mean, really, this offers an API of
two tiny functions. Not sure why you'd call that baroque?

> Alternatively, one could see it as a baroque mechanism designed to
> solve to solve a problem that really needs a much more sophisticated
> solution (i.e. better scheduling policies). 

Dunno. SCHED_ISO would certainly be nice, but having that wouldn't
solve the problem really either. Also in the end you need to supervise
RT processes anyway, which is heavily bound to admin policy and
will hence probably always require some userspace part.

And rtkit is just a tiny piece of software that only requires minimal
additions to client code to be useful. So if one day it turns out it
won't be necessary anymore then we can simply remove without much
hassle. This doesn't have to be a solution for the eternity.

> Either way, it seems like something that makes things more complex
> on every level, not less. 

Ah yeah? How so? What's complex? Adding a single #ifdef'ed fucntion
call to your code? I mean, really, there's not much left that could be
simpler than that.

> Take a look at the code in libjack/thread.c and compare and contrast
> what is necessary to get a realtime thread on Linux (already)
> compared to OS X.

Uh? I see one function call for mach's setThreadToPriority
vs.  one function for pthread_setschedparam(). Uh? Where's the
practical difference?

> You're adding a new API for this that will not be backwards
> compatible beyond a kernel change that has only just been made.

So what? How does that matter? New features you only get with new
code.

And it's not that adding support for rtkit to some software would
break anything that worked previously. RLIMIT_RTPRIO will still work
just fine, if people set it. All rtkit is about is that we can enable
RT scheduling for media applications out-of-the-box on newer Linux
distributions. If 'out-of-the-box' doesn't matter to you then
fine, I am pretty sure that distributors who ship your software do
care about it. I am pretty sure that in Fedora we would simply patch
jack_acquire_real_time_scheduling() to query rtkit if
pthread_setschedparam() fails with EPERM. It's a tiny
patch. However, I really don't see why you wouldn't want to merge a
jack patch like that to jack's official sources as long as it is a
compile-time option. I am pretty sure the distributors would be
thankful for that.

> I cannot imagine wanting to use this mechanism. You also seem to
> have assumed that everyone agrees that SCHED_RR is the correct
> policy, rather than SCHED_FIFO.  

If people can make a good case for SCHED_FIFO, then fine, we can add
that to rtkit.

Personally, I believe that RR vs. FIFO is not so much a decision that the
programmer should make. I think this is more a decision for the admin,
because this influences fairness between consumers of RT.

> Reasonable people still disagree about this. Finally, as Chris said
> - many of us are writing apps that target multiple platforms, and
> adding a new dependency on non-POSIX systems like DBus in order to
> get done things that are supposed to be possible with the POSIX API
> ... well, it gives some of us a slightly wierd feeling at the very
> least.

Uh. First of all, it's hard to find a POSIX system these days that
doesn't have D-Bus installed. All big distributions ship it. All big
desktop environments require it. Even non-Linux systems that are from
the last 5 years ship it. To find a system that lacks D-Bus you need
to go to niche distributions which are specifically designed to avoid
sytems such as D-Bus. But I seriously doubt they really matter.

D-Bus is simply an API for IPC, one that happens to have an adoption
of 100% on relevant POSIX implementations. If you try to avoid D-Bus
for IPC when coding for those systems then all you do is reinventing
the wheel over and over, duplicating a substantial amount of code, and
potentially buggy code. At this point in time it's not D-Bus that is
bloat but it is the applications that still implement their own
non-trivial IPC system that include unnecessary bloat.

Finally, I believe your insisting on POSIX is a lost cause

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

2009-06-21 Thread Paul Davis
On Sun, Jun 21, 2009 at 6:15 PM, Lennart Poettering wrote:
> On Sun, 21.06.09 11:09, Paul Davis (p...@linuxaudiosystems.com) wrote:
>
>> > Just a quick announcement:
>> >
>> > I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
>> > which will be enabled by default, and since it is now a dependency of
>> > PulseAudio and things work how they work this will then not only be
>> > available in Fedora 12 but also sooner or later in the other
>> > distributions as well, installed by default.
>> >
>> > So what does this do? It's a simple policy daemon that hands out
>> > SCHED_RR scheduling to normal user processes/threads that ask for it.
>>
>> This appears to be a baroque mechanism designed to solve a problem
>> suspectible to vastly simpler solutions.
>
> Simpler solutions? I am listening! What would a "simpler solution" be,
> that doesn't suffer by all the issues I pointed out in the README?
>
> Also, what's baroque with this? I mean, really, this offers an API of
> two tiny functions. Not sure why you'd call that baroque?

the API is simple. the implementation that the API sits on top of it
baroque. not yours, necessarily, but the combination of RTKit and
Ingo's patch. Baroque doesn't necessarily mean "huge, vast and
incomprehensible". it can just mean "overly intricate for the task at
hand".

i definitely led you astray with the reference to the jack source
code. firstly because you seem to have imagined that by mentioning the
use of POSIX i was making some kind of claim about POSIX correctness -
not sure what kind of game that it is. but secondly and more
importantly because the code now looks reasonably clean as a result of
me ditching all the crap that we needed on various older versions of
linux. yes, it is indeed now just as simple as OS X. in the code only,
of course. i had forgotten to check the current state of things before
referring to it.

>All I kindly ask for is to ease the distributors life by
> adding a tiny bit of fallback code that does a tiny call into rtkit in
> case sched_setschedparam() fails with EPERM and is #ifdef as __linux__
> && HAVE_DBUS and is also contorollable as a compile-time configure
> option.

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* ? i'm sorry but to me this is
just absurd. the call is there, it works (for a user with certain
priviledges granted), and has a reasonably long pedigree. why should
fixing the problem with priviledge granting be accomplished with a
different call to get the same scheduling priority, a call that relies
on new kernel functionality that isn't necessary for the sched_sp()
approach? this is applying a band-aid to  a deeper solution, and its
because of this that its hard to support it.

go and ask linus or ingo and/or whoever is deputized to handle (a)
scheduling and (b) priviledge control mechanisms. if they come back
and say "we think this is an appropriate solution and we don't intend
to address this any further in terms of kernel mechanisms" then the
conversation moves on to the next step - why are distributions not
being more creative with the priviledge granting mechanism that is
already in place? my reading of ingo's patch is that its mechanism,
not policy (as usual for the kernel), and its really *mostly*
duplicating facilities that are already intended to be accessed via
sched_setschedparam(). apparently, you feel otherwise. the thing is
lennart that the kernel guys and others interested in regular user
access to SCHED_(!OTHER) put a lot of effort into the current rlimit
mechanism as the appropriate solution. none of the mainstream
distributions have bothered to make it configurable, usable etc. etc.
fixing that by creating a new API just seems ... odd at best, and
counter-productive at worst.

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Fernando Lopez-Lezcano
On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:
> Heya,
> 
> Just a quick announcement:
> 
> I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> which will be enabled by default, and since it is now a dependency of
> PulseAudio and things work how they work this will then not only be
> available in Fedora 12 but also sooner or later in the other
> distributions as well, installed by default.

What other distros are considering its use? (or will use it?, or use it
currently?)

> So what does RealtimeKit do that previous solutions didn't do? rtkit
> relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
> merged into Ingo's tree and will hence shortly appear in 2.6.31. 

So this is, at this point, kernel version dependent, right? 
What happens if you run a 2.6.29.x kernel?

The question is relevant, I think, as the kernels that I use (Planet
CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
support is still far in the future). 

> You
> can set that flag when entering SCHED_RR scheduling and this will then
> make sure that after forking a child will be reset to
> SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand out
> RT to a process we can be sure it won't "leak", and if we decide to
> take it away again we can be sure we can do that without having to be
> afraid of races around forking.

If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hm... jack does not do any forking right? 

> rtkit enforces limits on the the number of threads/processes/users
> that get RT sched. It also does rate limiting, and calls into
> PolicyKit before handing out RT. Finally, as extra a-posteriori
> protection it also includes a canary watchdog.

How are all those limits set up and/or configured?

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Paul Davis
On Sun, Jun 21, 2009 at 7:06 PM, Fernando
Lopez-Lezcano wrote:

> If I understand correctly then the mechanism would not be useful for
> jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
> actually gives rt priority to threads in other processes (the clients of
> jack). But maybe things have changed in the way jack works internally
> these days, or, possibly I'm not completely understanding the
> implications... hm... jack does not do any forking right?

that's correct. there is no fork involved in setting up RT threads
inside JACK and even less for its clients.

i don't believe that lennart's RTKit relies on this though. The idea
is that a priviledged service is asked to give RT scheduling to a
thread, but because of Ingo's patch, it can grant it knowing that any
forked children will not also have RT scheduling.

of course, the name of lennart's new feature doesn't make it entirely
clear whether or not "fork" is equivalent to its "real" linux
implementation: clone. if it were not, then you could create an "RT
thread bomb" instead of a "fork bomb". i only did a quick reading of
his patch and in the context of the patch its not clear whether it
applies to every instance of clone() (i.e. thread or task creation) or
just plain fork().

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Fernando Lopez-Lezcano
On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:
> Heya,
> 
> Just a quick announcement:
> 
> I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> which will be enabled by default, and since it is now a dependency of
> PulseAudio and things work how they work this will then not only be
> available in Fedora 12 but also sooner or later in the other
> distributions as well, installed by default.
>
> What's wrong with using RLIMIT_RPRIO? 

You mean RLIMIT_RTPRIO?

> The simple fact that we cannot
> enable that by default since it basically empowers the user to freeze
> the machine. Also, asking the user to edit /etc/security/limits.conf
> is certainly not user-friendly. We want to enable RT scheduling for
> media aplications out-of-the-box.

As to configuration file editing, I think that in properly configured
distributions /etc/security/limits.conf is set up out of the box (when a
package that needs the privileges is installed) so that it is
unnecessary to edit it manually. 

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:
> On Sun, 21.06.09 11:09, Paul Davis (p...@linuxaudiosystems.com) wrote:
> > I cannot imagine wanting to use this mechanism. You also seem to
> > have assumed that everyone agrees that SCHED_RR is the correct
> > policy, rather than SCHED_FIFO.  
> 
> If people can make a good case for SCHED_FIFO, then fine, we can add
> that to rtkit.
> 
> Personally, I believe that RR vs. FIFO is not so much a decision that the
> programmer should make. I think this is more a decision for the admin,
> because this influences fairness between consumers of RT.

It is, ultimately, a decision for the _user_ to make. RealtimeKit should
also take that into account. 

As a user doing critical audio, say, in a concert situation, I'd require
that my computer's realtime audio tasks can use 99.9% of the cpu for
short amounts of time. I don't care if the rest of the user processes
are momentarily slowed down (up to a point, of course). I would very
much care if my computer, due to a temporary overload, decides to a)
glitch the audio and b) demote the rt process to SCHED_OTHER
permanently. It looks like the RealtimeKit is designed to do exactly
that by default. 

If that is the case, how can I regain control of what I can do without
having to resort to extreme cases of root configuration file magic, etc,
etc (what RealtimeKit is supposed to avoid). 

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Fernando Lopez-Lezcano
On Sun, 2009-06-21 at 19:14 -0400, Paul Davis wrote:
> On Sun, Jun 21, 2009 at 7:06 PM, Fernando
> Lopez-Lezcano wrote:
> 
> > If I understand correctly then the mechanism would not be useful for
> > jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
> > actually gives rt priority to threads in other processes (the clients of
> > jack). But maybe things have changed in the way jack works internally
> > these days, or, possibly I'm not completely understanding the
> > implications... hm... jack does not do any forking right?
> 
> that's correct. there is no fork involved in setting up RT threads
> inside JACK and even less for its clients.
> 
> i don't believe that lennart's RTKit relies on this though. The idea
> is that a priviledged service is asked to give RT scheduling to a
> thread, but because of Ingo's patch, it can grant it knowing that any
> forked children will not also have RT scheduling.

Without reading code it sounds from the description of RealtimeKit that
it is designed to avoid exactly the kind of thing Jack does routinely,
that is to grant rt scheduling to threads that belong to other processes
(the Jack clients). 

-- Fernando


> of course, the name of lennart's new feature doesn't make it entirely
> clear whether or not "fork" is equivalent to its "real" linux
> implementation: clone. if it were not, then you could create an "RT
> thread bomb" instead of a "fork bomb". i only did a quick reading of
> his patch and in the context of the patch its not clear whether it
> applies to every instance of clone() (i.e. thread or task creation) or
> just plain fork().


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Lennart Poettering
On Sun, 21.06.09 19:02, Paul Davis (p...@linuxaudiosystems.com) wrote:

> >> > So what does this do? It's a simple policy daemon that hands out
> >> > SCHED_RR scheduling to normal user processes/threads that ask for it.
> >>
> >> This appears to be a baroque mechanism designed to solve a problem
> >> suspectible to vastly simpler solutions.
> >
> > Simpler solutions? I am listening! What would a "simpler solution" be,
> > that doesn't suffer by all the issues I pointed out in the README?
> >
> > Also, what's baroque with this? I mean, really, this offers an API of
> > two tiny functions. Not sure why you'd call that baroque?
> 
> the API is simple. the implementation that the API sits on top of it
> baroque. not yours, necessarily, but the combination of RTKit and
> Ingo's patch. Baroque doesn't necessarily mean "huge, vast and
> incomprehensible". it can just mean "overly intricate for the task at
> hand".

It's me who wrote the kernel patch actually. And after discussing my
plans and the pros and cos with a few kernel/rt folks the patch went into
Ingo's tree.

The patch didn't come out of the blue sky and then Lennart came around
and wrote rtkit using it. No. Instead I have been discussing the issue
we fix with rtkit with a couple of people off and on for quite some
time now. And a couple of weeks ago I decided to actually to do
something about it and wrote this little patch accompanied by this
little userspace support for it which is going by the name of rtkit.

This is the patch btw:

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=ca94c442535a44d508c99a77e54f21a59f4fc462

Have you actually read rtkit's README file? This goes a bit into
details about the reasons to solve the issues this way.

http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

> >All I kindly ask for is to ease the distributors life by
> > adding a tiny bit of fallback code that does a tiny call into rtkit in
> > case sched_setschedparam() fails with EPERM and is #ifdef as __linux__
> > && HAVE_DBUS and is also contorollable as a compile-time configure
> > option.
> 
> 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.

> i'm sorry but to me this is just absurd. the call is there, it works
> (for a user with certain priviledges granted), and has a reasonably
> long pedigree. why should fixing the problem with priviledge
> granting be accomplished with a different call to get the same
> scheduling priority, a call that relies on new kernel functionality
> that isn't necessary for the sched_sp() approach? this is applying a
> band-aid to a deeper solution, and its because of this that its hard
> to support it.

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. 

> go and ask linus or ingo and/or whoever is deputized to handle (a)
> scheduling and (b) priviledge control mechanisms. if they come back
> and say "we think this is an appropriate solution and we don't intend
> to address this any further in terms of kernel mechanisms" then the
> conversation moves on to the next step - why are distributions not
> being more creative with the priviledge granting mechanism that is
> already in place? my reading of ingo's patch is that its mechanism,
> not policy (as usual for the kernel), and its really *mostly*
> duplicating facilities that are already intended to be accessed via
> sched_setschedparam(). 

You are really misunderstanding the situation here. Firstly, *I* wrote
the patch, and *I* was the one pushing this through. Secondly, this is
not coming out of the blue sky, but this is the result of discussions
with the RT folks, both inside RH and outside of RH. (which is
partially documented in the acked-by/signed-off-by of the patch, just
have a look!)

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.

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.

The low-level sched_setschedparam() syscall is a 

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

2009-06-21 Thread Lennart Poettering
On Sun, 21.06.09 16:06, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> 
> On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:
> > Heya,
> > 
> > Just a quick announcement:
> > 
> > I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> > which will be enabled by default, and since it is now a dependency of
> > PulseAudio and things work how they work this will then not only be
> > available in Fedora 12 but also sooner or later in the other
> > distributions as well, installed by default.
> 
> What other distros are considering its use? (or will use it?, or use it
> currently?)

This is a dep of PA now. Since all major distros adopted PA I'd be
surprised if they wouldn't adopt rtkit too. If things run like they
usually run then this will enter the other distros one cycle past F12. 

> > So what does RealtimeKit do that previous solutions didn't do? rtkit
> > relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
> > merged into Ingo's tree and will hence shortly appear in 2.6.31. 
> 
> So this is, at this point, kernel version dependent, right? 
> What happens if you run a 2.6.29.x kernel?

Nothing. Then the call into rtkit will simply fail. Since the rtkit
call is intended to be used as fallback only things will work as well
or badly as they did before rtkit was introduced.

> The question is relevant, I think, as the kernels that I use (Planet
> CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
> think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
> support is still far in the future). 

Dunno. I disagree. The primary objective for rtkit is to be able to
run media applications as RT by default, out-of-the-box. I doubt that
this feature matters for legacy distros/kernels.

> > can set that flag when entering SCHED_RR scheduling and this will
> > then make sure that after forking a child will be reset to
> > SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
> > out RT to a process we can be sure it won't "leak", and if we
> > decide to take it away again we can be sure we can do that without
> > having to be afraid of races around forking.
> 
> If I understand correctly then the mechanism would not be useful for
> jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
> actually gives rt priority to threads in other processes (the clients of
> jack). But maybe things have changed in the way jack works internally
> these days, or, possibly I'm not completely understanding the
> implications... hm... jack does not do any forking right? 

Dunno. All processes that want to have rt need to ask rtkit
themselves. (which is the only safe thing to do, only then we get the
credentials properly defined)

> > rtkit enforces limits on the the number of threads/processes/users
> > that get RT sched. It also does rate limiting, and calls into
> > PolicyKit before handing out RT. Finally, as extra a-posteriori
> > protection it also includes a canary watchdog.
> 
> How are all those limits set up and/or configured?

Right now you can edit the service startup file and pass them as
command line parameters. Just read the README I linked.

Lennart

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


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

2009-06-21 Thread Lennart Poettering
On Sun, 21.06.09 19:14, Paul Davis (p...@linuxaudiosystems.com) wrote:

> of course, the name of lennart's new feature doesn't make it entirely
> clear whether or not "fork" is equivalent to its "real" linux
> implementation: clone. if it were not, then you could create an "RT
> thread bomb" instead of a "fork bomb". i only did a quick reading of
> his patch and in the context of the patch its not clear whether it
> applies to every instance of clone() (i.e. thread or task creation) or
> just plain fork().

The distinction between a thread/clone() and a process/fork() bomb
doesn't really matter. What matters is that you can kill() processes
and make the whole issue go away in one step even if that process has
one gazillion threads and wants to create even more.

Lennart

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


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

2009-06-21 Thread Lennart Poettering
On Sun, 21.06.09 16:40, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> 
> On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:
> > Heya,
> > 
> > Just a quick announcement:
> > 
> > I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> > which will be enabled by default, and since it is now a dependency of
> > PulseAudio and things work how they work this will then not only be
> > available in Fedora 12 but also sooner or later in the other
> > distributions as well, installed by default.
> >
> > What's wrong with using RLIMIT_RPRIO? 
> 
> You mean RLIMIT_RTPRIO?

Yes.

> > The simple fact that we cannot
> > enable that by default since it basically empowers the user to freeze
> > the machine. Also, asking the user to edit /etc/security/limits.conf
> > is certainly not user-friendly. We want to enable RT scheduling for
> > media aplications out-of-the-box.
> 
> As to configuration file editing, I think that in properly configured
> distributions /etc/security/limits.conf is set up out of the box (when a
> package that needs the privileges is installed) so that it is
> unnecessary to edit it manually. 

Doing that is broken, and ugly.

Doing authorization via groups is broken, since practically you can
never take group membership away. Which is precisely one of the
reasons why PolicyKit got created.

Lennart

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


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

2009-06-21 Thread Lennart Poettering
On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> 
> On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:
> > On Sun, 21.06.09 11:09, Paul Davis (p...@linuxaudiosystems.com) wrote:
> > > I cannot imagine wanting to use this mechanism. You also seem to
> > > have assumed that everyone agrees that SCHED_RR is the correct
> > > policy, rather than SCHED_FIFO.  
> > 
> > If people can make a good case for SCHED_FIFO, then fine, we can add
> > that to rtkit.
> > 
> > Personally, I believe that RR vs. FIFO is not so much a decision that the
> > programmer should make. I think this is more a decision for the admin,
> > because this influences fairness between consumers of RT.
> 
> It is, ultimately, a decision for the _user_ to make. RealtimeKit should
> also take that into account. 
> 
> As a user doing critical audio, say, in a concert situation, I'd require
> that my computer's realtime audio tasks can use 99.9% of the cpu for
> short amounts of time. I don't care if the rest of the user processes
> are momentarily slowed down (up to a point, of course). I would very
> much care if my computer, due to a temporary overload, decides to a)
> glitch the audio and b) demote the rt process to SCHED_OTHER
> permanently. It looks like the RealtimeKit is designed to do exactly
> that by default. 

By default the watchdog will only become active after 10s of complete
lockup. This should be enough. We can raise it if this turns out to be
necessary, but let's wait for a request based on real-world data
before we do something like that.

Also note that in a case like yours admin and user are usually
identically, so if you don't trust rtkit just bypass it and use
RLIMIT_RTPRIO as it was done before rtkit came into the game.

> If that is the case, how can I regain control of what I can do without
> having to resort to extreme cases of root configuration file magic, etc,
> etc (what RealtimeKit is supposed to avoid). 

rtkit only comes into play as last resort when rt is cannot otherwise
be required (at least if developers follow my recommendations from the
README). If the supervised realtime sched that rtkit gives you isn't
good enough, then simply give your application unsupervised RT by
means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike.

Lennart

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


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

2009-06-21 Thread Adam Sampson
Lennart Poettering  writes:

> I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> which will be enabled by default,

It would have been nice to see some mention of this on l-a-u/l-a-d
earlier (i.e. while it was being designed), since getting realtime
priority for audio applications is a problem that's been discussed and
experimented with many times in this community. I'd imagine that most
people reading this list are already using one of the existing solutions
to this problem, and thus may be less delighted than you'd expect to
have another mechanism dropped in their laps with no prior warning or
chance to feed into the design process. ;-)

I don't think it's a good idea to make the D-Bus interface the public
API for this, because it assumes that you *can* write a D-Bus service
that gives a thread in another process realtime priority (which is true
for Linux, but not obviously so for other systems, even free ones). If
you want to make it easier for people to write realtime applications, I
think it'd be nicer -- and certainly more portable -- to provide a
librealtimethread, which could try to call your D-Bus service if it's
available, and otherwise fall back to the existing well-tested
approaches for various platforms (e.g. by generalising the code from
jackd).

You appear to be heading this way with your example client code in rtkit
anyway -- but please don't tell people to "copy these sources into your
repository", particularly when they contain such blatantly unportable
constructs as "#ifdef __linux__"! What it actually cares about is
whether the D-Bus client library is available, which'd be easy enough to
have a configure script test for.

You also need to be careful about licensing. The license status of D-Bus
-- at least, as of 1.2.14 -- is a mess: the daemon and libdbus-1 are
dual-licensed under the Academic Free License 2.1 and the GNU GPL v2
(only). rtkit-test.c claims to be GPL v3 or later, which isn't possible,
since neither the AFL 2.1 or the GPL v2-only are compatible with that
according to the FSF .
The best solution would be for the D-Bus folks to relicense their
client library under a more sensible permissive license...

(Incidentally, why the "-Kit" naming? There seem to be a few packages
like that around now, mostly providing a D-Bus service of some kind.)

Thanks,

-- 
Adam Sampson  
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Paul Davis
On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering wrote:
>
> The distinction between a thread/clone() and a process/fork() bomb
> doesn't really matter. What matters is that you can kill() processes
> and make the whole issue go away in one step even if that process has
> one gazillion threads and wants to create even more.

that was sort of my precisely my point. i only read your patch, i
didn't look at it in the context of the whole kernel. if indeed it
only applies to fork() and not to clone() calls that create threads
and not tasks, then its not really protecting against anything, is it?
however, from what i could see of the patch the no-inherit-RT property
belongs to the process, not a thread, and thus could not be reset by a
thread create call without wierd semantics.

so it appears to me that your patch still leaves the kernel open to a
thread-bomb ... am i wrong?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Paul Davis
On Sun, Jun 21, 2009 at 7:52 PM, Lennart Poettering 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 under

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

2009-06-21 Thread Lennart Poettering
On Mon, 22.06.09 01:55, Adam Sampson (a...@offog.org) wrote:

> I don't think it's a good idea to make the D-Bus interface the public
> API for this, because it assumes that you *can* write a D-Bus service
> that gives a thread in another process realtime priority (which is true
> for Linux, but not obviously so for other systems, even free ones). If
> you want to make it easier for people to write realtime applications, I
> think it'd be nicer -- and certainly more portable -- to provide a
> librealtimethread, which could try to call your D-Bus service if it's
> available, and otherwise fall back to the existing well-tested
> approaches for various platforms (e.g. by generalising the code from
> jackd).

I am Linux developer. My priority is Linux. 

rtkit is Linux-specific, internally it makes use of quite a few
Linux-only features. Which makes it very small and lean. I like it
that way. 
 
> You appear to be heading this way with your example client code in rtkit
> anyway -- but please don't tell people to "copy these sources into your
> repository", particularly when they contain such blatantly unportable
> constructs as "#ifdef __linux__"! What it actually cares about is
> whether the D-Bus client library is available, which'd be easy enough to
> have a configure script test for.

I guess one can't have one's cake and eat it too. 

I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call. Especially since this would be an extra dep to a lot of
software. D-Bus otoh is nowadays so deeply integrated into th system
(heck, we now have it in the init system itself, too, and there
has been work to add kernel code for socket(AF_DBUS)), that it's
available everywhere and on many projects a dep anyway.

Also, the reference client should compile fine on non-Linux, however
it will become a NOP and return ENOSUPP when you call it. I added this
precisely to allow compilation of the code on other OSes and
minimizing the ifdef orgies.

> You also need to be careful about licensing. The license status of D-Bus
> -- at least, as of 1.2.14 -- is a mess: the daemon and libdbus-1 are
> dual-licensed under the Academic Free License 2.1 and the GNU GPL v2
> (only).

Uh? To me it looks as if dbus was AFL/GPL2+ which a verified with a quick
grep over dbus' git repo.

How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
point me to where this is claimed?

>  rtkit-test.c claims to be GPL v3 or later, which isn't possible,
> since neither the AFL 2.1 or the GPL v2-only are compatible with that
> according to the FSF .
> The best solution would be for the D-Bus folks to relicense their
> client library under a more sensible permissive license...

dbus is GPL2+. When linked against the rkit daemon that gets
practically upgraded to GPL3. Problem solved.

> (Incidentally, why the "-Kit" naming? There seem to be a few packages
> like that around now, mostly providing a D-Bus service of some kind.)

Hehe, it's all davidz's fault.

Lennart

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


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

2009-06-21 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 01:55 +0100, Adam Sampson wrote:
> Lennart Poettering  writes:
> 
> > I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> > which will be enabled by default,
> 
> It would have been nice to see some mention of this on l-a-u/l-a-d
> earlier (i.e. while it was being designed), since getting realtime
> priority for audio applications is a problem that's been discussed and
> experimented with many times in this community. I'd imagine that most
> people reading this list are already using one of the existing solutions
> to this problem, and thus may be less delighted than you'd expect to
> have another mechanism dropped in their laps with no prior warning or
> chance to feed into the design process. ;-)

Count me in as being surprised. 

I would imagine it would be natural to include the LAD community in such
a discussion. If not _all_ of LAD, then I would imagine I would at least
invite the Jack developers to participate. If not _all_ of them, then at
least a small subset (the main developers). 

After all Jack users, developers, packagers, system administrators, etc,
have been dealing with this very same issue publicly for many many
years[*] and were part of previous discussions about this...

Oh well...
-- Fernando


[*] in my case since 2001 or so (when Planet CCRMA went public - but if
I remember correctly I was using realtime scheduling access methods for
non-root users at CCRMA even before that). 

My memory is fuzzy, but I may have the dubious distinction of being the
first to add a way to access SCHED_FIFO to jackd as a non-root user
using capabilities, as I needed that for CCRMA (based on code in, I
think, muse - or was it some other program?). A very ugly hack that
hopefully has been purged from the jack source code a long time ago :-)


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-21 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 02:01 +0200, Lennart Poettering wrote:
> On Sun, 21.06.09 16:06, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) 
> wrote:
> > > So what does RealtimeKit do that previous solutions didn't do? rtkit
> > > relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
> > > merged into Ingo's tree and will hence shortly appear in 2.6.31. 
> > 
> > So this is, at this point, kernel version dependent, right? 
> > What happens if you run a 2.6.29.x kernel?
> 
> Nothing. Then the call into rtkit will simply fail. Since the rtkit
> call is intended to be used as fallback only things will work as well
> or badly as they did before rtkit was introduced.
> 
> > The question is relevant, I think, as the kernels that I use (Planet
> > CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
> > think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
> > support is still far in the future). 
> 
> Dunno. I disagree. The primary objective for rtkit is to be able to
> run media applications as RT by default, out-of-the-box. I doubt that
> this feature matters for legacy distros/kernels.

I'm talking about the rt kernels specifically. In that context users
don't have a real choice as to what they get to run and the meaning of
legacy is different (I understand you may not care because of the target
audience of PA, but then again the RealtimeKit is being proposed as a
generic solution for access to rt scheduling). 

If the rt patch does not catch up fast enough then I may need to run a <
2.6.31 kernel (whatever is available at the time) in Fedora 12 when it
is released, hardly a legacy distro :-) 

(maybe unlikely, but it would not be the first time rt development
stalls for a looong time and you can't run the latest and greatest - not
complaining, just a fact)

> > > can set that flag when entering SCHED_RR scheduling and this will
> > > then make sure that after forking a child will be reset to
> > > SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
> > > out RT to a process we can be sure it won't "leak", and if we
> > > decide to take it away again we can be sure we can do that without
> > > having to be afraid of races around forking.
> > 
> > If I understand correctly then the mechanism would not be useful for
> > jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
> > actually gives rt priority to threads in other processes (the clients of
> > jack). But maybe things have changed in the way jack works internally
> > these days, or, possibly I'm not completely understanding the
> > implications... hm... jack does not do any forking right? 
> 
> Dunno. All processes that want to have rt need to ask rtkit
> themselves. (which is the only safe thing to do, only then we get the
> credentials properly defined)

We should try to find out what happens in Jack's case. 

It would be a __MAJOR__ step back if RealtimeKit is not usable by Jack
and it becomes the way distributions (and in particular Fedora) give
out-of-the-box access to rt scheduling. 

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Arnold Krille
On Monday 22 June 2009 02:09:36 Lennart Poettering wrote:
> Doing authorization via groups is broken,

What??? Did you ever do administration for more then one computer??? 
Authorization by groups is _the only_ way to go if you have more then one user 
to authorize for anything.
If you don't agree ask firms with intranets and net-wide authorization, look at 
yp/nis/ldap/Active Directory.

> since practically you can
> never take group membership away.

Yes, you can. Just remove the person from a group and the next time the groups 
are checked for that user, the rights are gone.

Arnold, still trying to understand why any distribution should now use 
RealtimeKit after not really using rtlimits in PAM (except for the new run for 
"Kits")


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Adam Sampson
Lennart Poettering  writes:

> I am Linux developer. My priority is Linux.

That's nice, but most of us developers don't have the luxury of being
able to forget about portability. I've spent quite a bit of effort
packaging software for other free operating systems, and there's already
a widespread (and largely justified) stereotype that Linux developers
don't write portable code. Please don't contribute to the problem.

> I don't think it is worth creating a tiny mini library that I'd need
> to maintain and everyone depend on for just one (or two) little
> function call. Especially since this would be an extra dep to a lot of
> software.

But instead you're proposing adding two dependencies (the D-Bus client
library and the RealtimeKit service), and having everybody who wants to
use it copy a large chunk of code into their project. I don't see how
that's a simpler option than providing a library interface; it's
certainly not simpler to write a configure test for.

> Also, the reference client should compile fine on non-Linux, however
> it will become a NOP and return ENOSUPP when you call it.

Whether the kernel is Linux or not is completely irrelevant for a
program trying to get realtime priority using your service. What matters
is whether D-Bus is available. Suppose I go away and implement your
realtime service for FreeBSD; because of that #ifdef, I now need to go
and patch every application that's copied your code before it'll work.

If the API were a library, like essentially every other API on a modern
Unix-like system, then I'd only have to change the library to add
support for new platforms and mechanisms, and I'd be able to support
systems where asking another process to increase your privileges isn't
the right way to do things.

> How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
> point me to where this is claimed?

It's stated clearly in the COPYING file for D-Bus: "D-Bus is licensed to
you under your choice of the Academic Free License version 2.1, or the
GNU General Public License version 2." If that isn't their intent, it
needs fixing.

-- 
Adam Sampson  
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Bob Ham
On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:

> this offers an API of
> two tiny functions.

> And rtkit is just a tiny piece of software that only requires minimal
> additions to client code to be useful.

On Mon, 2009-06-22 at 03:31 +0200, Lennart Poettering wrote: 
> On Mon, 22.06.09 01:55, Adam Sampson (a...@offog.org) wrote:
> 
> > If
> > you want to make it easier for people to write realtime applications, I
> > think it'd be nicer -- and certainly more portable -- to provide a
> > librealtimethread

> I don't think it is worth creating a tiny mini library that I'd need
> to maintain and everyone depend on for just one (or two) little
> function call.


There's something wrong here.


-- 
Bob Ham 

for (;;) { ++pancakes; }


signature.asc
Description: This is a digitally signed message part
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Chris Cannam
On Sun, Jun 21, 2009 at 4:09 PM, Paul Davis wrote:
> Finally, as Chris said -
> many of us are writing apps that target multiple platforms

Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience.  Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using.  PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 09:33, Arnold Krille (arn...@arnoldarts.de) wrote:

> On Monday 22 June 2009 02:09:36 Lennart Poettering wrote:
> > Doing authorization via groups is broken,
> 
> What??? Did you ever do administration for more then one computer??? 
> Authorization by groups is _the only_ way to go if you have more then one 
> user 
> to authorize for anything.
> If you don't agree ask firms with intranets and net-wide authorization, look 
> at 
> yp/nis/ldap/Active Directory.

Please read up on PoliyKit. What it does, and why it has been
introduced. 

You practically cannot take group membership away from a user after
you gave it to him, and also adding a seperate group for every tiny
bit you need to authorize access to doesn't scale.

> > since practically you can
> > never take group membership away.
> 
> Yes, you can. Just remove the person from a group and the next time the 
> groups 
> are checked for that user, the rights are gone.

Except that this doesn't work.

http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 08:52, Adam Sampson (a...@offog.org) wrote:

> 
> Lennart Poettering  writes:
> 
> > I am Linux developer. My priority is Linux.
> 
> That's nice, but most of us developers don't have the luxury of being
> able to forget about portability. I've spent quite a bit of effort
> packaging software for other free operating systems, and there's already
> a widespread (and largely justified) stereotype that Linux developers
> don't write portable code. Please don't contribute to the problem.

Really, I see not much value in supporting more than one kernel. That
just means reinventing the wheel over and over. If others care, fine
for them. 

> > I don't think it is worth creating a tiny mini library that I'd need
> > to maintain and everyone depend on for just one (or two) little
> > function call. Especially since this would be an extra dep to a lot of
> > software.
> 
> But instead you're proposing adding two dependencies (the D-Bus client
> library and the RealtimeKit service), and having everybody who wants to
> use it copy a large chunk of code into their project. I don't see how
> that's a simpler option than providing a library interface; it's
> certainly not simpler to write a configure test for.

This is bogus. There is no dependency on rtkit here. if during runtime
the rtkit service is found it is used. If it is not found it isn't
used. end of story.

There is not compile time dependency on rtkit and no runtime
dependency either.

If I had introduced my own little library everyone would have to link
to it. However this way they just have to depend on dbus, which is
something many applications link to any way. So this way there is many
cae no dependency added at all. And the build is certainly easier.

Also, the client reference implementation is tiny. it just wraps two
method calls. Trivial stuff.

> > How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
> > point me to where this is claimed?
> 
> It's stated clearly in the COPYING file for D-Bus: "D-Bus is licensed to
> you under your choice of the Academic Free License version 2.1, or the
> GNU General Public License version 2." If that isn't their intent, it
> needs fixing.

Then file a bug. 

The .c/.h files are pretty explicit. Ever single file one has the
GPLv2+ blurb in it.

Lennart

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


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

2009-06-22 Thread Fons Adriaensen
On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote:

> There's something wrong here.

There is a lot wrong here.


* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ? In the latter case this
system is not only broken, but should be classified as malware.

* Why should an app running on an headless system at RL3 be forced
to go through a collection of desktop-oriented daemons in order to
do something that amounts to a simple POSIX system call ?

* Claiming that 'group based security is broken' is not only
a show of ignorance, but also of arrogance. All UNIX sysadmins
of the last 30 years must have been idiots. 

* I don't run a 'desktop' on any machine, nor do I want one.
The thing I'm looking at is a computer screen, and that's it.
I want to remain the master of my system, whatever I do is
by definition to be trusted. This includes running RT threads 
that may block the machine. I'm not married into the Kit 
family, and the last thing I want is this collection of 
mothers-in-law interfering with my system. If the the desktop
kids want this sort of thing that's fine. Let them build it
into their desktops, but keep it out of the operating system.  

* All this talk from the freedesktop crowd about 'security'
is as misleading as it can be, *All* security violations
I've seeen lately on any of my systems were generated by
these desktop madness. This includes:

  - Gdm making unauthorised network connections (disable
DNS and see it hang for two minutes).

  - Login manangers changing device permissions.

  - Gnome automounting removable disks that don't have 
the 'user' flags set in /etc/fstab.

  - Digital camera software making unauthorised copies
of pictures to the local hard disk.

And more. This is 'big brother' security - basically
it means: 'trust us, we want the best for you, and are
trying to make your life easy'.

* If this trend continues then within a year or two 
there will some 'FilesystemKit' that requires the OK
from freedesktop.org each time you open a file. And
no doubt also a 'DecencyKit' checking the color of 
your underwear.

* It is IHMO high time to start the development of a
kernel patch that removes all of this, and provides a 
clean POSIX system to those who want it.

Ciao,


-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Sun, 21.06.09 20:58, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> > > The question is relevant, I think, as the kernels that I use (Planet
> > > CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
> > > think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
> > > support is still far in the future). 
> > 
> > Dunno. I disagree. The primary objective for rtkit is to be able to
> > run media applications as RT by default, out-of-the-box. I doubt that
> > this feature matters for legacy distros/kernels.
> 
> I'm talking about the rt kernels specifically. In that context users
> don't have a real choice as to what they get to run and the meaning of
> legacy is different (I understand you may not care because of the target
> audience of PA, but then again the RealtimeKit is being proposed as a
> generic solution for access to rt scheduling). 
> 
> If the rt patch does not catch up fast enough then I may need to run a <
> 2.6.31 kernel (whatever is available at the time) in Fedora 12 when it
> is released, hardly a legacy distro :-) 
> 
> (maybe unlikely, but it would not be the first time rt development
> stalls for a looong time and you can't run the latest and greatest - not
> complaining, just a fact)

Again, the worst thing that happens is that you need to bump
RLIMIT_RTPRIO for your user, as you always did. rtkit doesn't take
that away. 

Summary:

Kernel that lacks SCHED_RESET_ON_FORK: RLIMIT_RTPRIO is what matters.

Kernel that has SCHED_RESET_ON_FORK: RLIMIT_RTPRIO still matters when
it is set, rtkit is used as fallback.

Also note that supporting rtkit often enough doesn't add a build-time
dep to you application and the runtime dependency is very soft too: if
it isn't found it's not used, that's all.

> > > > can set that flag when entering SCHED_RR scheduling and this will
> > > > then make sure that after forking a child will be reset to
> > > > SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
> > > > out RT to a process we can be sure it won't "leak", and if we
> > > > decide to take it away again we can be sure we can do that without
> > > > having to be afraid of races around forking.
> > > 
> > > If I understand correctly then the mechanism would not be useful for
> > > jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
> > > actually gives rt priority to threads in other processes (the clients of
> > > jack). But maybe things have changed in the way jack works internally
> > > these days, or, possibly I'm not completely understanding the
> > > implications... hm... jack does not do any forking right? 
> > 
> > Dunno. All processes that want to have rt need to ask rtkit
> > themselves. (which is the only safe thing to do, only then we get the
> > credentials properly defined)
> 
> We should try to find out what happens in Jack's case. 

In JACK's sources the only place where I see fiddling with the
scheduler is in jack_acquire_real_time_scheduling(), which takes a
pthread_t. pthread_t is process local, so I am pretty sure JACK
doesn't try to change scheduling of out-of-process threads. This
should hence be perfectly compatible with the rtkit model.

Lennart

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


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

2009-06-22 Thread Chris Cannam
On Mon, Jun 22, 2009 at 1:58 PM, Lennart Poettering wrote:
> Also, the client reference implementation is tiny. it just wraps two
> method calls. Trivial stuff.

You're referring here to the code at
http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.c ?  That's not
trivial.  I appreciate that it's not difficult to cut and paste, but
still it's a pretty substantial replacement for one system call.
Surprisingly so, to me, having read much of the discussion before
looking at the code.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Chris Cannam
On Mon, Jun 22, 2009 at 2:05 PM, Fons Adriaensen wrote:
> * Why should an app running on an headless system at RL3 be forced
> to go through a collection of desktop-oriented daemons in order to
> do something that amounts to a simple POSIX system call ?

I do think this is a rather unfair objection.  Clearly the whole idea
here is to make this mechanism work better in a "desktop" context.
Applications on your properly configured headless system shouldn't
need to use this method at all.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 15:05, Fons Adriaensen (f...@kokkinizita.net) wrote:

> 
> On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote:
> 
> > There's something wrong here.
> 
> There is a lot wrong here.
> 
> * Question: is the 'demoting' of RT-threads applied only to RT
> threads granted by this daeomon, or does it apply to all, including
> those created by processes running as root ? In the latter case this
> system is not only broken, but should be classified as malware.

Is that so?

It can do both. resetting all is the default.

> * Why should an app running on an headless system at RL3 be forced
> to go through a collection of desktop-oriented daemons in order to
> do something that amounts to a simple POSIX system call ?

It shouldn't. 

Quoting myself from the announcement: "If you don't do RT development
or doing RT development only for embedded cases, ... then it doesn't
mean anything for you."

rtkit is only relevant for the desktop. end of story.

A "collection of desktop-oriented daemons"? Do I smell D-Bus fud
again? This is getting so old. And stays so wrong. D-Bus is deeply
rooted in system now, even the init system speaks it now. Get over it
already.

> * Claiming that 'group based security is broken' is not only
> a show of ignorance, but also of arrogance. All UNIX sysadmins
> of the last 30 years must have been idiots. 

Oh my. Just because someone mentions that UNIX has issues you don't
have to call him "ignorant" and "arrogant".

Also, it's not me who declared that UNIX groups are broken. That's a
fight others have sucessfully fought through the distros
already. PolicyKit entered all major distributions. 

If you think that UNIX is the only true verity and think that pk is an
abomination then bring that up with the pk guys, not with me. 

> * I don't run a 'desktop' on any machine, nor do I want one.
> The thing I'm looking at is a computer screen, and that's it.
> I want to remain the master of my system, whatever I do is
> by definition to be trusted. This includes running RT threads 
> that may block the machine. I'm not married into the Kit 
> family, and the last thing I want is this collection of 
> mothers-in-law interfering with my system. If the the desktop
> kids want this sort of thing that's fine. Let them build it
> into their desktops, but keep it out of the operating system.  

Then don't do it. You are clearly not the intended audience of rtkit
then. 

Have you actually read my announcement mail? This stuff is only useful
for out-of-the-box RT support on major distributions. If you roll
everything your own, because that makes you happy, then ignore rtkit.

Also, rtkit is just an offer. No need to adopt it if you think it is
an abomination. But if you do care that your software performs well
out-of-the-box on newer distros then think about it. The API is there,
you just make use of it.

> * All this talk from the freedesktop crowd about 'security'
> is as misleading as it can be, *All* security violations
> I've seeen lately on any of my systems were generated by
> these desktop madness. This includes:

Yes, we hate security. And it is our declared objective to make your
life miserable. Surprised?

> * If this trend continues then within a year or two 
> there will some 'FilesystemKit' that requires the OK
> from freedesktop.org each time you open a file. And
> no doubt also a 'DecencyKit' checking the color of 
> your underwear.

Didn't you know, it's world domination we are going for! We want to
control your computer and then you, muhahaha. And we take away your
freedoms. And creating a working desktop is just our cover for
this. Muahahahaah!  Muahahahahaahah!

> * It is IHMO high time to start the development of a
> kernel patch that removes all of this, and provides a 
> clean POSIX system to those who want it.

Yes, do it! Not sure what exactly you want to patch out. But please do
it!

Lennart

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


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

2009-06-22 Thread Paul Davis
Lennart, I am still trying to understand what the basic rationale is
here. 3 years ago, the kernel mailing discussed RT scheduling and
decided that RLIMIT_RTPRIO was the way to handle access to this
capability. That decision was made knowing that some user-space
infrastructure would be necessary to make it usable for most
end-users. So, 3 years on, that user space infrastructure hasn't been
created, and now your proposed solution is to provide a different
method of accessing RT scheduling. Are you arguing/suggesting that the
user-space infrastructure will never be created because of the
security issues? Are you suggesting that the original decision to
focus on RLIMIT_RTPRIO was a mistake that didn't take "the reality of
what mainstream distros will do" into account?

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fons Adriaensen
On Mon, Jun 22, 2009 at 03:38:01PM +0200, Lennart Poettering wrote:

> > In the latter case this
> > system is not only broken, but should be classified as malware.
> 
> Is that so?

If something supposedly 'only relevant for the desktop' (your words)
interferes with thing that are not related to the desktop, yes.


> > * Why should an app running on an headless system at RL3 be forced
> > to go through a collection of desktop-oriented daemons in order to
> > do something that amounts to a simple POSIX system call ?
> 
> It shouldn't. 

Then it shouldn't ever. A desktop is just another application.

> A "collection of desktop-oriented daemons"? Do I smell D-Bus fud
> again? 

If I write 'a collection of desktop-oriented daemons' then I mean
exactly that. You have confirmed many times that is what they are.

> Oh my. Just because someone mentions that UNIX has issues you don't
> have to call him "ignorant" and "arrogant".

There is a world of difference between saying that UNIX has issues
and saying that group based security is broken. You could as well
say that wheel based transport is broken,

> PolicyKit entered all major distributions. 

The only thing required for that it to ensure it becomes a 
dependency for Gnome. This will work for anything you want
and it does not demonstrate or imply any qualities.

> If you think that UNIX is the only true verity and think that pk is an
> abomination then bring that up with the pk guys, not with me. 

I didn't bring it up with you.

> Have you actually read my announcement mail? This stuff is only useful
> for out-of-the-box RT support on major distributions. If you roll
> everything your own, because that makes you happy, then ignore rtkit.

I will ignore it, also as an author. Or tell me why a RT DSP library
(which may create RT threads) should depened on any desktop-oriented
daemons.
 
> Yes, we hate security. And it is our declared objective to make your
> life miserable. Surprised?

Do you have a sensible answer to the four example issues I raised ?

> Didn't you know, it's world domination we are going for! We want to
> control your computer and then you, muhahaha. And we take away your
> freedoms. And creating a working desktop is just our cover for
> this. Muahahahaah!  Muahahahahaahah!

Your words. I'm not suggesting anything like such a conspiracy.
But history shows over and over again that those who want to impair
freedom will deny their intentions. So your denial is as irrelevant
as your attempt to make me say things I didn't say.


Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Sun, 21.06.09 21:16, Paul Davis (p...@linuxaudiosystems.com) wrote:

> 
> On Sun, Jun 21, 2009 at 7:52 PM, Lennart Poettering 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.

Bac

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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 16:34, Fons Adriaensen (f...@kokkinizita.net) wrote:

> > A "collection of desktop-oriented daemons"? Do I smell D-Bus fud
> > again? 
> 
> If I write 'a collection of desktop-oriented daemons' then I mean
> exactly that. You have confirmed many times that is what they are.

rtkit is just one little bus-activated service. Not sure where you see
a "collection of daemons".

> > Oh my. Just because someone mentions that UNIX has issues you don't
> > have to call him "ignorant" and "arrogant".
> 
> There is a world of difference between saying that UNIX has issues
> and saying that group based security is broken. You could as well
> say that wheel based transport is broken,

But group-bases access *is* broken. I mean, I am sorry if that hurts
your feelings, but uh, it's just the way it is.

> > PolicyKit entered all major distributions. 
> 
> The only thing required for that it to ensure it becomes a 
> dependency for Gnome. This will work for anything you want
> and it does not demonstrate or imply any qualities.

FUD, FUD. FUD. FUD. FUD. FUD. FUD. And FUD.

KDE adopted it too. And quite a few system daemons too.

Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Sun, 21.06.09 21:02, Paul Davis (p...@linuxaudiosystems.com) wrote:

> 
> On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering wrote:
> >
> > The distinction between a thread/clone() and a process/fork() bomb
> > doesn't really matter. What matters is that you can kill() processes
> > and make the whole issue go away in one step even if that process has
> > one gazillion threads and wants to create even more.
> 
> that was sort of my precisely my point. i only read your patch, i
> didn't look at it in the context of the whole kernel. if indeed it
> only applies to fork() and not to clone() calls that create threads
> and not tasks, then its not really protecting against anything, is it?
> however, from what i could see of the patch the no-inherit-RT property
> belongs to the process, not a thread, and thus could not be reset by a
> thread create call without wierd semantics.
> 
> so it appears to me that your patch still leaves the kernel open to a
> thread-bomb ... am i wrong?

What SCHED_RESET_ON_FORK fixes is that a process cannot fork() (as in
process) to evade the kill() of a supervisor process.

Without this flag you always have a race where the killer process
would have a hard time killing a process that is duplicating itself
exponentially.

What matter is that to put an end to the thread bomb process all we
need to do is one call to kill(). 

Lennart

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


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

2009-06-22 Thread Adam Sampson
Lennart Poettering  writes:

> Really, I see not much value in supporting more than one kernel.

I find this statement surprising, having found that testing on multiple
operating systems is an excellent way of finding subtle bugs in code.
(I assume you're just talking about RealtimeKit here and not PulseAudio
as a whole, since there are clear advantages to making that available to
as large a userbase as possible if you want it to be widely adopted...)

> There is not compile time dependency on rtkit and no runtime
> dependency either.

Yes, there is a runtime dependency on RealtimeKit -- else there would be
no point in having it in the first place! If I'm building an operating
system package for an application that wants realtime priority, then my
package has to have an explicit dependency on RealtimeKit as well as
D-Bus.

> Also, the client reference implementation is tiny. it just wraps two
> method calls. Trivial stuff.

It's neither trivial nor tiny -- rtkit.c is a bit over a hundred
non-comment/blank lines of code. The entirety of thread.c in libjack
(which handles getting realtime priority on a variety of operating
systems, among other things) is less than two hundred. This should be in
a library, *not* copied-and-pasted into multiple places; that's a
maintenance nightmare waiting to happen.

I should be clearer here that I think the RealtimeKit approach is
actually pretty sensible on Linux, and I don't have any objections to
using D-Bus. I just think it's important to recognise that this approach
is not appropriate for all platforms, and providing a more conventional
library interface would be more convenient for programmers, more
portable, and generally better software engineering practice.

> Then file a bug.

I have done. I wasn't aware that it *was* a bug until you commented on
it; I'm used to trusting packages' explicit statements in their
documentation about their licenses. (Looking at license statements in
headers is not sufficient; as in RealtimeKit, it's very common to have
different licenses applying to different files, or dependencies on
libraries which end up restricting the license of the overall package.)

Thanks,

-- 
Adam Sampson  
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 10:08, Paul Davis (p...@linuxaudiosystems.com) wrote:

> 
> Lennart, I am still trying to understand what the basic rationale is
> here. 3 years ago, the kernel mailing discussed RT scheduling and
> decided that RLIMIT_RTPRIO was the way to handle access to this
> capability. That decision was made knowing that some user-space
> infrastructure would be necessary to make it usable for most
> end-users. So, 3 years on, that user space infrastructure hasn't been
> created, and now your proposed solution is to provide a different
> method of accessing RT scheduling. Are you arguing/suggesting that the
> user-space infrastructure will never be created because of the
> security issues? 

What exactly are you asking for as "user-space infrastructure"? Some
easy to reach UI that will allow you to make yourself a member of some
group? This is unlikely to happen. At least not from the desktop
camp. 

I mean, rtkit is user-space infrastructure, so what are you asking for
that isn't covered by rtkit?

> Are you suggesting that the original decision to focus on
> RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
> mainstream distros will do" into account?

Yes. I guess you can say that. Although I wouldn't call it a
"mistake". RLIMIT_RTPRIO was added with audio production in
mind. While I think even then it sucks UI-wise, it certainly was good
enough and better than anything there was before. 

However, as soon as we want to make RT available out-of-the-box
RLIMIT_RTPRIO just doesn't cut it.

Lennart

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


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

2009-06-22 Thread Fons Adriaensen
On Mon, Jun 22, 2009 at 05:20:28PM +0200, Lennart Poettering wrote:

> FUD, FUD. FUD. FUD. FUD. FUD. FUD. And FUD.

Sounds like our prime minister: "Communists ! Communists !
Communists !". His standard answer to all critics. Even
the Financial Times is communist.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 16:34, Adam Sampson (a...@offog.org) wrote:

> > There is not compile time dependency on rtkit and no runtime
> > dependency either.
> 
> Yes, there is a runtime dependency on RealtimeKit -- else there would be
> no point in having it in the first place! If I'm building an operating
> system package for an application that wants realtime priority, then my
> package has to have an explicit dependency on RealtimeKit as well as
> D-Bus.

No.

rtkit is just an option. If distros install it, then you can use
it. If they don't then don't. The reference client code will magically
start to work if rtkit is around. If it isn't then there's still
RLIMIT_RTPRIO.

Really, there is no dependency.

> > Also, the client reference implementation is tiny. it just wraps two
> > method calls. Trivial stuff.
> 
> It's neither trivial nor tiny -- rtkit.c is a bit over a hundred
> non-comment/blank lines of code. The entirety of thread.c in libjack
> (which handles getting realtime priority on a variety of operating
> systems, among other things) is less than two hundred. This should be in
> a library, *not* copied-and-pasted into multiple places; that's a
> maintenance nightmare waiting to happen.

The reference implementation is relatively verbose, because it is
... a reference implementation. You can implement the real-time method
invocation in one call to dbus_message_new_method_call() followed by
dbus_message_append_args(), followed by
dbus_connection_send_with_reply_and_block(). Done.

> I should be clearer here that I think the RealtimeKit approach is
> actually pretty sensible on Linux, and I don't have any objections to
> using D-Bus. I just think it's important to recognise that this approach
> is not appropriate for all platforms, and providing a more conventional
> library interface would be more convenient for programmers, more
> portable, and generally better software engineering practice.

I guess we have to agree to disagree here then.

Lennart

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


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

2009-06-22 Thread Paul Davis
On Mon, Jun 22, 2009 at 11:34 AM, Lennart Poettering wrote:
> What exactly are you asking for as "user-space infrastructure"? Some
> easy to reach UI that will allow you to make yourself a member of some
> group? This is unlikely to happen. At least not from the desktop
> camp.

Well, this is precisely what was imagined when RLIMIT_RTPRIO was added
to the kernel. Even by Ingo :) And no, you don't need to be a member
of a group - limits.conf can grant access on a per-user basis.

What I mean by infrastructure are tools to make RLIMIT_RTPRIO settings
easily configurable by the user. Its still not clear to me how this
works in the case of RTKit either.

>> Are you suggesting that the original decision to focus on
>> RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
>> mainstream distros will do" into account?
>
> Yes. I guess you can say that. Although I wouldn't call it a
> "mistake". RLIMIT_RTPRIO was added with audio production in
> mind.

This just isn't true!  We had an earlier solution that was working OK
for audio production purposes BUT the kernel folks and embedded linux
developers were not happy about it. RLIMIT_RTPRIO was the result of
some quite extensive and at times heated discussion about how to
replace the old mechanism (based on kernel "capabilities" which have
now mostly gone away) with something else that would work for everyone
that had a stake in the outcome.

> However, as soon as we want to make RT available out-of-the-box
> RLIMIT_RTPRIO just doesn't cut it.

I'm sorry, I'm still not grasping the idea. Or maybe I am. You're
arguing that because we (will likely) have an RT-sched reset-on-fork
flag, that its now safe to grant RT scheduling permission by default?
First of all, I would dispute that this makes it "safe" in the sense
you want it to. By this I mean that although theoretically a clone
bomb would be stoppable with a kill(2) call, practically speaking the
machine would be rendered unusable by a suitable clone bomb attack.
That is - without the very things that you say we can't provide right
now - watchdogs, resource reservation scheduling (not isochronous),
and more. Secondly, if this flag is all that is needed to make it safe
to grant RT scheduling by default, why is RTKit needed at all?
Finally, you seem to continue assuming that SCHED_RR is the only
scheduling class of interest, which is by no means settled among the
various communities that use RT scheduling.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 11:53, Paul Davis (p...@linuxaudiosystems.com) wrote:

> 
> On Mon, Jun 22, 2009 at 11:34 AM, Lennart Poettering wrote:
> > What exactly are you asking for as "user-space infrastructure"? Some
> > easy to reach UI that will allow you to make yourself a member of some
> > group? This is unlikely to happen. At least not from the desktop
> > camp.
> 
> Well, this is precisely what was imagined when RLIMIT_RTPRIO was added
> to the kernel. Even by Ingo :) And no, you don't need to be a member
> of a group - limits.conf can grant access on a per-user basis.
> 
> What I mean by infrastructure are tools to make RLIMIT_RTPRIO settings
> easily configurable by the user. Its still not clear to me how this
> works in the case of RTKit either.

This is really the wrong approach. And no other OS does it. Really, how
would you find it if you install Fedora and one of the questions
during installation is whether you want to bump RLIMIT_RTPRIO for your
user, or not? Which user understands what "realtime" means anyway? My
mom certainly doesn't.

Sometimes, there is a bit of disconnect between what kernel folks
think is a good idea and what userspace folks think is one. [Which
(hint hint!) is precisely the reason why plumbers conf is so important
as an attempt to bridge that gap!]
 
> >> Are you suggesting that the original decision to focus on
> >> RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
> >> mainstream distros will do" into account?
> >
> > Yes. I guess you can say that. Although I wouldn't call it a
> > "mistake". RLIMIT_RTPRIO was added with audio production in
> > mind.
> 
> This just isn't true!  We had an earlier solution that was working OK
> for audio production purposes BUT the kernel folks and embedded linux
> developers were not happy about it. RLIMIT_RTPRIO was the result of
> some quite extensive and at times heated discussion about how to
> replace the old mechanism (based on kernel "capabilities" which have
> now mostly gone away) with something else that would work for everyone
> that had a stake in the outcome.

Back then audio and embedded realtime folks had a stake in the
outcome. Desktop folks did not, but apparently were expected to add
the "simple" UI for that? I mean, complaining that I now mostly kept
lad out of the loop is not entirely fair if back then you kept desktop
folks out of the loop...

(As a side note: capabilities are still there and doing better than
ever.)

> > However, as soon as we want to make RT available out-of-the-box
> > RLIMIT_RTPRIO just doesn't cut it.
> 
> I'm sorry, I'm still not grasping the idea. Or maybe I am. You're
> arguing that because we (will likely) have an RT-sched reset-on-fork
> flag, that its now safe to grant RT scheduling permission by
> default?

I am arguing that if you have that flag you can set it when handing out
rt sched to other processes in a supervised fashion and be sure that
the process cannot escape your supervision.

> First of all, I would dispute that this makes it "safe" in the sense
> you want it to. By this I mean that although theoretically a clone
> bomb would be stoppable with a kill(2) call, practically speaking the
> machine would be rendered unusable by a suitable clone bomb attack.
> That is - without the very things that you say we can't provide right
> now - watchdogs, 

As mentioned rtkit implements a watchdog, too. A watchdog however is
an a-posteriori solution to the problem. I.e. when things already
wrong it can be used to fix things up again. rtkit otoh tries to focus
on a-priori solutions, making sure that users cannot misuse RT in the
first place.

Please, please with cream on top, read rtkit's README:

http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

Starting at line 39 is the part about watchdogs.

It also roughly explains the problems with the various other
approaches that were tried before.

> resource reservation scheduling (not isochronous),
> and more. Secondly, if this flag is all that is needed to make it safe
> to grant RT scheduling by default, why is RTKit needed at all?

Because it fixes the problem that is "escaping supervision". Without
the patch a process can easily escape supervision or at least play
race games with the supervisor. rtkit is the supervisor.

> Finally, you seem to continue assuming that SCHED_RR is the only
> scheduling class of interest, which is by no means settled among the
> various communities that use RT scheduling.

I have now changed rtkit to make the policy configurable system
wide. I believe the sched policy should be a choice for the admin, not
the developer, as it controls fairness of different RT software to
each other.

And again, as I already offered: if someone offers a good real-world
case then we can make the sched policy controllable from the client
side, too, and even the RR qantum, if that's really needed.

However, unless anyone makes a good case how this matters for desktop
applicatios I'd like to start small.

Lennart

-- 

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

2009-06-22 Thread Fons Adriaensen
On Mon, Jun 22, 2009 at 05:14:00PM +0100, Krzysztof Foltman wrote:

> You're not ignoring it, you're practically waging the war against it,

Ever seen a real war ?

> The existence of rtkit doesn't make it harder for you to assign RT
> privileges to every process on the machine. However, it makes it
> possible to prevent rogue processes from obtaining/abusing the RT
> scheduling while letting user-approved processes to still use it.

Which rogue processes ? What was the last time you've seen a
RT-bomb ? Why did you run it ?

And anyay this thing protects against nothing at all.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Krzysztof Foltman
Fons Adriaensen wrote:

>> Have you actually read my announcement mail? This stuff is only useful
>> for out-of-the-box RT support on major distributions. If you roll
>> everything your own, because that makes you happy, then ignore rtkit.
> I will ignore it, also as an author. Or tell me why a RT DSP library
> (which may create RT threads) should depened on any desktop-oriented
> daemons.

You're not ignoring it, you're practically waging the war against it,
effectively trying to make life more miserable for the desktop users
(yes, like me for example). Why?

The existence of rtkit doesn't make it harder for you to assign RT
privileges to every process on the machine. However, it makes it
possible to prevent rogue processes from obtaining/abusing the RT
scheduling while letting user-approved processes to still use it. In
some contexts, asking the users to give up every single application a
dangerous permission just to let them run your application, is a bad
idea (it makes any other application in the system capable of locking up
the PC without the chance of preventing it).

Okay, it uses a commonly available message passing infrastructure
(D-Bus) instead of reinventing the wheel. So what? Is one way of sending
messages to other processes somehow bad because it's an Evil Baby-Eating
D-Bus? POSIX is Good, FreeDesktop is Evil, since when? What's the
reasoning behind THAT?

Krzysztof

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Krzysztof Foltman
Fons Adriaensen wrote:

>> You're not ignoring it, you're practically waging the war against it,
> Ever seen a real war ?

Your point being?

>> The existence of rtkit doesn't make it harder for you to assign RT
>> privileges to every process on the machine. However, it makes it
>> possible to prevent rogue processes from obtaining/abusing the RT
>> scheduling while letting user-approved processes to still use it.
> Which rogue processes ? What was the last time you've seen a
> RT-bomb ? Why did you run it ?

"When was the last time you've seen a Microsoft Word virus? Why did you
open it?" was probably some Microsoft manager's thinking more than
decade ago.

With the increasing number of Linux-based systems sold to novice users,
you're sure nobody will ever use RT API to do something nasty?

Basically, Lennart pointed out a potential security hole and shown a way
to fix it. The fact that it's not abused yet (mostly due to lack of
popularity of RT kernels) doesn't mean it won't be abused ever.
Especially if things like pulseaudio and games will making use of RT
privileges.

Krzysztof
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Jens M Andreasen
Since it is rogue processes - from the interweb? - rather than rough
users that are the potential problem, wouldn't the cure then be to grant
certain trusted applications RT-privileges?

A novice user would install well-known binaries from the distros
repository. The binary runs as user 'rt-audio' which is the only/one of
the few users on the system granted rt privileges.

jackd would be a single instance for all.

/j


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 17:58 +0100, Krzysztof Foltman wrote:
> Fons Adriaensen wrote:
> 
> >> You're not ignoring it, you're practically waging the war against it,
> > Ever seen a real war ?
> 
> Your point being?
> 
> >> The existence of rtkit doesn't make it harder for you to assign RT
> >> privileges to every process on the machine. However, it makes it
> >> possible to prevent rogue processes from obtaining/abusing the RT
> >> scheduling while letting user-approved processes to still use it.
> > Which rogue processes ? What was the last time you've seen a
> > RT-bomb ? Why did you run it ?
> 
> "When was the last time you've seen a Microsoft Word virus? Why did you
> open it?" was probably some Microsoft manager's thinking more than
> decade ago.
> 
> With the increasing number of Linux-based systems sold to novice users,
> you're sure nobody will ever use RT API to do something nasty?
> 
> Basically, Lennart pointed out a potential security hole and shown a way
> to fix it. The fact that it's not abused yet (mostly due to lack of
> popularity of RT kernels) 

Just a detail, but the issue at hand has nothing to do with the
popularity of rt kernels (ie: kernels patched with the rt patch), but
with allowing non-root users access to schedulers other than
SCHED_OTHER. That can happen with all current kernels. 

-- Fernando


> doesn't mean it won't be abused ever.
> Especially if things like pulseaudio and games will making use of RT
> privileges.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 15:38 +0200, Lennart Poettering wrote:
> On Mon, 22.06.09 15:05, Fons Adriaensen (f...@kokkinizita.net) wrote:
> 
> > 
> > On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote:
> > 
> > > There's something wrong here.
> > 
> > There is a lot wrong here.
> > 
> > * Question: is the 'demoting' of RT-threads applied only to RT
> > threads granted by this daeomon, or does it apply to all, including
> > those created by processes running as root ? In the latter case this
> > system is not only broken, but should be classified as malware.
> 
> Is that so?
> 
> It can do both. resetting all is the default.

Good question. 

Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

(I assume, for example, that it would not under any circumstances reset
the scheduler of the kernel interrupt processes in an rt patched
kernel!!)

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 19:59, Jens M Andreasen (jens.andrea...@comhem.se) wrote:

> 
> Since it is rogue processes - from the interweb? - rather than rough
> users that are the potential problem, wouldn't the cure then be to grant
> certain trusted applications RT-privileges?
> 
> A novice user would install well-known binaries from the distros
> repository. The binary runs as user 'rt-audio' which is the only/one of
> the few users on the system granted rt privileges.

But uh, that app could then not access the starting user's file in any
way. 

There is no such thing a trusted user applications. And I don't think
we want to go down the road to sandboxing for this.

Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> 
> On Mon, 2009-06-22 at 15:38 +0200, Lennart Poettering wrote:
> > On Mon, 22.06.09 15:05, Fons Adriaensen (f...@kokkinizita.net) wrote:
> > 
> > > 
> > > On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote:
> > > 
> > > > There's something wrong here.
> > > 
> > > There is a lot wrong here.
> > > 
> > > * Question: is the 'demoting' of RT-threads applied only to RT
> > > threads granted by this daeomon, or does it apply to all, including
> > > those created by processes running as root ? In the latter case this
> > > system is not only broken, but should be classified as malware.
> > 
> > Is that so?
> > 
> > It can do both. resetting all is the default.
> 
> Good question. 
> 
> Why is it resetting all the default, even processes with rt privileges
> not granted by RealtimeKit? Isn't rtkit supposed to be the only
> authorized way to access schedulers other that SCHED_OTHER by non-root
> users?

rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work.

Even if some folks seem to believe it, I am not replacing anything
existing, shoving down their throats something they didn't need
before. All I do is adding something new, that helps a few desktopish
cases and can be integrated into various applications very easily and
with only minimal impact on dependencies, and is only used as fallback
if nothing else is configured.

Really, I am doing my best to ease adoptions for those interested.
 
> (I assume, for example, that it would not under any circumstances reset
> the scheduler of the kernel interrupt processes in an rt patched
> kernel!!)

By default it only ever looks at non-root processes.

Lennart

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


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

2009-06-22 Thread Jens M Andreasen
On Mon, 2009-06-22 at 20:18 +0200, Lennart Poettering wrote:

> But uh, that app could then not access the starting user's file in any
> way. 

Of course it could!  ... :-/

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Emanuel Rumpf
2009/6/19 Lennart Poettering :

> Also, asking the user to edit /etc/security/limits.conf
> is certainly not user-friendly. We want to enable RT scheduling for
> media aplications out-of-the-box.
>
Why not just create a small script to handle editing + reloading of
limits.conf :

$ allow_realtime_for_group audio yes
Allowed RT scheduling for group audio

$ allow_realtime_for_group audio no
Disallowed RT scheduling for group audio

Things seem to work well with limits.conf set up.
No reason to change it AFAIS.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 21:28, Emanuel Rumpf (xb...@web.de) wrote:

> 
> 2009/6/19 Lennart Poettering :
> 
> > Also, asking the user to edit /etc/security/limits.conf
> > is certainly not user-friendly. We want to enable RT scheduling for
> > media aplications out-of-the-box.
> >
> Why not just create a small script to handle editing + reloading of
> limits.conf :
> 
> $ allow_realtime_for_group audio yes
> Allowed RT scheduling for group audio
> 
> $ allow_realtime_for_group audio no
> Disallowed RT scheduling for group audio
> 
> Things seem to work well with limits.conf set up.
> No reason to change it AFAIS.

Dude. Seriously.

As pointed out gazillions of times handing our RLIMIT_RTPRIO to
everyone is an invitation to freeze the machine. While that might not
be a problem on an audio workstation, it is a problem for the big
distributions.

Lennart

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


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 20:24 +0200, Lennart Poettering wrote:
> On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) 
> wrote:
> > On Mon, 2009-06-22 at 15:38 +0200, Lennart Poettering wrote:
> > > On Mon, 22.06.09 15:05, Fons Adriaensen (f...@kokkinizita.net) wrote:
> > > > On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote:
> > > > 
> > > > > There's something wrong here.
> > > > 
> > > > There is a lot wrong here.
> > > > 
> > > > * Question: is the 'demoting' of RT-threads applied only to RT
> > > > threads granted by this daeomon, or does it apply to all, including
> > > > those created by processes running as root ? In the latter case this
> > > > system is not only broken, but should be classified as malware.
> > > 
> > > Is that so?
> > > 
> > > It can do both. resetting all is the default.
> > 
> > Good question. 
> > 
> > Why is it resetting all the default, even processes with rt privileges
> > not granted by RealtimeKit? Isn't rtkit supposed to be the only
> > authorized way to access schedulers other that SCHED_OTHER by non-root
> > users?
> 
> rtkit doesn't need to be the exclusive consumer of the kernel RT
> interfaces. RLIMIT_RTPRIO is another supported mechanism that
> continues to work.

Maybe I did not frame the question correctly: if the system has been
configured on purpose by the administrator to grant !SCHED_OTHER by
using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
did not grant privileges to? 

> Even if some folks seem to believe it, I am not replacing anything
> existing, shoving down their throats something they didn't need
> before. All I do is adding something new, that helps a few desktopish
> cases and can be integrated into various applications very easily and
> with only minimal impact on dependencies, and is only used as fallback
> if nothing else is configured.

I understand that as well. If I may disagree, the long term implication
of rtkit is not just helping a few desktopish cases. It may be why it
was written. But if successful, it will be the only way a distribution
will grant !SCHED_OTHER out of the box, so it will affect anything that
wants to run !SCHED_OTHER out of the box in that distribution (say,
Fedora), including, for example, jack & friends. Thus my concerns and
questions.

(yes, I understand RLIMIT_RTPRIO will still be there, the system will
just not be configured out of the box to grant any access through that
mechanism). 

> Really, I am doing my best to ease adoptions for those interested.
>  
> > (I assume, for example, that it would not under any circumstances reset
> > the scheduler of the kernel interrupt processes in an rt patched
> > kernel!!)
> 
> By default it only ever looks at non-root processes.

Thanks...
Sorry but that is not what I understood from your answer. Fons asked:

> * Question: is the 'demoting' of RT-threads applied only to RT
> threads granted by this daeomon, or does it apply to all, including
> those created by processes running as root ?

Note the part about "including those created by processes running as
root". Your answer:

> It can do both. resetting all is the default.

To my eyes "resetting all" would mean to _include_ processes running as
root, thus my remark.  

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fons Adriaensen
On Mon, Jun 22, 2009 at 05:58:41PM +0100, Krzysztof Foltman wrote:

> Fons Adriaensen wrote:
> 
> >> You're not ignoring it, you're practically waging the war against it,
> > Ever seen a real war ?
> 
> Your point being?

My point being that if you use that word you'd better know
what it means. 

> Basically, Lennart pointed out a potential security hole and shown a way
> to fix it.

It fixes nothing at all. It just makes a system fail in a different way
which IMHO is not better but rather worse than the original one.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> > > Good question. 
> > > 
> > > Why is it resetting all the default, even processes with rt privileges
> > > not granted by RealtimeKit? Isn't rtkit supposed to be the only
> > > authorized way to access schedulers other that SCHED_OTHER by non-root
> > > users?
> > 
> > rtkit doesn't need to be the exclusive consumer of the kernel RT
> > interfaces. RLIMIT_RTPRIO is another supported mechanism that
> > continues to work.
> 
> Maybe I did not frame the question correctly: if the system has been
> configured on purpose by the administrator to grant !SCHED_OTHER by
> using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
> did not grant privileges to? 

rtkit is bus activated. It's only active when it is used. The
distinction between demoting all and demoting only the 'known'
processes is hence mostly theoretical.

I picked "demoting all" as the default since it 'felt' more
secure. Dunno. If someone can offer me real-world case where this
distinction really matters, I am all ears. Otherwise I'd got for the
safe default for now.

> (yes, I understand RLIMIT_RTPRIO will still be there, the system will
> just not be configured out of the box to grant any access through that
> mechanism). 

For RLIMIT_RTPRIO nothing changes. It wasn't enabled by default in the
big distros and it wont be enabled in the future either.

Lennart

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


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote:
> On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) 
> wrote:
> > > > Good question. 
> > > > 
> > > > Why is it resetting all the default, even processes with rt privileges
> > > > not granted by RealtimeKit? Isn't rtkit supposed to be the only
> > > > authorized way to access schedulers other that SCHED_OTHER by non-root
> > > > users?
> > > 
> > > rtkit doesn't need to be the exclusive consumer of the kernel RT
> > > interfaces. RLIMIT_RTPRIO is another supported mechanism that
> > > continues to work.
> > 
> > Maybe I did not frame the question correctly: if the system has been
> > configured on purpose by the administrator to grant !SCHED_OTHER by
> > using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
> > did not grant privileges to? 
> 
> rtkit is bus activated. It's only active when it is used. The
> distinction between demoting all and demoting only the 'known'
> processes is hence mostly theoretical.

No, it is absolutely practical. 

> I picked "demoting all" as the default since it 'felt' more
> secure. Dunno. 

Well, sorry but IMO "feeling" has nothing to do with security (I
understand what you are saying, but we cannot base policy decisions like
this one on feeling or beauty or other subjective qualities). 

What is rtkit assuming with that behavior? That any non-root process
that it did not authorize is fair game for it to meddle with. That is an
incorrect assumption. 

> If someone can offer me real-world case where this
> distinction really matters, I am all ears. Otherwise I'd got for the
> safe default for now.

_One_ of the available mechanisms for granting !SCHED_OTHER thinks it is
the only mechanism and acts accordingly. That is wrong. 

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Jörn Nettingsmeier
Lennart Poettering wrote:
> On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) 
> wrote:
>> As a user doing critical audio, say, in a concert situation, I'd require
>> that my computer's realtime audio tasks can use 99.9% of the cpu for
>> short amounts of time. I don't care if the rest of the user processes
>> are momentarily slowed down (up to a point, of course). I would very
>> much care if my computer, due to a temporary overload, decides to a)
>> glitch the audio and b) demote the rt process to SCHED_OTHER
>> permanently. It looks like the RealtimeKit is designed to do exactly
>> that by default. 
> 
> By default the watchdog will only become active after 10s of complete
> lockup. This should be enough. We can raise it if this turns out to be
> necessary, but let's wait for a request based on real-world data
> before we do something like that.

this demonstrates nicely that there is no solution to the problem (or
that i don't understand what problem you are trying to solve).

any user that gets rt privileges can DoS the machine. actually, one
person's creative act is another person's DoS :)

if you try to guard against forkbombs, you are obviously under the
illusionary impression that you can guide against malicious users. you
can't. with your new bit of policy, i just write a bomb that eats up
100% for 9.9s, then yields for as long as your daemon needs to be
pacified, then hog the machine again.

so what is this about? rt users want absolute control over their
machine. anybody who can tolerate some arbitrary bits of policy thrown
at them during work is by definition not an rt user.
rt users must be trustable with root access, at least in terms of cpu
governance, which is what rtlimits achivev just fine.






___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Jörn Nettingsmeier
Lennart Poettering wrote:
> On Mon, 22.06.09 09:33, Arnold Krille (arn...@arnoldarts.de) wrote:
> 
> 
> You practically cannot take group membership away from a user after
> you gave it to him, and also adding a seperate group for every tiny
> bit you need to authorize access to doesn't scale.

security is a matter of good design, not of "oh, look, he has become
evil, let's revoke his privileges" ad-hockery.

it should never be necessary to automatically revoke rights from users.
if i have to get rid of a misbehaving creature fast, "passwd -l villain"
in combination with "mv ~villain/.ssh /tmp" and a quick pkill fixes
things for me. and the very good part is that this decision is made by a
human, not by some imperial shitload of policy that caters to the needs
of some mythical desktop user.

your rtkit cannot protect against anything, you can just play policy
catch-up with evildoers forever. that's about the same level of security
that outgoing firewalls in windows provide - you depend on process names
and whatnot, and if i rename "Internet Explorer.exe" to "Windows
Update.exe", i'm free to do as i please (not quite, but you get the idea).
this is *not security*. this is theater. proper security sometimes
includes the wisdom that certain threats cannot be met without throwing
out the child with the bathwater. some daemon fiddling with rt privs at
runtime in my book qualifies as drowning the child first, then throwing
it out. maybe eating it afterwards, but i'm not sure.



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 23:19, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) 
wrote:

> so what is this about? rt users want absolute control over their
> machine. anybody who can tolerate some arbitrary bits of policy thrown
> at them during work is by definition not an rt user.
> rt users must be trustable with root access, at least in terms of cpu
> governance, which is what rtlimits achivev just fine.

What is so difficult to understand that rtkit is not intended to be a
solution for hardcore rt users? 

rtkit is not for you!

Let me repeat this:

RTKIT IS NOT FOR YOU!

rtkit is a just missing piece of the puzzle that allows distros to
enable RT by default for their desktop users.

And rtkit doesn't break RLIMIT_PRIO, it isn't even activated when that
is set.

Let me repeat this, too:

RTKIT DOESN'T BREAK RLIMIT_RTPRIO!

It was clearly a bad idea to post about rtkit on lad. It is a big
waste of time fighting this through against all those desktop-haters,
fdo-haters, dbus-haters, who apparently believe I am out to take away
their freedom to run their systems the way want. I really don't need
this shit. The amount of constructive criticism in this thread is next
to zero, nobody even bothers to read the README before just fudding
around. 

Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 23:35, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) 
wrote:

> Lennart Poettering wrote:
> > On Mon, 22.06.09 09:33, Arnold Krille (arn...@arnoldarts.de) wrote:
> > 
> > 
> > You practically cannot take group membership away from a user after
> > you gave it to him, and also adding a seperate group for every tiny
> > bit you need to authorize access to doesn't scale.
> 
> security is a matter of good design, not of "oh, look, he has become
> evil, let's revoke his privileges" ad-hockery.

Gah. You are so annoying.

rtkit includes the watchdog only as additional a-posteriori security
measure. The focus is clearly on a-priori security measures, i.e. not
handing out RT sched in a way that could be misused in the first place.

This is explicitly stressed in the README. Did you bother to read
that? No of course not.

Lennart

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


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

2009-06-22 Thread Jörn Nettingsmeier
Lennart Poettering wrote:
> On Mon, 22.06.09 23:19, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) 
> wrote:
> 
>> so what is this about? rt users want absolute control over their
>> machine. anybody who can tolerate some arbitrary bits of policy thrown
>> at them during work is by definition not an rt user.
>> rt users must be trustable with root access, at least in terms of cpu
>> governance, which is what rtlimits achivev just fine.
> 
> What is so difficult to understand that rtkit is not intended to be a
> solution for hardcore rt users? 
> 
> rtkit is not for you!
> 
> Let me repeat this:
> 
> RTKIT IS NOT FOR YOU!

this is getting childish. my claim is: if you give rt to a user, you
enable him to fuck the machine up. that's a law of nature. you can do
all kinds of very clever things and try to have a very fast watchdog,
but it doesn't prevent abuse.

my point is: since the rt user is locally trusted, you can just as well
grant static rt rights using the rtlimits approach. if the user is not
to be trusted with static rt rights, s/he is not to be trusted with any
kind of rt rights, no matter how clever the daemon that grants them. so
what is the problem you are trying to solve?

this is really akin to handing out root rights and watching the
filesystem, and as soon as the user starts reading other people's mail
some script yells at him.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread drew Roberts
On Monday 22 June 2009 17:37:20 Lennart Poettering wrote:
>  The amount of constructive criticism in this thread is next
> to zero, nobody even bothers to read the README before just fudding
> around.

I am one of those who also haven't read the README. I have been trying to 
follow this thread with a bit more than non-interested care though.

> rtkit is a just missing piece of the puzzle that allows distros to
> enable RT by default for their desktop users.

Here is a small bit of an attempt at being constructive.

I don't think I saw any assertion in the thread as to the benefits of enabling 
RT by default for all desktop users? (I may have missed it or forgotten it 
though) What is gained by this? What are normal desktop users doing than 
needs RT? (I am asking out of a large pool of ignorance here but I have a 
feeling from the thread that people may not be seeing the benefit of 
this...???)

all the best,

drew
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 23:46, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) 
wrote:

> > What is so difficult to understand that rtkit is not intended to be a
> > solution for hardcore rt users? 
> > 
> > rtkit is not for you!
> > 
> > Let me repeat this:
> > 
> > RTKIT IS NOT FOR YOU!
> 
> this is getting childish. my claim is: if you give rt to a user, you
> enable him to fuck the machine up. that's a law of nature. you can do
> all kinds of very clever things and try to have a very fast watchdog,
> but it doesn't prevent abuse.

That is simply bogus.

With the reset-on-fork kernel patch in place you can perfectly
supervise an RT process and it cannot evade you. If the system becomes
unresponsive (which is all that we try to detect), then we can
demote/kill everyone who's misbehaving.

The worst thing that can happen is that we demote more processes than
necessary. But so what? As long as the evildoer's process is
demoted/killed you have a usable system again.

Also, stuff such as RLIMIT_RTTIME (which we specifically check to be
set in clients in rtkit) should make sure that the process cannot even
misuse RT in the first place.

Really, all this has been answered before. You can run around in
circles if you like to, but this is where I get off.

Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 18:00, drew Roberts (z...@100jamz.com) wrote:

> Here is a small bit of an attempt at being constructive.
> 
> I don't think I saw any assertion in the thread as to the benefits of 
> enabling 
> RT by default for all desktop users? (I may have missed it or forgotten it 
> though) What is gained by this? What are normal desktop users doing than 
> needs RT? (I am asking out of a large pool of ignorance here but I have a 
> feeling from the thread that people may not be seeing the benefit of 
> this...???)

Has been answered before. I want to make PA RT by default. PA is
installed default on all big distros.

Lennart

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


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 18:00 -0400, drew Roberts wrote:
> On Monday 22 June 2009 17:37:20 Lennart Poettering wrote:
> >  The amount of constructive criticism in this thread is next
> > to zero, nobody even bothers to read the README before just fudding
> > around.
> 
> I am one of those who also haven't read the README. I have been trying to 
> follow this thread with a bit more than non-interested care though.
> 
> > rtkit is a just missing piece of the puzzle that allows distros to
> > enable RT by default for their desktop users.
> 
> Here is a small bit of an attempt at being constructive.
> 
> I don't think I saw any assertion in the thread as to the benefits of 
> enabling 
> RT by default for all desktop users? (I may have missed it or forgotten it 
> though) What is gained by this? What are normal desktop users doing than 
> needs RT? (I am asking out of a large pool of ignorance here but I have a 
> feeling from the thread that people may not be seeing the benefit of 
> this...???)

Basically playing sound. So that playback does not skip and can have
reasonable latencies. If the process that is playing sound gets
preempted out because of the workload of the machine and can't feed the
sound card soon enough you get a click. Humans are very sensitive to
that (more than to, say, a missed frame in video playback). 

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fons Adriaensen
On Mon, Jun 22, 2009 at 11:37:20PM +0200, Lennart Poettering wrote:

> It was clearly a bad idea to post about rtkit on lad. It is a big
> waste of time fighting this through against all those desktop-haters,
> fdo-haters, dbus-haters, who apparently believe I am out to take away
> their freedom to run their systems the way want. I really don't need
> this shit. The amount of constructive criticism in this thread is next
> to zero, nobody even bothers to read the README before just fudding
> around. 

Reading it does not imply agreeing with everything
said there. If it makes your life easier: I *did*
read it.

Since you claim that all the *Kit stuff is optional,
and you will still allow us to run our systems as we
see fit, and since you wear a Red Hat, please tell
me how to remove 

root  1830 1  0 Jun22 ?00:00:00 /usr/sbin/console-kit-daemon

permanently in FC10. It used to be a service but 
apparently isn't anymore. And while you're at it,
and since I don't run gdm or gnome, same for:

fons  2243 1  0 Jun22 ?00:00:00 /usr/bin/gnome-keyring-daemon 
-d --login
fons  2309 1  0 Jun22 ?00:00:00 /usr/libexec/gvfsd
fons  2346 1  0 Jun22 ?00:00:00 /usr/libexec//gvfs-fuse-daemon 
/home/fons/.gvfs
fons  2434 1  0 Jun22 ?00:00:00 
/usr/libexec/gconf-im-settings-daemon
fons  2436 1  0 Jun22 ?00:00:00 /usr/libexec/gconfd-2
fons  2516 1  0 Jun22 ?00:00:00 
/usr/libexec/gvfs-hal-volume-monitor
fons  2518 1  0 Jun22 ?00:00:00 
/usr/libexec/gvfs-gphoto2-volume-monitor

Once that is taken care of, I may start to believe what
you say.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Tue, 23.06.09 00:36, Fons Adriaensen (f...@kokkinizita.net) wrote:

> 
> On Mon, Jun 22, 2009 at 11:37:20PM +0200, Lennart Poettering wrote:
> 
> > It was clearly a bad idea to post about rtkit on lad. It is a big
> > waste of time fighting this through against all those desktop-haters,
> > fdo-haters, dbus-haters, who apparently believe I am out to take away
> > their freedom to run their systems the way want. I really don't need
> > this shit. The amount of constructive criticism in this thread is next
> > to zero, nobody even bothers to read the README before just fudding
> > around. 
> 
> Reading it does not imply agreeing with everything
> said there. If it makes your life easier: I *did*
> read it.
> 
> Since you claim that all the *Kit stuff is optional,

(as a side note, I didn't claim that)

> and you will still allow us to run our systems as we
> see fit, and since you wear a Red Hat, please tell
> me how to remove 

Just downgrade to FC5 or so. Or pick a different distro that is
suited more to your needs.

Nobody forced you to use Fedora. If you are unhappy with the decisions
Fedora took, then you are welcome to change distros or take the code
you like and create your own distro.

You are a troll, and this is wildly off-topic, and I am not a support
guy, so please drop this nonsense.

Lennart

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


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

2009-06-22 Thread Arnold Krille
On Monday 22 June 2009 23:35:57 Jörn Nettingsmeier wrote:
> some daemon fiddling with rt privs at
> runtime in my book qualifies as drowning the child first, then throwing
> it out. maybe eating it afterwards, but i'm not sure.

Yippie! We are back at the "child eating" stage!

/me gets out the popcorn...


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 14:18 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote:
> > On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) 
> > wrote:
> > > > > Good question. 
> > > > > 
> > > > > Why is it resetting all the default, even processes with rt privileges
> > > > > not granted by RealtimeKit? Isn't rtkit supposed to be the only
> > > > > authorized way to access schedulers other that SCHED_OTHER by non-root
> > > > > users?
> > > > 
> > > > rtkit doesn't need to be the exclusive consumer of the kernel RT
> > > > interfaces. RLIMIT_RTPRIO is another supported mechanism that
> > > > continues to work.
> > > 
> > > Maybe I did not frame the question correctly: if the system has been
> > > configured on purpose by the administrator to grant !SCHED_OTHER by
> > > using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
> > > did not grant privileges to? 
> > 
> > rtkit is bus activated. It's only active when it is used. The
> > distinction between demoting all and demoting only the 'known'
> > processes is hence mostly theoretical.
> 
> No, it is absolutely practical. 
> 
> > I picked "demoting all" as the default since it 'felt' more
> > secure. Dunno. 
> 
> What is rtkit assuming with that behavior? That any non-root process
> that it did not authorize is fair game for it to meddle with. That is an
> incorrect assumption. 

I think I may be misunderstanding something. 
Or I'm just SSS... 

You wrote yesterday:
> rtkit only comes into play as last resort when rt is cannot otherwise
> be required (at least if developers follow my recommendations from the
> README). If the supervised realtime sched that rtkit gives you isn't
> good enough, then simply give your application unsupervised RT by
> means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike.

If rtkit would demote all processes when triggered, regardless of whether 
rtkit granted the privileges or not then I can't really bypass it, it is 
always there defining policy. 

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Dennis Schulmeister
Hi,

On Mon, 2009-06-22 at 15:08 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-06-22 at 18:00 -0400, drew Roberts wrote:
> > I don't think I saw any assertion in the thread as to the benefits of 
> > enabling 
> > RT by default for all desktop users? (I may have missed it or forgotten it 
> > though) What is gained by this? What are normal desktop users doing than 
> > needs RT? (I am asking out of a large pool of ignorance here but I have a 
> > feeling from the thread that people may not be seeing the benefit of 
> > this...???)
> 
> Basically playing sound. So that playback does not skip and can have
> reasonable latencies. If the process that is playing sound gets
> preempted out because of the workload of the machine and can't feed the
> sound card soon enough you get a click. Humans are very sensitive to
> that (more than to, say, a missed frame in video playback). 

Then the assumption is that an audio-playing process belongs to the
top-priority processes which deserve the most computation time (on a
typical desktop system). I wouldn't agree to that assumption. Sure I do
have a media player running in the background and I don't want the
playback to click or skip. The same goes for video watching and so on.
But I might accept drop outs if the machine is under heavy load (like
when compiling a large program, rendering a video, ...) and don't want
the media player to consume all the computation power.

But then latency is no issue either as a media player most often plays
static files which can be read in advance to keep the buffers full. The
same goes for web streams which need to be buffered anyway in order to
compensate jitter and limited bandwidth. Typically between 1/3 and 1/5
second is responsive enough for most desktop applications and still
makes for plenty audio buffers even under non-rt situations.

So after reading all those messages I'm somewhat left up wondering if
the addressed problem (real-time audio for desktop applications) really
is an existing problem. The same goes for the theoretical threat of a
rt-fork bomb. Just because in theory someone could write such a program
and make it run on a someone else's machine doesn't seem like enough
reasoning for implementing a protection mechanism on a large user base.
In theory there are much more real threats for the average user which
nobody cared to address. And it has been shown that in theory the
suggested protection mechanism can be circumvented, too.


BTW: I read the README file and don't see why it should be required
reading for this thread. Lennart explained it much better through his
mails than the README file (which contains two typos :-).



Yours sincerely,
Dennis Schulmeister

PS: Sorry Fernando for first sending this directly to you.

-- 
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: den...@windows3.de

Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net)
Besides that: http://www.denchris.de - http://www.motagator.net/bands/65



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Jonathan Woithe
Lennart Poettering wrote:
> 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*.

But isn't this more to do with the missing userspace support infrastructure
that numerous people have pointed to than RTPRIO itself?  RTPRIO itself does
not imply this "all or nothing" restriction since it *can* be set on a
per-application basis (given appropriate support in userspace for doing so).

I also had a problem with the way PAM did the "all or nothing" approach and
so I wrote set_rlimits - which grants user-specified RT privileges via
RTPRIO on a user/group/program-specific basis.  It's not perfect (one has to
start applications via set_rlimits - eg: "set_rlimits ardour") but it works
for me and didn't take all that long to write.  Given this I'm sure others
could come up with a workable RTPRIO-based system which included a nice
user-friendly GUI configuration applet (and so forth) - set_rlimits is a
proof-of-concept in a way which shows that something like this can be done.

I mention this because from where I stand on the periphery it seems to me
that the major issues with RTPRIO could well have been solved if the
related userspace support infrastructure had been written.

> For the desktop case you need something in between: RT that cannot be
> misused, basically. Doing that securely is particularly hard ...

Almost anything involving elevated privileges can and will be abused in
time.  That's why the action requires elevated privileges in the first
place.

Regards
  jonathan
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Lennart Poettering
On Mon, 22.06.09 16:33, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:

> If rtkit would demote all processes when triggered, regardless of whether 
> rtkit granted the privileges or not then I can't really bypass it, it is 
> always there defining policy. 

Except that rtkit wouldn't be started in the first place if the apps
get RT by some other means, since rtkit is only the last resort for them.

But really, if this is so important to you then we can certainly
change that. 


Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Tue, 23.06.09 01:38, Dennis Schulmeister (linux-audio-...@windows3.de) wrote:

> So after reading all those messages I'm somewhat left up wondering if
> the addressed problem (real-time audio for desktop applications) really
> is an existing problem. The same goes for the theoretical threat of a
> rt-fork bomb. Just because in theory someone could write such a program
> and make it run on a someone else's machine doesn't seem like enough
> reasoning for implementing a protection mechanism on a large user base.
> In theory there are much more real threats for the average user which
> nobody cared to address. And it has been shown that in theory the
> suggested protection mechanism can be circumvented, too.

Take it from a desktop developer: it does make a difference if PA is
RT or not. 

And there are no plans to make every media player RT. Nobody is
suggesting that.

Lennart

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


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

2009-06-22 Thread Lennart Poettering
On Tue, 23.06.09 09:14, Jonathan Woithe (jwoi...@physics.adelaide.edu.au) wrote:

> 
> Lennart Poettering wrote:
> > 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*.
> 
> But isn't this more to do with the missing userspace support infrastructure
> that numerous people have pointed to than RTPRIO itself?  RTPRIO itself does
> not imply this "all or nothing" restriction since it *can* be set on a
> per-application basis (given appropriate support in userspace for
> doing so).

You are misunderstanding what I was saying: either a process is
SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
full RT powers, or no RT powers at all. Desktop media stuff doesn't
need the full RT powers.

> I also had a problem with the way PAM did the "all or nothing" approach and
> so I wrote set_rlimits - which grants user-specified RT privileges via
> RTPRIO on a user/group/program-specific basis.  It's not perfect (one has to
> start applications via set_rlimits - eg: "set_rlimits ardour") but it works
> for me and didn't take all that long to write.  Given this I'm sure others
> could come up with a workable RTPRIO-based system which included a nice
> user-friendly GUI configuration applet (and so forth) - set_rlimits is a
> proof-of-concept in a way which shows that something like this can be done.
> 
> I mention this because from where I stand on the periphery it seems to me
> that the major issues with RTPRIO could well have been solved if the
> related userspace support infrastructure had been written.

Processes with rtprio can fork as much as they want. With ptrace or
LD_PRELOAD or a similar mechanism users can load whatever they want
into those processes. That's why RLIMIT_RPRIO is not safe, and not
even remotely so.

> > For the desktop case you need something in between: RT that cannot be
> > misused, basically. Doing that securely is particularly hard ...
> 
> Almost anything involving elevated privileges can and will be abused in
> time.  That's why the action requires elevated privileges in the first
> place.

Sure, but that's no reason not to at least try to make the system safe
for abuses.

Lennart

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


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

2009-06-22 Thread Dennis Schulmeister
On Tue, 2009-06-23 at 01:59 +0200, Lennart Poettering wrote:
> Take it from a desktop developer: it does make a difference if PA is
> RT or not. 

I'd be curious which difference it makes.

> And there are no plans to make every media player RT. Nobody is
> suggesting that.

Okay, that was inaccurate by me. But still audio performance has always
been fine for typical desktop usage without rt privileges me thinks.
Because the issue of latency is relative in that case. But maybe I'm
missing an important point.



Yours sincerely,
Dennis Schulmeister

-- 
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: den...@windows3.de

Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net)
Besides that: http://www.denchris.de - http://www.motagator.net/bands/65



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Paul Davis
On Mon, Jun 22, 2009 at 8:05 PM, Lennart Poettering wrote:
> You are misunderstanding what I was saying: either a process is
> SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
> full RT powers, or no RT powers at all. Desktop media stuff doesn't
> need the full RT powers.

now i'm even more confused. there are two properties we seem to be
discussing. one is which scheduling class a thread is in. the other is
whether the process has RLIMIT_RTPRIO set. you're saying that RTKit
puts the thread into the/a RT scheduling class, whereas
limits.conf/PAM/set_rlimits gives it RLIMIT_RTPRIO. correct?

a few more questions now that i've read the README once (more to come):

1) do you have a plan for mlock/mlock_all ?

2) if a distro decides they want RTKit around, why not set
SCHED_RESET_ON_FORK for init, thus preventing a fork bomb ever, and
run the watchdog as part of the regular startup process? why start it
on demand? then allow any process to obtain SCHED_FIFO/RR, knowing
that its now "safe" ?

3) in your README you claim "If processes that have real-time
scheduling privileges enter a busy loop they can freeze the entire the
system." But this seems to ignore the existence of :
/proc/sys/kernel/{sched_rt_period_us,sched_rt_runtime_us} which i
understood as preventing this without any other kernel mechanisms? I
quote from: 
http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-group.txt

"These defaults were chosen so that a run-away realtime tasks will not
lock up the machine but leave a little time to recover it."

so now i'm even more puzzled about what problem you are attempting to solve ...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Tue, 2009-06-23 at 01:53 +0200, Lennart Poettering wrote:
> On Mon, 22.06.09 16:33, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) 
> wrote:
> 
> > If rtkit would demote all processes when triggered, regardless of whether 
> > rtkit granted the privileges or not then I can't really bypass it, it is 
> > always there defining policy. 
> 
> Except that rtkit wouldn't be started in the first place if the apps
> get RT by some other means, since rtkit is only the last resort for them.

Sorry to be a pest, if only _one_ app requests through rtkit then all
bets are off until a logout/login sequence, right? 

> But really, if this is so important to you then we can certainly
> change that. 

I happen to think it is the wrong thing to do in general: you are
essentially forcing policy for something you don't have complete control
over, so that it may overlap or override with what other methods want.
It is probably going to create problems in the long run, but that is a
very non-scientific thing to say. 

(BTW, I still have to try to figure out if jack support is possible -
don't know when I'm going to have time - jack bestows rt on threads that
the client programs use, but not through a fork)

-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Mon, 2009-06-22 at 20:22 -0400, Paul Davis wrote:
> On Mon, Jun 22, 2009 at 8:05 PM, Lennart Poettering wrote:
> > You are misunderstanding what I was saying: either a process is
> > SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
> > full RT powers, or no RT powers at all. Desktop media stuff doesn't
> > need the full RT powers.
> 
> now i'm even more confused. there are two properties we seem to be
> discussing. one is which scheduling class a thread is in. the other is
> whether the process has RLIMIT_RTPRIO set. you're saying that RTKit
> puts the thread into the/a RT scheduling class, whereas
> limits.conf/PAM/set_rlimits gives it RLIMIT_RTPRIO. correct?

Not my understanding at this point. Both limits.conf/PAM/set_rlimits and
rtkit give SCHED_FIFO|SCHED_RR to the process. Rtkit only gives
SCHED_RR(FIFO?) if RLIMIT_RTPRIO is set when the request is made, and
also ||'s the request with the new (forget its name) kernel flag that
resets a process's child to SCHED_OTHER when it forks. 

-- Fernando


> a few more questions now that i've read the README once (more to come):
> 
> 1) do you have a plan for mlock/mlock_all ?
> 
> 2) if a distro decides they want RTKit around, why not set
> SCHED_RESET_ON_FORK for init, thus preventing a fork bomb ever, and
> run the watchdog as part of the regular startup process? why start it
> on demand? then allow any process to obtain SCHED_FIFO/RR, knowing
> that its now "safe" ?
> 
> 3) in your README you claim "If processes that have real-time
> scheduling privileges enter a busy loop they can freeze the entire the
> system." But this seems to ignore the existence of :
> /proc/sys/kernel/{sched_rt_period_us,sched_rt_runtime_us} which i
> understood as preventing this without any other kernel mechanisms? I
> quote from: 
> http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-group.txt
> 
> "These defaults were chosen so that a run-away realtime tasks will not
> lock up the machine but leave a little time to recover it."
> 
> so now i'm even more puzzled about what problem you are attempting to solve 
> ...
> ___


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Esben Stien
Dennis Schulmeister  writes:

> audio performance has always been fine for typical desktop usage
> without rt privileges me thinks.  Because the issue of latency is
> relative in that case. But maybe I'm missing an important point.

Sure, like VoIP. 

-- 
Esben Stien is b...@e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Fernando Lopez-Lezcano
On Tue, 2009-06-23 at 03:54 +0200, Esben Stien wrote:
> Dennis Schulmeister  writes:
> 
> > audio performance has always been fine for typical desktop usage
> > without rt privileges me thinks.  Because the issue of latency is
> > relative in that case. But maybe I'm missing an important point.
> 
> Sure, like VoIP. 

& games...
-- Fernando


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread nescivi
On Monday 22 June 2009 17:35:57 Jörn Nettingsmeier wrote:
> your rtkit cannot protect against anything, you can just play policy
> catch-up with evildoers forever. that's about the same level of security
> that outgoing firewalls in windows provide - you depend on process names
> and whatnot, and if i rename "Internet Explorer.exe" to "Windows
> Update.exe", i'm free to do as i please (not quite, but you get the idea).
> this is *not security*. this is theater. 

Maybe that's where the confusion comes from!
In today's media and everyday life security is so often confused with theater, 
and theater is so often used to make things seem secure, that we don't know 
the difference anymore!
Ever been in an airport lately?

Only the bad actors get caught.

(which reminds me of that question on a certain well-known country's 
immigration form, which asks whether or not I am planning to blow something 
up, while I'm there. Like, I would answer yes if I did?).


> proper security sometimes
> includes the wisdom that certain threats cannot be met without throwing
> out the child with the bathwater. some daemon fiddling with rt privs at
> runtime in my book qualifies as drowning the child first, then throwing
> it out. maybe eating it afterwards, but i'm not sure.


sincerely,
Marije
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-22 Thread Dennis Schulmeister
On Tue, 2009-06-23 at 03:54 +0200, Esben Stien wrote:
> Dennis Schulmeister  writes:
> 
> > audio performance has always been fine for typical desktop usage
> > without rt privileges me thinks.  Because the issue of latency is
> > relative in that case. But maybe I'm missing an important point.
> 
> Sure, like VoIP. 

There's the buffer argument again. Even a highly compressed
low-bandwidth VoIP stream needs to be buffered by the application
because of the annoying factor not being latency but jitter. If you do a
"regular" phone call from one mobile phone to another you easily get 1
second latency. The point is you don't notice it unless you're standing
next to the other person.

But then what's the reason behind ultra-small hardware buffers which
need to be refreshed very quickly in contrast to the comparatively large
buffers needed for the input stream in the first place?

I see the reasoning for games, though.



Yours sincerely,
Dennis Schulmeister

-- 
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: den...@windows3.de

Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net)
Besides that: http://www.denchris.de - http://www.motagator.net/bands/65



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Stefan Kost
Dennis Schulmeister schrieb:
> Hi,
>
> On Mon, 2009-06-22 at 15:08 -0700, Fernando Lopez-Lezcano wrote:
>   
>> On Mon, 2009-06-22 at 18:00 -0400, drew Roberts wrote:
>> 
>>> I don't think I saw any assertion in the thread as to the benefits of 
>>> enabling 
>>> RT by default for all desktop users? (I may have missed it or forgotten it 
>>> though) What is gained by this? What are normal desktop users doing than 
>>> needs RT? (I am asking out of a large pool of ignorance here but I have a 
>>> feeling from the thread that people may not be seeing the benefit of 
>>> this...???)
>>>   
>> Basically playing sound. So that playback does not skip and can have
>> reasonable latencies. If the process that is playing sound gets
>> preempted out because of the workload of the machine and can't feed the
>> sound card soon enough you get a click. Humans are very sensitive to
>> that (more than to, say, a missed frame in video playback). 
>> 
>
> Then the assumption is that an audio-playing process belongs to the
> top-priority processes which deserve the most computation time (on a
> typical desktop system). I wouldn't agree to that assumption. Sure I do
> have a media player running in the background and I don't want the
> playback to click or skip. The same goes for video watching and so on.
> But I might accept drop outs if the machine is under heavy load (like
> when compiling a large program, rendering a video, ...) and don't want
> the media player to consume all the computation power.
>   
Just a small comment. Its not about computation time so much, its about
regular scheduling.
> But then latency is no issue either as a media player most often plays
> static files which can be read in advance to keep the buffers full. The
> same goes for web streams which need to be buffered anyway in order to
> compensate jitter and limited bandwidth. Typically between 1/3 and 1/5
> second is responsive enough for most desktop applications and still
> makes for plenty audio buffers even under non-rt situations.
>   
Even if its for memory reasons, media players don't read even static
files totally in advance. media is rendered in chunks. of course its a
good idea to do some extra buffering in non-interactive playback case
where latency does not matter so much.

I'd say most users would prefer if the media playback can ensure smooth
playback.

Stefan
> So after reading all those messages I'm somewhat left up wondering if
> the addressed problem (real-time audio for desktop applications) really
> is an existing problem. The same goes for the theoretical threat of a
> rt-fork bomb. Just because in theory someone could write such a program
> and make it run on a someone else's machine doesn't seem like enough
> reasoning for implementing a protection mechanism on a large user base.
> In theory there are much more real threats for the average user which
> nobody cared to address. And it has been shown that in theory the
> suggested protection mechanism can be circumvented, too.
>
>
> BTW: I read the README file and don't see why it should be required
> reading for this thread. Lennart explained it much better through his
> mails than the README file (which contains two typos :-).
>
>
>
> Yours sincerely,
> Dennis Schulmeister
>
> PS: Sorry Fernando for first sending this directly to you.
>
>   

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Fons Adriaensen
On Tue, Jun 23, 2009 at 12:49:40AM +0200, Lennart Poettering wrote:

> Just downgrade to FC5 or so. Or pick a different distro that is
> suited more to your needs.

Actually F8 would be enough. ConsoleKit was a service there and I
just disabled it without any ill effect.

In F10 that choice has been removed, and I predict that
whatever you wirte today, the same will happen with your
RealtimeKit.

Today you claim it's optional, 'if it's not for you then don't
use it', etc. etc.

Maybe it will be optional in F12. But based on previous 
experience I'm pretty sure things won't stay like that.

By the time we are at F13 or 14, if someone asks you how to
disable RealtimeKit, your answer will be similar to the one
you gave above: 'downgrade to F10 or use a distro that better
suits your needs, nobody is forcing you use Fedora, etc.'

Indeed, nobody is forcing me to use Fedora. But it is the
base of one of the best specialised audio distros, CCRMA.

Maybe you don't care about that, then just say so.


Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Jörn Nettingsmeier
Lennart Poettering wrote:
> On Mon, 22.06.09 23:46, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) 
> wrote:
> 
>>> What is so difficult to understand that rtkit is not intended to be a
>>> solution for hardcore rt users? 
>>>
>>> rtkit is not for you!
>>>
>>> Let me repeat this:
>>>
>>> RTKIT IS NOT FOR YOU!
>> this is getting childish. my claim is: if you give rt to a user, you
>> enable him to fuck the machine up. that's a law of nature. you can do
>> all kinds of very clever things and try to have a very fast watchdog,
>> but it doesn't prevent abuse.
> 
> That is simply bogus.
> 
> With the reset-on-fork kernel patch in place you can perfectly
> supervise an RT process and it cannot evade you. If the system becomes
> unresponsive (which is all that we try to detect), then we can
> demote/kill everyone who's misbehaving.

you don't need to fork in order to do wreak havoc.
how do you make sure you know which processes (i.e. which executables)
deserve rt rights? hash them?
and whatever you do, the moment the user loads a user-defined plugin
from a user-controlled location (such as a privately installed LADSPA
plugin), you are utterly hosed.

or am i missing something fundamental here? in which case please
enlighten me.

btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you
define a maximum amount of time that can be spent in rt mode, per user?
or per process? or per group?
if per user, how is scheduling fairness accomplished? does the first rt
process grab as much as it wants, and then another rt process gets
demoted by rtkit because the user used up their rt slice?




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Jens M Andreasen
On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:

> If you don't do RT development or doing RT development only for
> embedded cases, or if you are a [/*intended explicitives deleted*/]
> then it doesn't mean anything for you.
> 
> However, if you are a desktop developer interested to get your stuff
> working out-of-the-box on modern distributions then you should think
> about calling into RealtimeKit ...

What are the other applications - except for PA - that needs "fixing"?

Is this a PA specific problem only? In which case it could probably be
solved less violently.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Patrick Shirkey


On 06/22/2009 04:20 PM, Chris Cannam wrote:

On Sun, Jun 21, 2009 at 4:09 PM, Paul Davis  wrote:
   

Finally, as Chris said -
many of us are writing apps that target multiple platforms
 


Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience.  Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using.  PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.

   


As a point of interest and comparison that has very little to do with 
this debate,  I just noticed that pulseaudio *is* being used in the Palm Pre


http://opensource.palm.com/packages.html

While Jack and Portaudio are not.




--
Patrick Shirkey
Boost Hardware Ltd.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Bob Ham
On Tue, 2009-06-23 at 00:49 +0200, Lennart Poettering wrote:
> On Tue, 23.06.09 00:36, Fons Adriaensen (f...@kokkinizita.net) wrote:

> > Since you claim that all the *Kit stuff is optional,
> 
> (as a side note, I didn't claim that)
> 
> > and you will still allow us to run our systems as we
> > see fit, and since you wear a Red Hat, please tell
> > me how to remove 
> 
> Just downgrade to FC5 or so.

This response shows a real problem.  The fact that you cannot disable
these kinds of services without forking shows there's a design problem.
The fact that these badly-designed services have become so widespread
shows a deeper problem. 

Recently, money seems to have become quite influential in the free
software community, typified by Red Hat and its efforts to drive free
software development in a direction that suits enterprise customers.
The quoted response shows an unwillingness for these parties to
*cooperate* with communities and instead I see a desire to *dictate* to
communities.

Yes, I can fork Fedora and create a new distribution but that takes a
great deal of time and effort.  If Red Hat were interested in
cooperating instead of dictating, that effort would not be needed; Red
Hat would take on the responsibility of ensuring that their systems are
flexible enough not to need a fork.  Practically, that means designing
software systems in such a way as they can be easily disabled.


Being fuelled by money, this new influence in free software is
susceptible to the control of any parties willing to spend enough.  That
opens the possibility of a fifth column within the free software
community.  I've previously argued that in future, it may be necessary
to protect the interests of free software by forking away from this
influence if it starts behaving as a fifth column.

The above response shows that this influence is already having a
detrimental affect on the quality of free software.  I wonder if it
won't be necessary to fork away from this influence, purely because of
the sub-standard nature of the solutions it produces.

RealtimeKit demonstrates this sub-standard nature in that it's a
workaround.  It provides an API to be used if a system call fails.  This
is not a problem in itself but there seems to be no desire to spend the
time and effort needed to deal with the issue of why the system call is
failing.  Instead, there seems to be only a narrow-minded drive to
produce the next-best *Kit, which will provide an all-new service to
enable our enterprise customers!

It's great that all these new Kits are putting free software in the
hands of average users.  What isn't great is that they seem to be
hastily developed and without concern for the wider free software
community.  There will be consequences of this lack of concern.

Bob

-- 
Bob Ham 

for (;;) { ++pancakes; }


signature.asc
Description: This is a digitally signed message part
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread alex stone
On Tue, Jun 23, 2009 at 2:33 PM, Patrick
Shirkey wrote:
>
> On 06/22/2009 04:20 PM, Chris Cannam wrote:
>
> On Sun, Jun 21, 2009 at 4:09 PM, Paul Davis
> wrote:
>
>
> Finally, as Chris said -
> many of us are writing apps that target multiple platforms
>
>
> Well, my comment (from the point of view of applications rather than
> library development) was not so much about portability as simple
> convenience.  Regardless of which method is ultimately used to
> establish proper audio scheduling, it would be nice to be able to
> handle it through the same audio API as I am already using.  PortAudio
> and JACK APIs both contain some support for this, PulseAudio is the
> odd one out for me.
>
>
>
> As a point of interest and comparison that has very little to do with this
> debate,  I just noticed that pulseaudio *is* being used in the Palm Pre
>
> http://opensource.palm.com/packages.html
>
> While Jack and Portaudio are not.
>
>
>
>
> --
> Patrick Shirkey
> Boost Hardware Ltd.
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
Patrick, the point is well made.

The decision's already been taken, excluding the wider linuxaudio
community, and no amount of enthusiastic input here will make any
difference to Lennert's intent, or anyone else involved in this
project.

Seems we got the short straw. Again.

A real shame.

Alex


-- 
www.openoctave.org

midi-subscr...@openoctave.org
development-subscr...@openoctave.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Patrick Shirkey


On 06/23/2009 06:02 PM, alex stone wrote:

On Tue, Jun 23, 2009 at 2:33 PM, Patrick
Shirkey  wrote:
   

On 06/22/2009 04:20 PM, Chris Cannam wrote:

On Sun, Jun 21, 2009 at 4:09 PM, Paul Davis
wrote:


Finally, as Chris said -
many of us are writing apps that target multiple platforms


Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience.  Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using.  PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.



As a point of interest and comparison that has very little to do with this
debate,  I just noticed that pulseaudio *is* being used in the Palm Pre

http://opensource.palm.com/packages.html

While Jack and Portaudio are not.




--
Patrick Shirkey
Boost Hardware Ltd.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


 

Patrick, the point is well made.

The decision's already been taken, excluding the wider linuxaudio
community, and no amount of enthusiastic input here will make any
difference to Lennert's intent, or anyone else involved in this
project.

   



I wouldn't go that far. Lennart has proven to be open to our suggestions 
in the past and is prepared to work with everyone round here on the 
matter of desktop integration and to a degree system design.


IMO what is missing at the moment is a unified plan from the LAD 
community for desktop integration that is compatible with the unified 
plan from the freedesktop community et al.


What I see is that Lennart and the others who have worked on pulseaudio 
have done such a good job at making the platform accessible to the 
desktop community that it has now become the defacto standard for Linux 
Audio.


This was certainly helped by the insistence (for good reasons) that JACK 
is not designed for normal users or non realtime desktop apps and the 
lack of effort contributed to tackling the inherent issues.


However we do have a problem now that needs to be sorted with 
integrating pa and jack in a way that is easy for everyone to work with.


Clearly Lennart has found that PA needs to be able to handle realtime 
usage cases and is attempting in his best way to deal with those 
problems. However there is s much cross over here that it is 
becoming a dictatorial situation for those of us who are not 
intrinsically tied too the pulse audio system.


Hence it is in everyones best interests to make sure this issue is 
resolved or else we will have another alsa vs oss situation on our hands 
for the foreseeable future.


By itself that is not a problem as that is the beauty of open source, 
but for the average user it is a real headache.







Patrick Shirkey
Boost Hardware Ltd






Seems we got the short straw. Again.

A real shame.

Alex


   
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


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

2009-06-23 Thread Krzysztof Foltman
Patrick Shirkey wrote:
> As a point of interest and comparison that has very little to do with
> this debate,  I just noticed that pulseaudio *is* being used in the Palm Pre
> http://opensource.palm.com/packages.html
> While Jack and Portaudio are not.

Yes, also, Palm Pre doesn't ship with pre-installed Ardour, Aeolus,
Hydrogen or Csound. I really don't see why! /s

Krzysztof

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


  1   2   >