On 02/17/2011 09:48 PM, Paul Davis wrote: I know that patching is not a requirement anymore for realtime on Linux. But I was just asking about some possible security enhancement patch. What are those files in /proc/sys that you mention? Also I'm a bit confused about rlimits. IIUC, realtime processes always run before non-realtime processes. And the realtime priority as set with set_rlimits() only affects the priority of realtime processes between each other. It doesn't seem to affect the priority between realtime and non-realtime processes. I've been told than on OSX, when a process runs in realtime, it is only allowed to use a certain ratio of CPU time. And if it goes over this limit, it loses its priority. Is there something comparable on Linux? Maybe with the files in /proc/sys that you mention? What I'm looking for is some way to say: ok, this thread can run in realtime, but if it ever uses more than 10% of CPU time it will lose realtime priority. Aside of that, what about locks? I've many times been told that one mustn't do anything that could block in a realtime thread. What are the consequences of that? Could a malicious app freeze the system by blocking in a realtime thread? -- Olivier

On Thu, Feb 17, 2011 at 4:53 PM, Robin Gareus <robin(a)gareus.org> wrote: it poses no risks to anything except itself if it does that. blocking in an RT thread matters to the thread, not to anything else. to demote RT threads that are doing too much you'd need a user-space watchdog like das_watchdog

On Thu, Feb 17, 2011 at 10:04:31PM +0000, Fons Adriaensen wrote: if that restriction exists, its a bug. i remember that i successfully set the ratio to 0.1 ... -- torben Hohn

On 02/17/2011 09:40 PM, Olivier Guilyardi wrote: I have written a dynamic system optimizer for linux called ulatencyd. I stumbled more by accident over rt issues my self. I use dynamic cgroups to adjust the resources of the system to what heuristic rules think the user expects. At least in the default desktop configuration but you can actually optimise every system to every load. I mainly use cgroups to group processes which get different parameters like cpu.shares and some other values. you can use cgroups to give strict RT slices. In fact, if you want processes to be able to get rt you have to handle them to, when CONFIG_RT_GROUP_SCHED is set. It is a little bit tricky and it's kind of a hack, how ulatencyd does it, because there is no notification in into userspace when rt scheduling is set on a thread. (There is not even a hook in the kernel execpt the secruity module). What ulatencyd does is to give most groups a cpu.rt_runtime_us of 1, this is way to less to actually do rt work, but allows a process to set rt on a thread. The current scheduler config moves processes that have realtime threads into a rt group that have enough cpu.rt_runtime_us to do their work, but not enough to pull down a system. There are some drawbacks, as I don't get notifications in thread changes, the process is only looked at in a iteration cycle. If a process starts it's rt thread shortly after booting up, everything is fine, as long as he doesn't instantly complain about the bandwidth assigned. jackd for example starts up quite nicely, so does pulseaudio. If a process starts his rt thread very late, the rescheduling could take a iteration interval which is 10 seconds currently. If there is a rule, that marks the process with a flag "sched.rt" it will get moved into the rt group as soon as ulatencyd runs the process, thats quite after delay of 1s (default). I'm thinking about adding a special very early match list that allows to minimise this delay. It exists because many normal processes are just very short living and it's useless to schedule them in the first place. If you are a process, you can put yourself into the rt group by doing in dbus call and mark it as sched.rt and kick a schedling on the process, this way you will instantly end up in the rt group. Now, what you can do if you have no trust in processes at all is, to create dynamic cgroups with carefully calculated cpu.rt_runtime_us values for the processes. If you have trusted processes, you may give them seperate cgroups with fixed runtimes, like for example your mixer process. But remember: you can't overcommit rt_runetime_us and they will not borrow their rt if they don't use it. kind regards Daniel

