X.Org Server Hit By New Local Privilege Escalation Vulnerability

[ryao]

Did you ignore that in Android 13, Google rewrote the low-level driver into Rust?
And cargo itself is production ready.

I don't think it's fair to say "almost and next to no".

It is fair to say that for any new language.

As for Android, Google is very clear that they are using Rust for new code:

https://security.googleblog.com/2022...ndroid-13.html

The same can be said about every project, including your mature software.
You don't know a bug is present until it's found, so lacks of bug report does not mean lacks of bug.

There are a number of bugs in any non-trivial software that is not formally verified, including OpenZFS. I am working on squashing as many as I can. Unlike new code, the OpenZFS source code at least has the benefit of having had years of validation and debugging, which separates it from freshly written code.

Because this is their proprietary software and it's part of their core business.
Would you expect Google to release its search engine code as open source?

It's already stated that this is a proprietary project by Cloudflare and they have no plan to open source it from day 0.

The fact that Cloudflare is using it where they get GB or TB level of data per second in their data center means they have confidence in it.

Cloudflare explicitly stated that they plan to open source Pingora from the beginning:

https://blog.cloudflare.com/how-we-b...-the-internet/

Cloudflare has an enormous amount of infrastructure. If I were one of their engineers, I would start by putting it into production on a fraction of the infrastructure, monitoring that and expanding from there. The monitoring will likely help to catch reliability bugs, but as far as security bugs go, those will not be caught by monitoring, since you need malicious packets being sent to the servers and until they open source it, outside of fuzzing, the black hat community will have no clue how to send malicious packets to their servers.

Rewrite is hard and it could be buggy at first, but not every rewrite produce more bugs.

Planning not to have any bugs is a recipe for disaster. Anything non-trivial will have many bugs and the first thing that compiles will undoubtedly have an even higher number of bugs. Mozilla, which invented Rust, did not take such an approach to Rust. They waited 5 years before introducing Rust to firefox, by reusing the "stable" portions of the Servo codebase that they had been developing for 5 years.

Just because people don't often rewrite software doesn't mean every rewrite produces more bugs, it's simply that rewrite is very hard and resource consuming.

Rewrites are hard and resource consuming in large part because you need to catch and fix all of the bugs that they introduce.

Getting to the same level as a mature solution takes time. To give a tangible example, we are seeing this right now with Intel's graphics drivers playing catch up with Nvidia's graphics drivers.

Rust do have a few ways of preventing high level logic bugs.
For example, rust has type builder https://www.reddit.com/r/rust/commen...ecked_builder/ which makes sure that you cannot pass invalid combination of values into the builder.

There's also NonZeroUsize, which guarantees that it contains a non-zero usize and creating an instance would check its value and returns an Option<NonZeroUsize>.
And often crates create their own newtype uphold the invariants.

This communicates the invariant explicitly to the user, though the programmer could obviously just ignore it and go head to pass an invalid one, but still using this pattern is much better than not.

A high level logic bug would be something where you cannot have a checker that will identify what is correct unless the checker is checking a proof of correctness for the software as part of formal verification. Here is an example of one of the more expensive ones:

http://edition.cnn.com/TECH/space/99...ars.metric.02/

Here is another example of a high level logic bug where they made a mistake transcribing mathematical equations:

https://medium.com/lessons-from-hist...n-23651aba474d

Interestingly, there are limits to Rust's guarantees even with "safe" Rust. If you use an out of bounds index in a way that the Rust compiler cannot detect in advance, it will terminate the program. Do that based on untrusted inputs in a daemon that provide a network service (e.g. as part of Pingora) and you have a DoS vulnerability. Rust being "memory safe" does not prevent out of bounds issues from being security problems, although it does change those security problems into DoS vulnerabilities. If such a bug exists in Pingora, then Cloudflare could see their CDN trivially disabled by a DDoS attack that operates by exploiting that bug rather than saturating bandwidth, but at least the Pingora code is memory safe.

That said, there is Clippy, which likely helps, provided that people use it:

https://github.com/rust-lang/rust-clippy

[mdedetrich]

Also regarding the wrong point of no software being re-written in Rust, currently a large chunk of user space utils common on POSIX systems are being rewritten in Rust.

