Please don't move processes out of cgroups
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- c
- Domain
- operating-systems, performance, security
Research direction
Start by reading the code that matches literal process names, the config entries for services such as gdm-session-worker and pipewire, and the logic that moves processes into bespoke .scope units. Check how those paths interact with systemd cgroup hierarchies, resource limits, and OOM handling. Done requires an agreed replacement design that preserves systemd management and addresses the reported security and classification concerns.
Written by the indexing model from the issue text.
Description
Hello! I just happened to be looking this project (considering it for inclusion into GNOME OS), and was surprised to find code that does things like:
- matching processes by their literal process name
- ripping processes out of systemd's cgroup management heirarchy and into bespoke .scope units
This will break lots of things in various ways that aren't immediately obvious. I'll give a few examples:
- systemd's cgroups are structured to allow power management decisions to take place. For instance, background services are placed in a special background.slice so that resource limits can be applied to it. lpmd rips these processes out of these heirarchies, so the units end up in the generic app.slice and don't get the system's resource usage policies applied correctly
- systemd-oomd operates on the assumption that it can safely kill an app by killing the app's cgroup. lpmd moving individual processes out of the cgroup without the app's consent violates that assumption and will subtly break the system's OOM management (where apps will not get cleanly OOM killed as intended)
- I would consider lpmd moving processes out of systemd's configured cgroups and into its own a security vulnerability: the cgroup heirarchy enforces things like memory usage limits, CPU time limits, etc. If a system administrator configures such limits for security reasons (to prevent untrusted code from DOSing the system, for example), intel-lpmd moving that process out of that management heirarchy allows it to escape those restrictions. Absolutely nothing prevents malicious code (isolated in a container, for instance) to name its process "pipewire" and then magically get moved out of the restricted cgroup that's supposed to contain it.
I also heavily question some of the decisions made in lpmd's config file listing services by process name. For instance, gdm-session-worker, gdm-wayland-session, and gdm-x-session are all listed as "user_interactive", when really they aught to be "background" (maybe one of them qualifies for "utility"). Most of the daemons lpmd tries to list as background are already in systemd's background.slice and are already treated specially by systemd for system resource limits (and LPMD moving them out of that cgroup heirarchy ironically enough disrupts systemd's ability to do that).
Ultimately, this feature is ill-conceived, and I would highly suggest that it be replaced with something that has design involvement from upstream Linux desktops. At the moment, this code being in intel-lpmd excludes it from use, which is unfortunate because we would ultimately like to integrate the OS with the hardware's P/E/L core to extend the battery life for our end-users
- Dominant language
- C
- Stars
- 235
- Forks
- 33
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from intel/intel-lpmd
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
intel/intel-lpmd#137 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
intel/intel-lpmd#125 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
intel/intel-lpmd#140 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
intel/intel-lpmd#139 ·
-
Native IRQ affinity is not restored after the first cycle in multi-state configurationsPossibly taken @0x484558 claimed this 39 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
intel/intel-lpmd#126 ·
All issues in intel/intel-lpmd
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
area:buffer good first issue type:documentation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sudo-project/sudo#586 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
Abort (SIGABRT) when stderr is a closed pipe: uncaught fmt::system_error in ccache_main's catchPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 3 days