6 ms·

isn't this a bit too optimistic? Rust as a language to write kernel drivers for <POPULAR ARCHITECTURE> is a great achievement, but what about all the other ar

isn't this a bit too optimistic? Rust as a language to write kernel drivers for <POPULAR ARCHITECTURE> is a great achievement, but what about all the other architectures that only have a C compiler and do not want/can't to depend on LLVM? What about the billions poured into LLVM that made writing an optimizing Rust compiler possible in reasonable time, that is still written in C++? Lastly, I hope to be wrong on this, but watching at Google history being backed by them is, unfortunately, a course,

arunc 4y ago
Compilers are just short running tools. They can hog as much memory for the short period during compilation and die away after that. But a kernel is a critical piece of long software that can have CVE. The criticality is not to have the CVE in the first place.
- peoplefromibiza 4y ago
  > The criticality is not to have the CVE in the first place. I guess the most critical part of a Linux Kernel is being able to compile it in the first place for the architecture you're using. Virtually every platform/architecture out there provides a C compiler. Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. There's certainly hope, it doesn't mean data will prove us right.
  - hardware2win 4y ago
    >Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. We have https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
    - peoplefromibiza 4y ago
      There's literally no single data point regarding Rust. You can't compare the number of bugs in a 20 years old C software (C++ in the case of Chrome, which is another beast entirely) with wishful thinking.
      - insanitybit 4y ago
        You will never have the data you're asking for. There are a number of papers about language impact on software quality and they all suffer from numerous issues - there are tons of confounding variables; Use two different devs and you can't account for experience, use the same dev and you taint the second project, use two different projects and you can't account for the differences, etc. The reality is that whatever data you want is pointless. Anyone who knows what they're talking about should be able to very easily conclude that Rust will have fewer memory safety issues than C. Arguing about that would be silly. I think to nearly the same degree that one can draw the conclusion that Rust code will have fewer CVEs than C. Generally speaking, of course. Individual projects can always be outliers.
        peoplefromibiza 4y ago
        > You will never have the data you're asking for. Why????? Just wait. Obviously you can't compare 20 years of data with "a few papers" It means you're comparing hard evidence with something that is theoretical. Imagine this: "Cancer has been one of the main causes of death for people around the World, but we have these few papers about this new drug that say that it can beat cancer, se we can say for sure that cancer will not be a main cause for death anymore, without even testing the new drug, because I've read it in these papers here, written by people who work at developing this new drug, so obviously we don't need no data!" If anything, the liks at the studies posted here prove that memory safety issues went down over the years, even without Rust. Because, obviously, when going fast to develop something, you cut many corners, then, when your software is stable enough, developers can focus on improving it. 95% of the bugs were memory safety issues doesn't really say anything. If those 95% issues were all edge cases, does it really matters? If 50% of that 95% was something like "in some cases the interface is rendered slightly incorrectly" does it really matter? I am much more worried by the 0,1% of them that end up in an arbitrary code execution vulnerability or worse. > The reality is that whatever data you want is pointless Then why even bother? If it's pointless, why are you even arguing with me? You're right by design, I'm quite sure I am not. > Anyone who knows what they're talking about should be able to very easily conclude that Rust will have fewer memory safety issues than C Doesn't mean anything. If you put people in bunkers alone you'll see a drop in homicide cases. Doesn't mean it's better. That's all I'm saying. I'm not a zealot, not a fan, don't have a political agenda and not trying to convince anybody. We don't have the data, that's all, if you have data then show it to me or you have to agree with me that we don't have any. I guess you put Linus Torvalds in the group of people who don't know what they are talking about Sorry if I trust him more than you. --- And the *reality* is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. -- Linus Torvalds
