Linux kernel forced different behavior for processes starting with "X"

Linux kernel forced different behavior for processes starting with “X”


A nasty hack in the Linux kernel that has been online for over three years has been exposed. Due to an X.Org Server/xf86-video-modesetting DDX buggy, the Linux kernel has enforced different behavior depending on whether a process starts with “X” and in turn disables mode setting support atomic.

Linux security researcher Jason Donenfeld (who is also well known for inventing WireGuard), came across this nasty kernel code hack.

Donenfeld commented this weekend on the kernel mailing list:

This negates 26b1d3b527e7 (“drm/atomic: keep atomic toys away from X”), a rootkit-like bogus that has no business inside a general-purpose kernel. This is the type of debugging hack I will use momentarily but never commit, or some sort of babbies-first-process-hider malware trick.

The backstory is that some user space code – xorg-server – has a mode setting DDX which is not really coded correctly. Since no one wanted to maintain X11 anymore, rather than fix buggy code, the kernel was adjusted to avoid having to touch X11. A bummer, but fair enough: if the kernel no longer wants to support certain userspace APIs, the right thing to do is to arrange for a graceful fallback where the userspace thinks it’s not. not manageably available.

However, the *way* to do this is to simply check `current->comm[0] == ‘X’`, and disable it only in this case. So that means it’s *not* just a matter that the kernel no longer wants to support a particular userspace API, but rather that the kernel doesn’t want to support xorg-server, in theory, but in fact, it turns out that all processes start with ‘X’.

Playing games with current->comm like this is obviously wrong, and it’s quite shocking that it ever happened.

The validation of this kernel with the verification of the first character “X” was carried out in September 2019. The argument in this validation of the Linux kernel at the time was:

The -modesetting ddx has the totally wrong idea of ​​how atomic works:

– does not disable old connectors, assuming they automatically disable as with the old setcrtc

– assumes ASYNC_FLIP is hardwired for atomic ioctl

– not a single call to TEST_ONLY

[In other words] the implementation is a 1:1 translation of legacy ioctls to atomic, which is a) broken b) useless.

We already have bugs in i915 and amdgpu-DC where it prevents us from enabling interesting features.

If anyone cares about the atom in X, we can easily add a new atomic level (req->value==2) for X to get the shiny toys.

Since those broken versions of -modesetting shipped, there’s really no other way out of this bind.

The “good” news is that since then, on the userspace side, in 2019 the xf86-video-modesetting code continued and disabled atomic support by default. So technically if you’re running an updated X.Org stack within the last three years, this kernel hack is no longer necessary since userspace then bypasses the atomic API.

We’ll see if Linus Torvalds is okay with removing this hack, because after all, it goes against his “don’t break userspace” principle by then regressing the system if it breaks. sticks to an outdated X.Org server stack and wants to run with a future kernel version. We will see but surprise it took three years for this dirty code to be criticized.

#Linux #kernel #forced #behavior #processes #starting

Leave a Comment

Your email address will not be published. Required fields are marked *