At this time, it is a very limited, single-source language, while Linux runs on tons of hardware. Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware.
Linux runs on many obscure platforms, but the vast majority of Linux devices run on only a few platforms. If Rust proves to work well in practice for kernel code, it will become the responsibility of the people who care about the obscure platforms to ensure that LLVM supports them or they'll be left behind. I'm not saying this is what will happen, but if Rust proves to be as effective as it has the potential to be, the kernel will undoubtedly choose to move forward at the expense of obscure platforms.
Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
The difference between you and me maybe that I have seen countless hypes of the type "Tool/language/approach XYZ will finally fix software errors!". None of them ever has panned out. Assembler code was not more error prone than C and C is not more error prone then Rust. The reason to use C and not assembler is portability and higher productivity. But in a kernel-setting, things end there. The amount of control C gives is _needed_.
Assembler code was not more error prone than C and C is not more error prone then Rust.
Do you have som proof for this? Because otherwise it sounds like nonsense. There is a class of wrong programs which are possible in assembler and are not possible in C (e.g. programs having all the type mishmash errors C compilers catches). That means a programmer can make more errors in assembler than in C. That almost definitely means there more errors in assembler than in C provided that the scope of implemented functionality is the same.
Relationship between Rust and C is analogous to the one between C and assembler.
The amount of control C gives is _needed_.
If there is something which is missing in Rust for Linux kernel drivers then they can identify it and add it. That will be good for both Linux and Rust.
TLDR: swillden is very right in his argument and your rebuttal is weak.
Since the integration of the Rust CSS engine in Firefox in 2017, its had the same number of memory corruption security vulnerabilities as Chrome's CSS engine and 1 less than IE/Edge's engine over the same time period. It also managed to introduce a variety of lower severity logic errors presumably from being an immature code base. While the timeline is still short and so a definitive conclusion is hard to reach, at the moment it seems hard to justify the 2 year process going into producing that CSS engine w
Interesting. Do I understand it correctly that he compared an old C++ code base to a new Rust code base? If so then more effort was already invested into fixing the old C++ code than into the new Rust code. That would mean that his comparison is biased in favor of C++, That is in addition to the fact that the one Rust memory error may have been related to interfacing with C++.
Interesting. Do I understand it correctly that he compared an old C++ code base to a new Rust code base? If so then more effort was already invested into fixing the old C++ code than into the new Rust code. That would mean that his comparison is biased in favor of C++
Yes, and while I'd say the bias in theory should be minimal your point is not entirely incorrect. So, I took a look at CVEs for the three projects and noted the following, for the preceding four years (the same length as now being compared with rust/c++):
- Chrome had the newest code base having forked from Webkit to Blink in 2013
- Firefox had the oldest code base, originally extending from Netscape in something like 1998
- Firefox had 9 memory related vulnerabilities in its CSS engine dating back to 2
From the data above, it actually looks very well for Rust. It is the youngest code and has only 0.25 errors per year so far.
I clipped most of what you said as redundant, but it works out to be basically the exact same thing as if they hadn't switched to rust or at least that's the case so far. Additionally, IE/Edge's code base is the newest, not Stylo (2019 when they again switched engines to one chromium based v. 2017)
Rust type system ensures you cannot have a memory error if you do not use unsafe code (marked explicitly as unsafe in the code).
I didn't overly comment on it because I left it as a task for myself to investigate more, but the UaF in question in framing, at least in theory, is something that Rust could realistically encounter. The way the
You cannot keep a reference to an object which is out of scope in Rust without sneaking it out using unsafe casts. The fact that C++ and Rust use the same back end does not have any influence on this. Rust front end translates to LLVM assembly. That is much lower level type system than C++. It is just an assembly with types. Life time management was already done by the front end and its preservation is enforced by data dependencies in the generated LLVM assembly. Low level optimizer and machine code generat
Yes, and while I'd say the bias in theory should be minimal your point is not entirely incorrect. So, I took a look at CVEs for the three projects and noted the following, for the preceding four years (the same length as now being compared with rust/c++):
I applaud your attempt to put this discussion on a factual basis. Unfortunately, CVEs are not a good way to measure security vulnerabilities. There are many CVEs that are incredibly narrow, while many others are incredibly broad. The number of CVEs filed against a particularly component depends heavily on researcher interest, and where CVEs are reported by developers, on developer focus.
I hate to simply argue that your analysis is useless without providing something better, but the truth is that systemati
Why do you assume more ways errors can be made results in more errors? There is no sane reason for that assumption. Coding is not a randomized process.
"I go on working for the same reason a hen goes on laying eggs."
- H. L. Mencken
Rust would have to run anywhere Linux runs... (Score:3, Insightful)
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware. Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
Re: (Score:3)
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware.
Linux runs on many obscure platforms, but the vast majority of Linux devices run on only a few platforms. If Rust proves to work well in practice for kernel code, it will become the responsibility of the people who care about the obscure platforms to ensure that LLVM supports them or they'll be left behind. I'm not saying this is what will happen, but if Rust proves to be as effective as it has the potential to be, the kernel will undoubtedly choose to move forward at the expense of obscure platforms.
Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
You're
Re: (Score:2)
The difference between you and me maybe that I have seen countless hypes of the type "Tool/language/approach XYZ will finally fix software errors!". None of them ever has panned out. Assembler code was not more error prone than C and C is not more error prone then Rust. The reason to use C and not assembler is portability and higher productivity. But in a kernel-setting, things end there. The amount of control C gives is _needed_.
Re:Rust would have to run anywhere Linux runs... (Score:2)
Assembler code was not more error prone than C and C is not more error prone then Rust.
Do you have som proof for this? Because otherwise it sounds like nonsense. There is a class of wrong programs which are possible in assembler and are not possible in C (e.g. programs having all the type mishmash errors C compilers catches). That means a programmer can make more errors in assembler than in C. That almost definitely means there more errors in assembler than in C provided that the scope of implemented functionality is the same.
Relationship between Rust and C is analogous to the one between C and assembler.
The amount of control C gives is _needed_.
If there is something which is missing in Rust for Linux kernel drivers then they can identify it and add it. That will be good for both Linux and Rust.
TLDR: swillden is very right in his argument and your rebuttal is weak.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Interesting. Do I understand it correctly that he compared an old C++ code base to a new Rust code base? If so then more effort was already invested into fixing the old C++ code than into the new Rust code. That would mean that his comparison is biased in favor of C++
Yes, and while I'd say the bias in theory should be minimal your point is not entirely incorrect. So, I took a look at CVEs for the three projects and noted the following, for the preceding four years (the same length as now being compared with rust/c++):
- Chrome had the newest code base having forked from Webkit to Blink in 2013
- Firefox had the oldest code base, originally extending from Netscape in something like 1998
- Firefox had 9 memory related vulnerabilities in its CSS engine dating back to 2
Re: (Score:2)
Re: (Score:1)
Ok; to sum it up:
From the data above, it actually looks very well for Rust. It is the youngest code and has only 0.25 errors per year so far.
I clipped most of what you said as redundant, but it works out to be basically the exact same thing as if they hadn't switched to rust or at least that's the case so far. Additionally, IE/Edge's code base is the newest, not Stylo (2019 when they again switched engines to one chromium based v. 2017)
Rust type system ensures you cannot have a memory error if you do not use unsafe code (marked explicitly as unsafe in the code).
I didn't overly comment on it because I left it as a task for myself to investigate more, but the UaF in question in framing, at least in theory, is something that Rust could realistically encounter. The way the
Re: (Score:2)
You cannot keep a reference to an object which is out of scope in Rust without sneaking it out using unsafe casts. The fact that C++ and Rust use the same back end does not have any influence on this. Rust front end translates to LLVM assembly. That is much lower level type system than C++. It is just an assembly with types. Life time management was already done by the front end and its preservation is enforced by data dependencies in the generated LLVM assembly. Low level optimizer and machine code generat
Re: (Score:2)
Yes, and while I'd say the bias in theory should be minimal your point is not entirely incorrect. So, I took a look at CVEs for the three projects and noted the following, for the preceding four years (the same length as now being compared with rust/c++):
I applaud your attempt to put this discussion on a factual basis. Unfortunately, CVEs are not a good way to measure security vulnerabilities. There are many CVEs that are incredibly narrow, while many others are incredibly broad. The number of CVEs filed against a particularly component depends heavily on researcher interest, and where CVEs are reported by developers, on developer focus.
I hate to simply argue that your analysis is useless without providing something better, but the truth is that systemati
Re: (Score:2)
Why do you assume more ways errors can be made results in more errors? There is no sane reason for that assumption. Coding is not a randomized process.