Roger Larsson <[EMAIL PROTECTED]> 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