Comment by goodcanadian
Comment by goodcanadian a day ago
Real-time Linux used to be a joke, but apparently now it works.
When was that? I used it over a decade ago, and it worked pretty well even then.
Comment by goodcanadian a day ago
Real-time Linux used to be a joke, but apparently now it works.
When was that? I used it over a decade ago, and it worked pretty well even then.
That page seems to be describing SCHED_FIFO processes, which are already a thing without PREEMPT_RT. Maybe they weren't back in the pre-2.6 days? Anyway, they are usually limited to 95% of total runtime by the sched_rt_runtime_us tunable, to avoid accidental self-DoSing. Maybe that, too, was later invention -- 2.6 is very very old.
The page goes on:
> A patch does exist to enable process to have real-time process access to any process requesting it.
According to the sched(7) man page, this has never been the case: before 2.6.12, the process had to have CAP_SYS_NICE; after, it was limited by policy through RLIMIT_RTPRIO. I guess it's possible that this was not the case for the original out-of-tree patch set.
But it's been there for many years, well before the 2020 edit that added the bulk of the current text on that wiki page.
>completely lock-out a user from their machine, turning that machine into part of a botnet or other malicious purpose
There seems to be a pretty big leap from beginning of that sentence to the end, I personally wouldn't consider local DoS a problem.
Here's when:
https://help.ubuntu.com/community/UbuntuStudio/RealTimeKerne...
> Security Implications
> All it would take is one malicious process to execute and take advantage of the real-time code to completely lock-out a user from their machine, turning that machine into part of a botnet or other malicious purpose. Real-Time processes have the potential to completely take-over a machine. This is the number one reason Ubuntu does not carry a Real-Time kernel.