Merging the realtime security module

The Linux audio development community has a longstanding problem: many audio applications require very short latencies to avoid losing data, but the Linux kernel makes it hard to get the sort of response times needed. Over time, the audio hackers have developed a solution which works reasonably well for them, and which they would like to see merged into the mainline kernel. There has been strong opposition, however, leaving the audio community feeling, once again, that its needs are being passed over by the kernel developers.

The code in question is the realtime security module, which was covered briefly here last September. This module, when loaded, makes a simple change to the Linux protection mechanism: any process running with a designated group ID is given the CAP_SYS_NICE, CAP_IPC_LOCK, and CAP_SYS_RESOURCE capabilities. Thus, any user who has membership in the special group can raise priorities, lock pages into physical memory, and exceed resource limits. With these capabilities, a suitably aware audio application can ensure that it will be able to respond to events within the required time.

A couple of objections have been raised to the inclusion of the realtime module. One is that it is a specialized hack for a specific set of users which has no place in a general-purpose kernel. The GID-based mechanism is seen as being ugly and hard to administer in the long term. A few kernel hackers have been quite vocal in their opinion that, until these issues have been addressed, this module should not be merged. They have been less vocal, however, on just how audio users should satisfy their needs without offending the sensibilities of the kernel community.

Nonetheless, some progress has been made. The memory locking issue has been solved via the new resource limits which were added in 2.6.9. By setting the limits appropriately, a system administrator can allow otherwise unprivileged users to lock a bounded number of pages into physical memory. A bit of PAM configuration work should suffice to deal with that part of the problem.

The other issue, however, is response time from the CPU scheduler. Ingo Molnar has noted that the kernel's handling of regular "nice" levels is much improved in 2.6.10. Audio hacker Jack O'Quin checked it out and found that things had improved, though the maximum response time was still far worse than can be had by running in the SCHED_FIFO class. The reasons for this behavior are still being investigated; interference from high-priority kernel threads may be part of the problem. Even if the response were adequate, however, raising priorities is still a privileged operation.

That issue could, perhaps, be addressed via yet another resource limit which would allow individual users to raise their priorities within an administrator-set of bounds. If the remaining response time issues could be addressed, this new limit could be part of the overall solution, though it would take some time for updated utilities to get into the hands of the users who need them.

Another approach which has been mentioned would be to generalize the realtime module to address a wider range of needs. If it could be set up to hand out any set of capabilities to given users or groups, it would at least be useful to more people. It could, for example, replace the current group-based hack which gives access to the "hugetlb" mechanism. It would still be setting policies in the kernel by way of user and group IDs, which is not a popular idea, but it would not be quite the niche tool that it is now. A first pass at such a module has been posted by Olaf Dietsche; it takes an interesting approach by having much of the relevant information stored in the form of group ownership on sysfs attributes.

A more comprehensive solution would be to make capabilities work properly. After all, that is what capabilities are supposed to be for: to allow precisely-defined bits of privilege to be granted in the situations where they are needed. The problems there are that Linux capabilities are currently broken, fixing them is a tricky job that nobody seems to want to take on at the moment, and, in any case, administering a truly capability-based system is an exercise in complexity. Capabilities seem unlikely to be part of the solution anytime soon.

One interesting aspect of the discussion is what has not been mentioned. SELinux should be able to solve this problem; it exists to provide ultimate control over what every user and program can do. Nobody, however, has wanted to see what happens when musicians attempt to administer SELinux, it would seem. The realtime preemption work has also been strangely absent from the discussion - and from the kernel mailing lists in general.

As of this writing, no real solution seems to have been found. There are enough kernel hackers sympathetic to the needs of audio hackers, however, that some sort of resolution should be possible. Linux should be the ultimate playground for audio developers; it would be a shame if the kernel continued to get in their way. (For more background, see this history of the realtime LSM by Jack O'Quin).

---

(Log in to post comments)