Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
From: Jack O'Quin (joq_AT_io.com)
Date: Wed Nov 19 2003 - 02:40:54 EET


Roger Larsson <roger.larsson_AT_norran.net> writes:

> Problem is - why doesn't most distributions even ship with wrappers suid
> to be able to start the application with SCHED_FIFO/RT/mlock?
> - It is due to risks of local Denial Of Service attacks (intentional or
> unintentional)

That seems logical, but AFAICT the actual reason is because of a
security hole introduced by CAP_SETPCAP (which was not part of the
original POSIX draft spec). Before this screwup was detected, kernels
shipped with capabilities enabled.

If an attacker manages to subvert one of the system daemons with a
buffer overflow (sendmail is a frequent target), it can use
CAP_SETPCAP to deny capabilities to other system services that need
them to perform their jobs, including monitoring system security.

> So with any scheme that opens up these holes you have to deliver a way
> to protect from the downsides.

Clearly this is desirable. But, for many audio workstations it is
*not* mandatory.

> My monitor protects from CPU overuse, but what about memory?
> How to protect from an application that mlockall(MCL_FUTURE) and
> has a memory leak?

If you fail to solve this problem, then we end up back where we are
right now: patching kernels or running untrusted audio applications as
root. This solution is much worse than the problem you were trying to
solve.

> One important thing to remember - if you like to get broad acceptance
> you have to suggest a solution that solves these problems. I would say
> that the rt_monitor or some other means to do the same thing is
> mandatory to get that kind of acceptance.

But, only if it works. It would really be great if you *could* come
up with a solution.

> > The big difference between realtime and most other kinds of
> > performance work is that it focuses on tuning the "worst case", not
> > the average. Paging works fine on average, but in the worst case your
> > recording session gets blown.
>
> SCHED_FIFO does not make ANY guarantees on "worst case"!

I didn't mention "guarantees", I spoke of "focusing on tuning". Big
difference.

SCHED_FIFO is a blunt instrument. By itself, not adequate for much of
anything. Used in conjunction with carefully tuned hardware and
software, a low-latency kernel, and a known set of well-written audio
applications, rather decent realtime performance can be achieved with
only commodity hardware and free software. That's not bad.

> > Otherwise, a good solution. Perhaps adequate for some applications.
>
> But at the same time SCHED_FIFO is adequate for most applications.
>
> See my point? :-)

No, I don't.

-- 
  joq


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 19 2003 - 02:38:44 EET