asiekierka 4y ago
The Linux kernel did not even compile on most non-GCC compilers (like LLVM) as recently as a few years ago: https://www.phoronix.com/news/Clang-Kernel-2018 https://www.phoronix.com/news/Clang-Kernel-2018 Therefore, for the Linux kernel specifically, I think the only concern is whether or not GCC remains supported in addition to LLVM - as GCC and Clang are, as far as I know, the only two compilers which actually can be used to build the kernel as we speak. There's work being done on both gcc-rs and rustc_codegen_gcc to allow using GCC as a Rust backend, meaning that all platforms currently supported by the Linux kernel should be eventually capable of being supported without porting a compiler backend.
- peoplefromibiza 4y ago
  > The Linux kernel did not even compile on most non-GCC compilers I believe that was a feature. non-GCC compiler, like Clang+LLVM, are (were?) considered to be open source but not Free Software (TM)
  - planede 4y ago
    If it was a feature, what's the benefit?
    - peoplefromibiza 4y ago
      benefit != convenience for some at least, and it was a goal in the first two decades of the Linux kernel community TL;DR: LLVM and Clang allow non-free (proprietary) extensions The Clang and LLVM developers reach different conclusions from ours because they do not share our values and goals. They object to the measures we have taken to defend freedom because they see the inconvenience of them and do not recognize (or don't care about) the need for them. I would guess they describe their work as "open source" and do not talk about freedom. They have been supported by Apple, the company which hates our freedom so much that its app store for the ithings _requires_ all apps to be nonfree. (*) The nonfree compilers that are now based on LLVM prove that I was right -- that the danger was real. If I had "opened" up GCC code for use in nonfree combinations, that would not have prevented a defeat; rather, it would have caused that defeat to occur very soon. For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance. The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers -- so that all contribution to LLVM directly helps proprietary software as much as it helps us. The cause of the setback is the existence of a non-copylefted compiler that therefore becomes the base for nonfree compilers. The identity of that compiler -- whether it be LLVM, GCC, or something else -- is a secondary detail. To make GCC available for such use would be throwing in the towel. If that enables GCC to "win", the victory would be hollow, because it would not be a victory for what really matters: users' freedom.
colonwqbang 4y ago
Writing an LLVM backend for <LESS POPULAR ARCH> isn't impossible, it just hasn't been done yet. Writing GNU Rust compiler isn't impossible, it just hasn't been done yet. What better way to encourage it than to write more high quality and useful code in the language. Seems like an unfair criticism to levy.
- sophacles 4y ago
  > Writing GNU Rust compiler isn't impossible, it just hasn't been done yet I think you mean it just isn't finished yet, but it's almost there.
pornel 4y ago
Rust is close to supporting GCC as a back-end already: > It’s awesome that we can already compile Rust for Linux with very few hacks: we’re very close to being able to compile it on the master branch. https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-16 https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-16
insanitybit 4y ago
> but what about all the other architectures that only have a C compiler and do not want/can't to depend on LLVM? They either don't compile the rust code, which is fine, or they wait for gcc support. > What about the billions poured into LLVM that made writing an optimizing Rust compiler possible in reasonable time, that is still written in C++? I'm not sure what you're asking here. > Lastly, I hope to be wrong on this, but watching at Google history being backed by them is, unfortunately, a course, Also unclear on what this statement is about.

arunc 4y ago

Compilers are just short running tools. They can hog as much memory for the short period during compilation and die away after that. But a kernel is a critical piece of long software that can have CVE. The criticality is not to have the CVE in the first place.

peoplefromibiza 4y ago
> The criticality is not to have the CVE in the first place. I guess the most critical part of a Linux Kernel is being able to compile it in the first place for the architecture you're using. Virtually every platform/architecture out there provides a C compiler. Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. There's certainly hope, it doesn't mean data will prove us right.
- hardware2win 4y ago
  >Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. We have https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
  - peoplefromibiza 4y ago
    There's literally no single data point regarding Rust. You can't compare the number of bugs in a 20 years old C software (C++ in the case of Chrome, which is another beast entirely) with wishful thinking.
    - insanitybit 4y ago
      You will never have the data you're asking for. There are a number of papers about language impact on software quality and they all suffer from numerous issues - there are tons of confounding variables; Use two different devs and you can't account for experience, use the same dev and you taint the second project, use two different projects and you can't account for the differences, etc. The reality is that whatever data you want is pointless. Anyone who knows what they're talking about should be able to very easily conclude that Rust will have fewer memory safety issues than C. Arguing about that would be silly. I think to nearly the same degree that one can draw the conclusion that Rust code will have fewer CVEs than C. Generally speaking, of course. Individual projects can always be outliers.
      - peoplefromibiza 4y ago
        > You will never have the data you're asking for. Why????? Just wait. Obviously you can't compare 20 years of data with "a few papers" It means you're comparing hard evidence with something that is theoretical. Imagine this: "Cancer has been one of the main causes of death for people around the World, but we have these few papers about this new drug that say that it can beat cancer, se we can say for sure that cancer will not be a main cause for death anymore, without even testing the new drug, because I've read it in these papers here, written by people who work at developing this new drug, so obviously we don't need no data!" If anything, the liks at the studies posted here prove that memory safety issues went down over the years, even without Rust. Because, obviously, when going fast to develop something, you cut many corners, then, when your software is stable enough, developers can focus on improving it. 95% of the bugs were memory safety issues doesn't really say anything. If those 95% issues were all edge cases, does it really matters? If 50% of that 95% was something like "in some cases the interface is rendered slightly incorrectly" does it really matter? I am much more worried by the 0,1% of them that end up in an arbitrary code execution vulnerability or worse. > The reality is that whatever data you want is pointless Then why even bother? If it's pointless, why are you even arguing with me? You're right by design, I'm quite sure I am not. > Anyone who knows what they're talking about should be able to very easily conclude that Rust will have fewer memory safety issues than C Doesn't mean anything. If you put people in bunkers alone you'll see a drop in homicide cases. Doesn't mean it's better. That's all I'm saying. I'm not a zealot, not a fan, don't have a political agenda and not trying to convince anybody. We don't have the data, that's all, if you have data then show it to me or you have to agree with me that we don't have any. I guess you put Linus Torvalds in the group of people who don't know what they are talking about Sorry if I trust him more than you. --- And the *reality* is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. -- Linus Torvalds

asiekierka 4y ago

The Linux kernel did not even compile on most non-GCC compilers (like LLVM) as recently as a few years ago: https://www.phoronix.com/news/Clang-Kernel-2018 https://www.phoronix.com/news/Clang-Kernel-2018 Therefore, for the Linux kernel specifically, I think the only concern is whether or not GCC remains supported in addition to LLVM - as GCC and Clang are, as far as I know, the only two compilers which actually can be used to build the kernel as we speak. There's work being done on both gcc-rs and rustc_codegen_gcc to allow using GCC as a Rust backend, meaning that all platforms currently supported by the Linux kernel should be eventually capable of being supported without porting a compiler backend.

peoplefromibiza 4y ago
> The Linux kernel did not even compile on most non-GCC compilers I believe that was a feature. non-GCC compiler, like Clang+LLVM, are (were?) considered to be open source but not Free Software (TM)
- planede 4y ago
  If it was a feature, what's the benefit?
  - peoplefromibiza 4y ago
    benefit != convenience for some at least, and it was a goal in the first two decades of the Linux kernel community TL;DR: LLVM and Clang allow non-free (proprietary) extensions The Clang and LLVM developers reach different conclusions from ours because they do not share our values and goals. They object to the measures we have taken to defend freedom because they see the inconvenience of them and do not recognize (or don't care about) the need for them. I would guess they describe their work as "open source" and do not talk about freedom. They have been supported by Apple, the company which hates our freedom so much that its app store for the ithings _requires_ all apps to be nonfree. (*) The nonfree compilers that are now based on LLVM prove that I was right -- that the danger was real. If I had "opened" up GCC code for use in nonfree combinations, that would not have prevented a defeat; rather, it would have caused that defeat to occur very soon. For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance. The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers -- so that all contribution to LLVM directly helps proprietary software as much as it helps us. The cause of the setback is the existence of a non-copylefted compiler that therefore becomes the base for nonfree compilers. The identity of that compiler -- whether it be LLVM, GCC, or something else -- is a secondary detail. To make GCC available for such use would be throwing in the towel. If that enables GCC to "win", the victory would be hollow, because it would not be a victory for what really matters: users' freedom.

colonwqbang 4y ago

Writing an LLVM backend for <LESS POPULAR ARCH> isn't impossible, it just hasn't been done yet. Writing GNU Rust compiler isn't impossible, it just hasn't been done yet. What better way to encourage it than to write more high quality and useful code in the language. Seems like an unfair criticism to levy.

sophacles 4y ago
> Writing GNU Rust compiler isn't impossible, it just hasn't been done yet I think you mean it just isn't finished yet, but it's almost there.

pornel 4y ago

Rust is close to supporting GCC as a back-end already: > It’s awesome that we can already compile Rust for Linux with very few hacks: we’re very close to being able to compile it on the master branch. https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-16 https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-16

insanitybit 4y ago

> but what about all the other architectures that only have a C compiler and do not want/can't to depend on LLVM? They either don't compile the rust code, which is fine, or they wait for gcc support. > What about the billions poured into LLVM that made writing an optimizing Rust compiler possible in reasonable time, that is still written in C++? I'm not sure what you're asking here. > Lastly, I hope to be wrong on this, but watching at Google history being backed by them is, unfortunately, a course, Also unclear on what this statement is about.