8 ms·

Here's when: https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel https://help.ubuntu.com/community/UbuntuStudio/RealTimeKerne... > Security Implicat

by akikoo 2y ago

Here's when: https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel 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.

PhilipRoman 2y ago
>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.
Snild 2y ago
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.