• https://github.com/uutils/coreutils
• https://github.com/BurntSushi/ripgrep
• https://github.com/sharkdp/bat
• https://github.com/ogham/exa
• https://github.com/sharkdp/fd
• https://github.com/dalance/procs
• https://github.com/chmln/sd
• https://github.com/bootandy/dust
• https://github.com/cjbassi/ytop
• https://github.com/dbrgn/tealdeer
• https://github.com/polyverse/rmesg/
• https://github.com/ajeetdsouza/zoxide
• https://github.com/dandavison/delta

[mdedetrich]

Rewrite is hard and it could be buggy at first, but not every rewrite produce more bugs.
Just because people don't often rewrite software doesn't mean every rewrite produces more bugs, it's simply that rewrite is very hard and resource consuming.

Rust do have a few ways of preventing high level logic bugs.
For example, rust has type builder https://www.reddit.com/r/rust/commen...ecked_builder/ which makes sure that you cannot pass invalid combination of values into the builder.

The whole point that was glossed over in this asinine debate is those business/logic bugs are almost always the easiest to detect and deal with, especially if the original software you are rewriting has tests (and as you pointed out, if you have a good type system which Rust has then you can even use that to check for certain logic bugs without needing static analysis). So yes a rewrite in Rust can introduce new bugs, its just that its highly likely that if any new bugs are created they will be business logic bugs and if so there is a high chance they are going to be caught almost instantly because they are not that hard to detect and deal with.

This is very different to memory access/concurrency bugs, which is typically the kind of bug that causes developers to pull their hair out. This is one of the major reasons why Rust is getting so much traction, it has a linear type checking that catches the category of bugs that is most hard to find (and hence severe), i.e. its catching all of the low hanging fruit (and more!).

[ryao]

The whole point that was glossed over in this asinine debate is those business/logic bugs are almost always the easiest to detect and deal with, especially if the original software you are rewriting has tests (and as you pointed out, if you have a good type system which Rust has then you can even use that to check for certain logic bugs without needing static analysis). So yes a rewrite in Rust can introduce new bugs, its just that its highly likely that if any new bugs are created they will be business logic bugs and if so there is a high chance they are going to be caught almost instantly because they are not that hard to detect and deal with.

This is very different to memory access/concurrency bugs, which is typically the kind of bug that causes developers to pull their hair out. This is one of the major reasons why Rust is getting so much traction, it has a linear type checking that catches the category of bugs that is most hard to find (and hence severe), i.e. its catching all of the low hanging fruit (and more!).

I had a fantastic reply that preempted what you wrote, but it is waiting in a moderation queue due to an overzealous spam filter. Here is one of the links that I had in it:

https://medium.com/lessons-from-hist...n-23651aba474d

The incorrectly transcribed mathematical equation passed unit tests without a problem.

Rust’s own documentation also states that it does not solve general race conditions:

https://doc.rust-lang.org/nomicon/races.html

In C and C++, we have ThreadSanitizer for finding data races with relative ease:

https://github.com/google/sanitizers...tizerCppManual

It can even detect lock inversion bugs too, which are part of the general category that Rust cannot address.

Also, as I said in my comment that is in the moderation queue, there are limits to Rust’s memory safety guarantees. The rust compiler does not prove the absence of out of bounds conditions because that is too hard, so it uses runtime instrumentation to gain memory safety. If it detects an out of bounds condition at runtime, it terminates the software. If a network service is terminated because a malicious packet causes an out of bounds condition, that is a DoS vulnerability, but at least it is “memory safe”.

Writing new code in Rust can be beneficial since Rust does avoid plenty of classes of bugs and the remaining classes would have occurred in the same frequency anyway, so the result is a net win. However, outside of trivial codebases, it is not as beneficial to write replacements for mature code with Rust. The mature code already has a low number of bugs relative to freshly written code. The freshly written rust code would have plenty of those remaining classes of bugs until it has time to mature. Out of bounds bugs, which cause termination in Rust due to runtime instrumentation, would also be a category of bugs that need to be addressed over time, since not every such bug is trivially detectable by a developer.

By the way, I still want to know which institution issued your degree.

[mdedetrich]

Rust’s own documentation also states that it does not solve general race conditions:

https://doc.rust-lang.org/nomicon/races.html

Dude why are you still responding? You actually didn't even read the god damn documentation you are using to try and "prove" that you are right. Let me quote relevant paragraph