Hi, On 02/17/2011 10:53 PM, Robin Gareus wrote: There's something which confuses me. But I'm not sure how this realtime period settings relate to the audio I/O period. On Android, the closest that one can get to hardware in a more or less portable way is libaudio [1]. It's Android's audio HAL. This API exposes blocking read() and write() calls, with fixed buffer sizes (input and output buffer sizes generally do not match, but that's another problem). So, this may be a silly/newbie question, but can one access this blocking API from a realtime thread? What will happen when it blocks? How does the read/write period relate to sched_rt_period_us? [1] http://source.android.com/porting/audio.html -- Olivier

On 02/23/2011 11:22 AM, Olivier Guilyardi wrote: It only does iff the audio-I/O thread (or process) is executed with realtime privileges (`man chrt` - man `pthread_setschedparam` ). if you have a RT_PREEMPT kernel you can also raise the priority of the audio-device interrupt handler. Well, it's a bit more complex than that.. not sure if you can go that way on Android easily.

On 02/24/2011 03:59 PM, Olivier Guilyardi wrote: mmh. it depends on how the blocking is done. If it is a spin-lock it will consume CPU and block other processes which are running at lower priority in the meantime (but only up to sched_rt_runtime_us per second. Other processes won't starve). Is there a poll (or select) function available as part of the libaudio API? If the i/o block waits for a signal (e.g. IRQ), it will work just fine.

On 02/23/2011 06:24 PM, Daniel Poelzleithner wrote: Yes, that's the idea. Maybe limit the number of audio clients to a few ones. In the case of Android, here's what I imagine: - a client program asks for (realtime) audio access - the audio server verifies if there aren't too many clients - from that, the server either allows or denies access - in case of a denial the client program can display a meaningful error One thing is that each client runs under a different UID. This is part of app sandboxing. There isn't any predetermined groups of users who can or can't access audio (oh well there is a permission system for that, but it's another question). Basically, any app could request audio access, and ulatencyd or whatever does the same job would have to be rather tightly integrated into the sound server, and move the requesting app to a realtime cgroup if it's possible, or deny access and return an error. Well, you could imagine that ulatencyd and the sound server are distinct and that the client program must connect to both to achieve realtime + audio access. But let's take JACK for example. It handles setting up realtime scheduling transparently when one creates a jack client. There isn't any extra step necessary. As a supposition, could you imagine that ulatencyd integrates tightly into JACK to provide fine-grained per-client realtime permissions? This would for example result in a new error reported by jack_client_open() in case realtime permissions can't be granted because there are too many clients, etc.. -- Olivier

On 02/25/2011 04:29 PM, Paul Davis wrote: I was only supposing the integration of ulatencyd with JACK to illustrate my points. I was not saying that it's necessary a good idea. Let me rephrase my idea. Let's imagine that JACK runs as a privilege user, which in addition of having realtime privileges, is also able to assign other processes to given cgroups and adjust their sched_rt_runtime_us and sched_rt_period_us dynamically. Which is the kind of thing which ulatencyd does IIUC. But let's forget about ulatencyd for a second. Let's now consider that clients runs as user(s) which do not have realtime privileges by default, but that it's JACK which grant them such privileges and assign them a certain CPU time share dynamically. In this scenario could also refuse connections if it considers that there isn't enough resources. Doesn't this make sense to a certain extent? Wouldn't this be an improvement in regard to security? -- Olivier

On 02/25/2011 04:53 PM, Olivier Guilyardi wrote: About this, security really doesn't seem like a pointless question to me. Otherwise, why would all major distributions grant absolutely no realtime privileges/runtime by default? Reading the JACK FAQ and editing some obscure config file to gain realtime privileges isn't exactly user-friendly.. You don't need that kind of thing for realtime audio on OSX for example. -- Olivier

On Fri, Feb 25, 2011 at 11:31 AM, Olivier Guilyardi <list(a)samalyse.com> wrote: the point is that both OS X and contemporary linux have mechanisms that prevent RT scheduling from locking up the system. linux distributions have not adapted to this reality and thus they still continue to make RT scheduling inaccessible to users by default.

On 02/25/2011 05:33 PM, Paul Davis wrote: Maybe that's because such security mechanism are too young in Linux? Or maybe that any system-wide RT privileges are considered too dangerous? In these circumstances, maybe that a JACK specific solution could make sense. It would only need jackd to run as a privileged user (I don't mean root). Maybe that this would make its way into major distributions more easily than system-wide RT privileges. Although I think that granting system-wide RT privileges with a limited runtime sounds like the best solution. But maybe that this mechanism isn't considered mature yet. -- Olivier