X.Org Server Hit By New Local Privilege Escalation Vulnerability

[ryao]

Even with all the test suites, new tooling (better PL, compiler, linters), better code review, better doc and better understanding of the software written from scratch?

Basically all of that is something that the existing code likely already has, and even if it did not, it is likely not enough to make a difference.

It is hard to replace mature code with something better. In general, the only thing better than mature code is mature code. Writing a replacement for mature code is a recipe for pain for years until it matures. We have seen that with wayland, pulseaudio, systemd, etcetera. It always happens when writing a replacement.

[Sevard]

We have seen that with wayland, pulseaudio, systemd, etcetera. It always happens when writing a replacement.

Wayland isn't really X11 replacement. X11 is giant blob of everything. Some of those functionalities are not needed in modern systems and some should never be handled by windowing system. But the main issue is that there are some issues in X11 core that can never be fixed without breaking protocol. And I really prefer experimental code that can be fixed than mature code that is broken and there's nothing you can do with this. X protocol was designed many years ago and it really doesn't work well in current system and security models.
Here you can find great presentation from one of long time X and Wayland devs https://www.youtube.com/watch?v=cQoQE_HDG8g

PulseAudio doesn't replace anything. That's just another layer that simplifies things a bit. You can still use ALSA or even OSS if you want.

Systemd – it's a bit trickier since Systemd does more than other init systems. It's set of components that can be enabled or disabled as needed. So which components were worse? Main issue with systemd adaptation weren't bugs, but GNU philosophy (do one thing and do it well).

[ryao]

I really prefer experimental code that can be fixed than mature code that is broken and there's nothing you can do with this. X protocol was designed many years ago and it really doesn't work well in current system and security models.

Mature code tends to not be broken. That is a requirement for it to have become mature. You might not like the architecture, but it is reliable at doing what it does because the bugs in it that people tend to hit have all been fixed over the years.

The Linux kernel for the most part (excluding some drivers) is an example of mature code. If you want to use immature code, try using GNU HURD. That code is never allowed to mature since it’s developers are always trying to reinvent the wheel.

The choice between mature code and new code is not between broken and easy to fix code, but between working code and seemingly perpetually broken code. It takes years of full time development for a decent sized code base to mature.

[Sevard]

Mature code tends to not be broken. That is a requirement for it to have become mature. You might not like the architecture, but it is reliable at doing what it does because the bugs in it that people tend to hit have all been fixed over the years.

So X11 is not mature at all. And this ends this discussion.

[ryao]

So X11 is not mature at all. And this ends this discussion.

X11 is a protocol. The display server is mature. Just because you do not like its design choices does not diminish that. I can say the same about Microsoft Windows. The codebase is mature, even if it has bad design decisions.

Anyway, once software is mature, it is very hard to convince people to migrate to something else, especially when that something else requires making compromises that they are not already making. The Xorg X11 server would not have so much momentum if it were not a mature code base.

That said, X11 is much better than much of its historical competition. Extensions have only made it better over the years. For example, X11 was much faster than NeWS:

https://en.wikipedia.org/wiki/NeWS

[Sevard]

X11 is a protocol.

So is Wayland.

The display server is mature.

X Server devs say that it's broken and I'd rather trust them.

Just because you do not like its design choices does not diminish that.

It's not I don't like them. It's just isn't 1984 anymore. Many of choices made some sense back then, but yeah – time moved on.
But it is another story. X Server development used to be hack based for quite some time. Some things were fixed some cannot be fixed without breaking everything else. Check YT link I pasted above to see some examples.

[RavFX]

Wayland, I will use it when, as a gamer, will support changing screen resolution.
Not all games run at 60 fps in 4k on my setup, and when it does not, I set a lower resolution in the game. Here the result:

- Xorg : Screen change resolution and game is in full screen
- Wayland : Screen stay at same resolution and game take 1/4 of the screen, leaving the rest of the screen, black.

Ability for game to change screen resolution work on these : DOS, Windows 3.1, NT4,95,98,ME,2000,XP,7,8,10,11,Xorg
Ability for game to change screen resolution does not work on these : Wayland

Fix it and I might switch to wayland, assuming the other annoying issues are also eventually fixed.

Edit : Not all games support scaling

[MorrisS.]

Actually the only graphical environments supporting Wayland are gnome and plasma excluding the capability of Wayland to run with Nvidia cards properly. Just when Wayland and Nvidia drivers match together, the transition will be able to end supported by Vulkan render. In my opinion Wayland is ready for some time, what is not ready deals with drivers, graphical environment, program compatibility.

[ryao]

So is Wayland.

X Server devs say that it's broken and I'd rather trust them.

It's not I don't like them. It's just isn't 1984 anymore. Many of choices made some sense back then, but yeah – time moved on.
But it is another story. X Server development used to be hack based for quite some time. Some things were fixed some cannot be fixed without breaking everything else. Check YT link I pasted above to see some examples.

I think you mean former Xorg server developers, as the ones who wanted a fresh start switched to working on wayland code.

The Xorg server works for what it was intended to do and that handles most use cases. That being said, you can find developers that will call software broken in just about any project, Former Linux developers working on microkernels will likely say that Linux is broken too and in a way, they are not wrong. The complaints are actually fairly similar. One bad kernel module being able to attack everything else is much like one bad X11 client being able to attack everything else connected to the X11 server. However, broken is not a very descriptive word.

I recall one of the wayland developers stating that wayland could have been a X11 extension. They just chose not to do that.

[NobodyXu]

Basically all of that is something that the existing code likely already has,

Not all "mature code" uses these, especially if they are not well maintained.

and even if it did not, it is likely not enough to make a difference.

Is switching from memory unsafe to memory safe language not a difference?

Is using wasm for sandboxing not a difference?

It is hard to replace mature code with something better. In general, the only thing better than mature code is mature code. Writing a replacement for mature code is a recipe for pain for years until it matures. We have seen that with wayland, pulseaudio, systemd, etcetera. It always happens when writing a replacement.

It's true it takes a lot of effort, but it's not always so hard to come up with something better when many existing "mature" code is in terrible shape.

For example, the mature code in OpenSSL had CVEs like heardbeat because there is not enough funding or devs until a CVE is filled and everybody is panic in fixing their own stuff.

And that's not the only CVEs, it's been a long history of CVEs.

WolfSSL which comes 8 years after OpenSSL, has a much better security history.

Something similar happens to log4j, they did not get enoguh maintenance because everybody thought they are mature code and there's nothing that can go wrong.

So being mature doesn't mean it is necessary better, the code could be in a mess and nobody has enough time/effort to fix them, despite them seemly to "function as normal" until you discover it is malfunctioning.