This is pretty fundamentally impossible, and probably honestly undesirable. Your hardware is racy, your OS is racy, the other programs on your computer are racy, and the world this all runs in is racy. Any system that could genuinely claim to prevent all race conditions would be pretty awful to use, if not just incorrect.

In other words its not that Rust cannot prove that the code you wrote specifically in Rust is data free, its that because programs don't exist in a vacuum and are run in an OS its entirely possible for either the OS and/or hardware to be racy which Rust written program has to interact with. And no, I am not interested in reading the rest of your damn post because tbh, every single time you post something to try and defend yourself from being so defensive in the first place you don't even understand what it is your posting and this specific one generated a pretty massive seismic facepalm from my end.

Please just stop we don't need a second oiaohm, i.e. someone that just quotes random material from the internet posing as if they know what they are talking about when they don't. I don't even know why you are so defensive, rather than being intellectually honest instead you give off the "oh no, someone (i.e. Rust) is taking my job" vibe, i.e. any kind of factual aspect where Rust can do things better than other languages (such as C/C++) instead of you spending like 10 f**ken minutes of Googling to verify that actually, Rust is being used and its been considered a mature language for some time now you instead outright ignore and give the worst take on everything being mentioned, even going down to the compete level of horsesh**t where you entirely dismiss statements from a commercial company stating that they recoded an entire system in Rust because that code is not publicly available????? What the flying turtle are you smoking, that is like 1990-2000's Intel/Microsoft level FUD bad.

[ryao]

Also regarding the wrong point of no software being re-written in Rust, currently a large chunk of user space utils common on POSIX systems are being rewritten in Rust.

• https://github.com/uutils/coreutils
• https://github.com/BurntSushi/ripgrep
• https://github.com/sharkdp/bat
• https://github.com/ogham/exa
• https://github.com/sharkdp/fd
• https://github.com/dalance/procs
• https://github.com/chmln/sd
• https://github.com/bootandy/dust
• https://github.com/cjbassi/ytop
• https://github.com/dbrgn/tealdeer
• https://github.com/polyverse/rmesg/
• https://github.com/ajeetdsouza/zoxide
• https://github.com/dandavison/delta

I do not think I said no software is being rewritten in Rust. I said it was not worthwhile to do, although the results could be good in the long term after the maturation pairs end.

[ryao]

Dude why are you still responding? You actually didn't even read the god damn documentation you are using to try and "prove" that you are right. Let me quote relevant paragraph



In other words its not that Rust cannot prove that the code you wrote specifically in Rust is data free, its that because programs don't exist in a vacuum and are run in an OS its entirely possible for either the OS and/or hardware to be racy which Rust written program has to interact with. And no, I am not interested in reading the rest of your damn post because tbh, every single time you post something to try and defend yourself from being so defensive in the first place you don't even understand what it is your posting and this specific one generated a pretty massive seismic facepalm from my end.

Please just stop we don't need a second oiaohm, i.e. someone that just quotes random material from the internet posing as if they know what they are talking about when they don't. I don't even know why you are so defensive, rather than being intellectually honest instead you give off the "oh no, someone (i.e. Rust) is taking my job" vibe, i.e. any kind of factual aspect where Rust can do things better than other languages (such as C/C++) instead of you spending like 10 f**ken minutes of Googling to verify that actually, Rust is being used and its been considered a mature language for some time now you instead outright ignore and give the worst take on everything being mentioned, even going down to the compete level of horsesh**t where you entirely dismiss statements from a commercial company stating that they recoded an entire system in Rust because that code is not publicly available????? What the flying turtle are you smoking, that is like 1990-2000's Intel/Microsoft level FUD bad.

I did read that and it shows that there are limits to what Rust can do, which directly contradicts your suggestion that
rust prevents concurrency bugs. To elaborate, the “category of bugs that is most hard to find (and hence severe)” would be general race conditions thanks to ThreadSanitizer.

People here seem to think Rust is a silver bullet such that rewrites in rust are always a good idea, but the reality is that rewrites in Rust are not free from maturation pains, so they are less worthwhile as a solution to the existence of bugs in existing mature code. You are basically trading one set of issues for another by doing that in the short term and some simple projections show that the bugs should be greater in the new rust code (e.g. assuming 10x the bugs in new code and that rust prevents 70% of them, leaves 3x the bugs). I am tired of seeing this nonsense that rewrites in rust are the solution to all ills and that mature code is garbage on these forums, so I am taking a stand against it.

