|| ||Paul Davis <paul-AT-linuxaudiosystems.com> |
|| ||David Henningsson <david.henningsson-AT-canonical.com> |
|| ||Re: debian jack/pulse support [ was : Re: JACK in
Chrome !! ] |
|| ||Thu, 17 Jan 2013 07:48:05 -0500|
|| ||JACK <jack-devel-AT-lists.jackaudio.org>|
|| ||Article, Thread
On Thu, Jan 17, 2013 at 7:33 AM, David Henningsson <
> On 01/17/2013 12:57 PM, Paul Davis wrote:
>> that document includes this line:
>> "This can be necessary for running low-latency audio without drop-outs,
>> but is bad from a security and stability point of view, as a process
>> running with real-time privileges can lock up the entire system
>> completely. "
>> this is no longer true. it is trivial to configure the amount of time
>> that RT-scheduled tasks can consume. it can no longer be used as an
>> explanation of why RT scheduling is problematic.
> I'm not a security expert, so excuse me if these are stupid questions,
> First, I tried to look this up on
http://jackaudio.org/linux_rt_**config<http://jackaudi...>but I saw no such
from my experience to date, all distros come with this already configured
because it is the default in the kernel. the kernel reserves a (small)
amount of time for non RT-scheduled tasks.
we also have not documented it for two additional reasons:
(1) we don't want to suggest that users should be messing with these
(2) confusion about cgroups, which has been made worse by different
distributions (initially, at least) doing very different things with cgroups
> Second, your argument seems to apply to RT scheduling only - what about
memlock cannot cause the machine to lock up. it can cause other problems,
but they are more akin to a swap storm than a lock up, and like RT
scheduling, the amount that the user can lock can be finely controlled
(though it would be nice if the syntax for the relevant files allowed
expressions like "80%" rather than fixed amounts of space.
> Third, if you were a maintainer of an general purpose distro, that should
> be able to do everything from pro-audio, consumer audio, gaming, run on
> laptops with decent battery life, to multi-user ssh and web servers and all
> that, how do you recommend we set RT and memlock privileges for the user by
at this point in time, i personally can see absolutely no reason why a
regular user should not have access to RT scheduling or memlock if the
kernel and PAM (or equivalent) are normally and appropriately configured.
give the user the ability to memlock 75% of the system RAM, make sure that
the RT scheduling parameters reserve 5% of the CPU for non-RT tasks. done.
Jack-Devel mailing list
to post comments)