Security implications of RT and memlock?

Seth Arnold seth.arnold at canonical.com
Sat Jan 19 04:34:21 UTC 2013


On Thu, Jan 17, 2013 at 02:35:58PM +0100, David Henningsson wrote:
> In a discussion with JACK developer Paul Davis, he says:
> 
> "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."
> 
> The advantage of doing so is to remove one obstacle for having
> low-latency audio working OOTB, without manual configuration.

This feels like a surprising amount of resources to grant to a user. On a
single-user workstation, it would feel appropriate to allow the resources
to be used as desired, but it wouldn't be appropriate for multiuser
machines, shared-use systems, servers, etc.

But for the few that really want a top-to-bottom realtime audio
stack, adding a handful of /etc/security/limits.conf settings to
change RLIMIT_RTPRIO and RLIMIT_MEMLOCK (I'm surprised it doesn't
yet support RLIMIT_RTTIME, but without an explicit setting, probably
sched_rt_runtime_us applies equally to all users) does not seem so bad:
after all, those users also need to install and configure their software
and hardware.

64K might seem like a remarkably low per-process locked memory limit,
but it is per-process -- and on my 12.04 LTS laptop I'm allowed to
create 125874 processes; the locked memory works out to nearly eight
gigabytes in total, which feels like a lot. (Probably cgroups could
enforce some reasonable per-user limits rather than just per-process
limits.)

A realtime priority of 0 also doesn't seem too surprising; those
processes do win over non-realtime processes.

Is two lines in a configuration file really so unreasonable?

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130118/8e1e6d02/attachment.pgp>


More information about the ubuntu-devel mailing list