Do not misunderstand me. I do think well of Rust. I just do not take those good thoughts and suggest that Rust can solve problems it cannot by saying rewriting things in rust will fix all ills. I do say that after the rust code matures, it should be better than the existing code that it replaces (compared to what it was at the time the replacement started development), but the time needed for that often could be used to get the existing code to a similar level without subjecting end users to maturation pains.

As for whether Rust is a mature language, that is tangential to everything being discussed.

As for comparing me to oiaohm, that is a big insult and it is wrong. First, he is demonstrably mentally ill with untreated schizophrenia. Second, he has no actual experience and is a true armchair expert.

That said, I still want to know which institution issued your degree. I have been involved with hiring decisions at various companies. Knowing which institution issued your degree would be helpful to me when I participate in those decisions. In particular, if I meet enough quacks with degrees from your institution, I will just black list it and your degree will be worth slightly less than it is currently worth. Posting incorrect technical information online has consequences, even if that information is popular among armchair experts and enthusiasts due to a misunderstanding of what actual experts are saying.

You could try to use those words against me, but unlike you (and oiaohm), I have an established public record in developing reliable system software. I am also hardly alone in what I say, but I am one of the few in the field willing to post here. Most who post here are enthusiasts and armchair experts.

That being said, I am posting to combat your misinformation for the benefit of others, rather than for your benefit, since it is clear to me that you are a lost cause. I would prefer it if you did not read my replies since then you would not post replies that I would feel obliged to correct. Honestly, you really should have given up after the following comment:

https://www.phoronix.com/forums/foru...19#post1372619

Between the two of us, you are less qualified to make statements about software reliability, yet you keep doing it with the audacity to tell an actual expert that he is clueless. :/

[ryao]

Assuming that this is mdedetrich, I think I understand why he is spreading the nonsense that fresh rewrites in Rust are more reliable than mature C code:

https://github.com/mdedetrich

He is a scala developer. Scala is a functional programming language that avoids many of the same classes of bugs that Rust does. It lives on the JVM and tends to co-exist with Java, which also addresses many of the same classes of bugs that Rust does.

Proponents of functional programming languages are often heavy critics of C. mdedetrich clearly fits the stereotype of a fanatical functional programmer and thus he cannot accept the idea that a fresh rewrite of mature C code could be worse than the existing code since to functional programming fanatics, all C code is automatically bad (with perhaps the exception of formally verified C).

Interestingly, Kafka, one of the projects that he develops, has no end of bugs that a rewrite in Rust cannot address if the commit history is any indication:

https://github.com/apache/kafka/commits/trunk

I suspect that he would become more reasonable if the discussion shifted to rewriting Kafka in Rust. Clearly, there will initially be more bugs from doing that, such that Rust is not a silver bullet. We can observe that using Java+scala instead of C in the first place was not a silver bullet either. That is talking about bugs in general, but in terms of security bugs, it has not been immune either:

https://kafka.apache.org/cve-list

If we ignore log4j, then it has had a fairly good track record, although it should have less attention from security researchers than more widely used projects. It is likely run on private networks too, which means it is not typically something an attacker can target until he is already inside an organization.

Also, I am not surprised that he seems entirely ignorant of improved development tools for C that tackle many of the short comings that memory safe languages address. When you spend your career assuming C is bad, of course you would not know about improvements to C development tools.

[NobodyXu]

ryao I do not think Rust is a magic bullet, and with that said I think there's no point in arguing.
Let's agree to disagree and I have a quite busy life right now and I would rather spend more time working on OSS projects and my own ideas to try out, provided there are inf many of them...

[ryao]

ryao I do not think Rust is a magic bullet, and with that said I think there's no point in arguing.
Let's agree to disagree and I have a quite busy life right now and I would rather spend more time working on OSS projects and my own ideas to try out, provided there are inf many of them...

We can agree to disagree until you realize that the propaganda that rewrites in Rust are guaranteed to be better than mature code is false. Most people will realize that within 10 years. I am just sick of seeing it and 10 years is a long time to wait, so I felt obligated to say something. I have already been through this once with Java and I will be through it again with Rust. What really bothers me is that after people learn that, I will have to go through this again with the language that comes after Rust. Just thinking about it makes me want to speak out to try to end this frustrating cycle, since it is painful to watch. :/