It seems to me that there's a lot of unnecessary confusion coming from people not understanding that there are actually two linked but separate mechanisms being talked about here.
One is the SCHED_RESET_ON_FORK flag, which solves the "busy fork bomb" problem. AFAICS this removes the major problem with trusting RLIMIT_RTTIME.
The other is the RealtimeKit daemon, which allows processes to gain realtime priority within the control of the distribution and without the user having to edit nasty config files. It relies on having SCHED_RESET_ON_FORK available, but the reverse is not true.
This makes it a lot easier to accept the two things independently. One is a pure kernel patch, and the other is a userspace control for it.
Posted Jul 2, 2009 2:07 UTC (Thu) by jwoithe (subscriber, #10521)
[Link]
> One is the SCHED_RESET_ON_FORK flag, which solves the "busy fork bomb"
> problem. AFAICS this removes the major problem with trusting RLIMIT_RTTIME.
Yes, it addresses the fork bomb problem. However, a thread-based attack (that is, a "busy clone bomb" for want of a better description) is not prevented by the SCHED_RESET_ON_FORK functionality (if I understand things correctly).
Regards
jonathan
RealtimeKit and the audio problem
Posted Jul 2, 2009 4:40 UTC (Thu) by salimma (subscriber, #34460)
[Link]
Would a "thread bomb" really be possible? As I understand it, all the threads created by a process would cumulatively consume the resource limits of the containing process -- so in this case, all the threads run in real time, but the more threads are created, the less each of them gets to execute before RTLIMIT.
RealtimeKit and the audio problem
Posted Jul 2, 2009 4:54 UTC (Thu) by jwoithe (subscriber, #10521)
[Link]
I'm only echoing some of the concerns expressed by others on the LAD mailing list. I'm not sure of the precise mechansims they have in mind.
RealtimeKit and the audio problem
Posted Sep 28, 2009 5:31 UTC (Mon) by naptastic (subscriber, #60139)
[Link]
Has anyone ever actually been attacked by a "busy fork bomb"? Where do they come from? How do they get started? I see three scenarios:
1. Malicious software exploits some other vulnerability first, in which case rtkit or PAM limits are unlikely to do any good anyway.
2. A naive user clicks a link or opens an email with malicious code. Correct me if I'm wrong, but I'm under the impression that neither Firefox nor Thunderbird are usually run with real-time permissions?
3. A user runs malicious code they crafted themselves. It should go without saying that in this instance, real-time priority inheritance is the very least of the administrator's worries.
RealtimeKit and the audio problem
Posted Oct 1, 2009 21:16 UTC (Thu) by nix (subscriber, #2304)
[Link]
I've had 3) before. 'Crafted' was perhaps a bad word for something with a
bug that size in it, though.
(Mind you, it would have been every bit as devastating if it hadn't been
realtime: it *is* still a fork bomb...)