Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Looks like GPU switching tool optimus-manager isn't abandoned yet

By - | Views: 12,948

As we have previously reported here, optimus-manager, the GPU manager for laptop setups was going silent because the main developer didn't have the time or resources to keep that project running on Github. Looks like it's coming back!

After I got notified that a long-standing bug I'm participating in related to PCI ID generation missing the Domain ID on Xorg configuration generation was closed as fixed, I've noticed that a bunch of other stale Pull Requests got merged recently too.

Referring back to the main discussion thread, "The state of optimus-manager", to my surprise someone nicknamed es20490446e is doing all the hard work to get the software active again and asking people to deliberately tag him on pull requests so he can better handle them because he is not (yet) the owner of the software.

It's nice to have such piece of software back into active state. I've switched back to envycontrol recently because of optimus-manager being abandoned and crashing a lot on newer kernels but, since this software is more feature rich and also supports some of my VFIO (GPU pass-through) stuff, I would definitively give it a try again when it gets in a better shape again.

Article taken from GamingOnLinux.com.
4 Likes
About the author -
author picture
I'm and enthusiast of Linux on Laptops and Secure Boot related stuff. Playing exclusively on Linux since 2013. Played on Wine on dates that trace back to 2008(Diablo 2, Lineage 2...). A troubleshooter that used to work with strace and it is now working with Kubernetes...
See more from me
8 comments

tfk 3 days ago
Don't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.
ShabbyX 3 days ago
Quoting: tfkDon't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.

I scrolled down to comment just that. Damn xz attack is making us all paranoid.
LoudTechie 3 days ago
Quoting: tfkDon't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.

My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.

Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.

Things that are the same:
New maintainer and overworked old maintainer.

Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.


Last edited by LoudTechie on 9 June 2024 at 8:35 pm UTC
Pengling 3 days ago
View PC info
  • Supporter
Quoting: ShabbyXDamn xz attack is making us all paranoid.
Better to be paranoid than complacent, though!
ShabbyX 2 days ago
Quoting: LoudTechie
Quoting: tfkDon't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.

My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.

Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.

Things that are the same:
New maintainer and overworked old maintainer.

Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.

But what if they learned from the xz experience, and now they are going to work on building trust for a year by doing real work before sneaking in an attack?

(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)
LoudTechie 2 days ago
Quoting: ShabbyX
Quoting: LoudTechie
Quoting: tfkDon't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.

My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.

Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.

Things that are the same:
New maintainer and overworked old maintainer.

Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.

But what if they learned from the xz experience, and now they are going to work on building trust for a year by doing real work before sneaking in an attack?

(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)

Maintainer replacement is a rare event.
Big projects are often maintained by the same person for more than 10 years.

The xz attack was "just" ~3 years of work, because they correctly predicted(not as impressive as it sounds) a maintainer that had already been maintaining a valuable project for a long time, who would snap within a manageable amount of time.
For this reason they basically immediately enabled the malware function after this rare event of, which they benefited.

If this maintainer replacement is contrary to the xz attack a cog in some larger more elaborate scheme instead part of the finishing blow, we're dealing here with an attacker with far more resources than the xz attacker(~6 years of dev team time instead of ~3 years, or 1+ election cycle instead of 1- election cycle).
My check ascertained me they're not running the same script as 90% of the current known maintainer replacement attackers.

Also maybe It eases you to know that es20490446e has been active for 7 years(, which is 4 years longer than Jian Tang) and has an inactive period of 3 years before that, which implies that they've had a healthy junior dev inferiority complex.
They also have a widespread widespread social media presence, which is less common among adversaries, because it makes it easier to trace you.
nwildner 2 days ago
Quoting: ShabbyX(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)

And you are completely right being paranoid these days after the xz CVE stuff but, as LoudTechie said above, the guy has a profile of contributing to multiple other opensource softwares and he would be putting his reputation at jeopardy if he really wanted to widespread damage to laptops, or doing some nasty stuff with optimus-manager.

But yeah, these days being paranoic with software should be the modus operandi...
Gazoche about 20 hours ago
View PC info
  • Supporter
Hey, I wasn't expecting to see my project mentioned on GoL! I'm the original creator of optimus-manager (Askannz on Github).

And yeah I admit I haven't been working on it for a long time. It's less than I'm overworked and more that I just don't have the hardware for it anymore. My only testing machine is currently missing a hard drive, a right hinge, and is just generally falling apart (thanks MSI for your wonderful build quality), in addition to having a very old GPU that's not representative of modern Optimus variants. So I'm glad someone else has been picking up the slack. But in any case I'll be keeping an eye on new commits to make sure everything is going smoothly.


Last edited by Gazoche on 12 June 2024 at 12:36 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.