X.Org Server Hit By New Local Privilege Escalation Vulnerability

[Sevard]

For every issue found in mature code, there will be many more bugs found in new code.

It's kind of true when you add new code to existing software. But it's not necessary true when you write something from scratch. Old code tends to have some functionalities that you don't need anymore. And also old code often has some hacks that were needed to add new functionality/fix something and maintain backward compatibility at the same time. That makes old code more complex than it should be and more complexity = more potential bugs.
Wayland isn't really X11 rewrite. It's protocol that's written from scratch. Some of X11 functionalities won't ever be implemented in Wayland. And since Wayland doesn't need to be backward compatible with X11, some things can be done in different way. It also means that Wayland will never have feature parity with X11 and actually it's good.

[Britoid]

Wayland is arguably more mature than Xorg: developers were able to learn from the mistakes in Xorg, which couldn't be done in Xorg itself due to being constrained by backwards compatibility.

Wayland actually more matches to how modern graphics hardware works and is far better for embedded hardware (it's more similar to Androids SurfaceFlinger than Xorg), there's a reason why Asahi Linux has a Wayland driver and not an Xorg one already.

[Slartifartblast]

Would be good if we had a nice stable alternative to turn to, unfortunately it seems only half baked at the moment and GIMP 3 will be released before it can be considered beta software.

Yes, I mean you Wayland.

[Sergey Podobry]

And studies have shown that such memory management related errors account for ~70% of the related security issues found in modern software, especially software written in C/C++ (which Xorg is a typical example of).

Xorg is written in C. In C++ people are using std::unique_ptr that eliminates this kind of errors.

[reba]

Xorg is written in C. In C++ people are using std::unique_ptr that eliminates this kind of errors.

https://conscientiousprogrammer.com/blog/2014/12/21/how-to-think-about-rust-ownership-versus-c-plus-plus-unique-ptr/

https://www.reddit.com/r/rust/comments/dhvxff/comment/f3tswv7/

[ClosedSource]

Historically, people will switch platforms instead of adopting safer versions of current ones. For example, IE was very unsafe but people used it anyway. The only way to allow people to get off IE was to get them to use Firefox. Then google chrome forced itself by bundling itself with random software and appointing it as the default browser.
Mozilla and Google did a very huge favor to Microsoft here because Microsoft was able to phase out IE without disturbing workflows and then shipping edge instead.
If you want people to get off Xorg, you need a whole new platform for the Linux desktop instead of kwin/mutter adapted to wayland. You can ship ubuntu with wayland as default but there are massive markets in Asia, Middle East, and north Africa that haven't even heard of AMD. They are perpetually stuck on NVIDIA and Xorg. Similarly to the platform concept, you have to switch those to AMD to get them off Xorg which is not going to happen in our lifetimes.

[ryao]

Oh yeah, John Carmack, the most overrated developer in the gaming industry.... Was involved in Doom 30 years ago, then somehow his word is gospel even decades after he stopped being relevant or even coding himself (and left after the disgrace that was Rage proved he had lost his touch)... Still has faithful religious zealots that take his words as gospel it seems...

No, good coders do not easily make mistakes. And modern tools are better for writing bugless code than older tools. Yes, mistakes do happen, but believing that professional software engineers are chimpanzees incapable of learning from their mistakes, is only something that hack, Carmack, and his gaming fanbois, would say and defend.

In fact, newer code tends to be safer, more stable, and more optimized than older code in my experience. Back in the day no one was experienced in parallel programming and multithreaded software was garbage, for example. These days you can see that people have gained experience in managing more threads, and the software frameworks/libraries they use are better as well.

My experience is the opposite of yours and unlike you, I actually have experience doing software development. Anyone saying what you are saying either has never written software or is a novice at it. :/

Also, mature software is not a museum piece. It will gain the same improved tools and improvements to dependencies that are available to newer software. As for “how threads are managed”, well written threaded code from decades ago really would not see any improvements from a rewrite today, since very little has changed. If it can be done better, the code would probably be rewritten by its maintainers to do it better, with far less risk of bugs than an entirely new codebase brings.

By the way, John Carmack mentioned Rage in his article. He stated that the issues were mostly graphics driver bugs that were beyond his control. There is also some irony that you are pushing a false narrative that newer code is more reliable than mature code, yet criticize the new code that was Rage.

[binarybanana]

Wayland actually more matches to how modern graphics hardware works and is far better for embedded hardware (it's more similar to Androids SurfaceFlinger than Xorg), there's a reason why Asahi Linux has a Wayland driver and not an Xorg one already.

Wayland compositors don't use any special drivers. They use the common DRM/KMS kernel infrastructure, plus mesa for GL. They also pretend modern GPUs don't have blitters, which isn't true at least on Intel hardware (where it also does scaling, rotation, transformation, alpha blending, etc.) although in theory they could use it for compositing like some X11 compositors do through XRender. Most GPUs also support an overlay plane which Xorg exposes through xv. This is mostly used for video but it's interesting because it can be synchronized to the monitor refresh independently of the main framebuffer (like the mouse cursor). Anyway, if Wayland works so should Xorg with the modesetting driver.

[ryao]

Well if we are talking about these kinds of security vulnerabilities and rewriting it in Rust specifically, such a vulnerability wouldn't be possible in Rust (Rust fails to compile on use after free errors).

That being said, I don't think any sane person would think its wise to rewrite X.org in Rust but its for other reasons.





While this is true, as with any study/analysis the hypothesis/requirements need to be taken into account. Most of this analysis is not rewriting the software in a safer language (i.e. Rust), instead its about rewriting it in the same typical popular but unsafe languages that most people are used to. Point here is that Rust is very unique in this regard, its one of the only mainstream languages that actually prevents an entire suite of security issues.

And there have been studies on this, and it does show that Rust does significantly reduce such types of errors. This is why even for non trivial software (i.e. Firefox), people have been rewriting parts of it exclusively in Rust.





This is not entirely true. Type systems which is how Rust implements its compile time checks for memory access (specifically its a linear type system) has been formally verified to be correct, and type systems are equivalent to mathematical proofs.

Now of course that doesn't mean that Rust can prove everything, thats not even possible (see godel's incompletness theorem), but what it does mean is that you can prove that certain parts of the program will uphold a certain property. So if we are talking about use after free errors, which is a subset of memory management related errors then Rust can absolutely prove that assuming you don't use unsafe, that these specifics errors won't happen.

And studies have shown that such memory management related errors account for ~70% of the related security issues found in modern software, especially software written in C/C++ (which Xorg is a typical example of).

Rust is not 100% immune to memory issues, since it needs unsafe Rust to work in many cases and unsafe Rust is well known to suffer from memory issues. For example:

https://www.infoq.com/news/2021/11/rudra-rust-safety/

For completeness, I should add that compiler bugs can also result in memory safety issues.

However, even if there really were no memory safety issues, other classes of bugs would occur in enough abundance to make replacements more buggy than the original software. Let us say that a rewrite from scratch will have 10x the bugs (which is likely a conservative estimate). Then even if you eliminate 70% via memory safety, you still have 3x the bugs. This is why you have various industry leaders that encourage Rust adoption suggesting that Rust be used only for new projects rather than calling for complete rewrites in Rust.

[NobodyXu]

Also, mature software is not a museum piece. It will gain the same improved tools and improvements to dependencies that are available to newer software.

No, that's not always true.
if you checkout bash source code, you will find it still using K&R style function declaration.

And how many codebase is permanently sticks to old version of C++?
The adoption of new C++ version has been very slow, even the C++ creator himself admits it.

As for “how threads are managed”, well written threaded code from decades ago really would not see any improvements from a rewrite today, since very little has changed. If it can be done better, the code would probably be rewritten by its maintainers to do it better, with far less risk of bugs than an entirely new codebase brings.

But how many of them are actually properly done?
And what makes you believe the maintainers would do their best when the code is too complex and they don't have enough effort to optimize it?

In the case of X, the code is so complex that they give up maintaining it and plan for next-gen from 10 years ago.