[LAD] Realtime threads and security

[Olivier Guilyardi]

Hi everyone,

I am currently spending a lot of time working on Android, and on the andraudio
mailing list [1] we are discussing about possible improvements to the internal
Android audio system. Currently, latencies are very high, over 100ms, and we're
looking for ways to improve the situation.

In my opinion this can't be achieved on Linux without realtime scheduling. On
Android, there's something called audioflinger which acts as a sound server, and
apps act as clients of this server. The server and clients run in distinct
processes. What I'm thinking about is having a realtime thread within the
server, as well as another realtime thread in the (each) client.

The one thing about Android is that it has a strict security model. Every app is
considered potentially harmful and is thus "sandboxed". Here, this for example
means that apps can lower their threads priority, but not increase it. And of
course they can only use non-realtime scheduling.

On desktops, for instance using JACK, apart from a few multimedia distributions,
realtime permissions are not granted by default to normal users. And when one
enables it, security is usually not a primary concern AFAIK. If a piece of
software happens to crash the system when running in realtime, the user may just
uninstall the buggy software, etc..

But on phones, this is critical, for example if the system crashes while you're
waiting for a call. So, on Android, the security policies are strict. But this
could certainly be necessary to plenty of other Linux usages.

Now my question is: how to allow user-space apps to use realtime scheduling for
one of their threads without compromising the overall security?

For example, in man sched_setcheduler() I see SCHED_RR, and "Everything
described above for SCHED_FIFO also applies to SCHED_RR, except that each
process is only allowed to run for a maximum time quantum".

Would this help and be sufficient? Would there need to have some kind of
watchdog/monitor running with SCHED_FIFO scheduling to prevent realtime client
threads from consuming too much resources?

Or is there some other ways to achieve this? Some kernel patch maybe?

Thanks in advance

[1] http://music.columbia.edu/mailman/listinfo/andraudio

Olivier