Skip to content

Draft: Rework how WinRing0 is managed in Windows

Adam Honserequested to merge
winring0_rework into master

Microsoft has flagged the WinRing0 driver that we use for SMBus and Super IO access on Windows as malicious and it is being quarantined by Windows Defender.

See this article for more details: https://www.theverge.com/report/629259/winring0-windows-defender-fan-control-pc-monitoring-alert-quarantine

We don't really have the capability or the resources to write our own SMBus and Super IO kernel drivers and get them properly verified and signed by Microsoft, as this requires at very least a recurring certificate to sign the driver (multiple hundreds of dollars per year at least) and it is uncertain whether you have to be a company in order to even purchase such a certificate.

However, after speaking with one of my contacts at HYTE, it sounds like HYTE is interested in submitting an updated version of WinRing0 for validation by Microsoft. This new version enhances security by requiring that all userspace applications accessing the driver be running as Administrator, so any random user application cannot get ring 0 access (which I can understand being at least a little concerning). Personally, I am absolutely OK with this solution if Microsoft accepts it and HYTE is willing to sign and publish the updated WinRing0 driver. This will, however, mean that any application using it must be run as Administrator all the time.

At the moment, OpenRGB only needs to be run as Administrator once. During this first run as admin, a function at the very beginning of main.cpp installs the WinRing0.sys kernel driver if it is not already installed. Once the driver is installed and functioning, it allows any application to connect to it even with normal user privileges, so we don't have to continue opening OpenRGB as Administrator on every subsequent launch to have access to SMBus. With this new driver, this will no longer be the case. Every time you want to launch OpenRGB and have access to SMBus, you will have to launch it as Administrator.

This is not unheard of, there are already some select few devices in OpenRGB that already require Administrator privileges - namely NVMe and SCSI devices like the XPG Spectrix S40G NVMe SSD and Seagate FireCuda external gaming HDD. These devices are pretty rare in the grand scheme of things though while SMBus devices (especially RGB RAM modules) are very common. We will need to rethink how we indicate to the user that SMBus devices could not be detected.

I think we have three options, but the user should get to make the decision:

  1. Background Service - We can already do this in Linux, and several distro-packaged versions of OpenRGB (including Arch Linux AUR) ship a systemd service file that starts OpenRGB in headless server mode with root permissions. Then, once started, when the user opens the OpenRGB application on their own account, it simply connects to the local server. The server has root permissions and thus can access restricted devices (including the same NVMe and SCSI devices that require root on Linux as they require admin on Windows).

  2. Run as Administrator shortcut - In Windows, it's much easier to run something as Administrator than it is in Linux as root. Just mark the "Run as Administrator" option in a shortcut and it launches as admin, no password prompt or questions asked, and it doesn't cause weird conflicts with user resources like the desktop environment or sound server as it does in Linux.

  3. Run entirely as user, but without SMBus/Super IO support - If the user does not need any of the support provided by WinRing0, they should have the option of just not using it at all. No potential security risk in installing the driver, no requiring admin permissions at all. This option is important still as there may be people wanting to use OpenRGB on restricted accounts such as on work PCs where installing kernel drivers and/or running as admin are not permitted.

To start, I think having OpenRGB try to install a driver that could fall into "potentially unwanted program" territory isn't the best idea. Therefore, with this patch set, the first thing I'm doing is removing the ability for OpenRGB to install the WinRing0 driver itself. Instead, we should come up with an alternate, out-of-app means of installing the driver (whether it's a second .exe installer, a .msi installer, a batch file/PowerShell script, etc) that can both be run standalone (for portable version of OpenRGB) and baked into the .msi OpenRGB installer as an optional checkbox.

We then need to clean up all the references and documentation to "run OpenRGB once as admin" because this will be incorrect after the new version of WinRing0. We will have to refer users to a page telling them how to install the driver and/or to use the .msi OpenRGB installer and check the box to install WinRing0.

Finally, we should probably figure out how to register a background service in OpenRGB and make a script or something to set it up. Again, this should be optional, but it could also be a checkbox in the OpenRGB .msi installer.

I am still waiting to hear back from HYTE about the updated WinRing0 status though, if that doesn't get approved then we'll have to just keep using the "vulnerable" version we're already using and instruct people to add an exception in Defender.

Merge request reports