5 ms·

Rewriting stable, network-facing, C or C++ software in Rust is a very good idea, because that way that software will require less ongoing maintenance to avoid s

Rewriting stable, network-facing, C or C++ software in Rust is a very good idea, because that way that software will require less ongoing maintenance to avoid security problems in the future.

Const-me 7y ago
We don’t know yet how much Rust software will cost in ongoing maintenance to avoid security problems. Unsafe keyword disables many safety features. It already caused security issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-... That particular one was fixed long ago, but unsafe is used a lot in libraries, both in standard and third-party crates. The reasons include native interop e.g. OS kernel calls, language limitations e.g. in collections and other data structures, also sometimes they’re performance optimizations.
- pcwalton 7y ago
  Yes, we do. Empirically, there have been far fewer memory safety problems in the Rust components of, for example, Firefox than there have been in the C++ components. That particular memory safety issue was not a security issue, because it did not cause any problems in actual software. Rust is very conservative about issuing CVEs for any issue which could conceivably be a security problem. (The equivalent would be if C++ the language issued a CVE because the language lets you clear an array while you're iterating over it. The CVEs for exploitable problems that this kind of thing enables are for the vulnerable software, letting C++ off the hook.) In my opinion, Rust is too conservative and shouldn't even call those things security issues until they affect real products, because it leads to misunderstandings like this.
  - Const-me 7y ago
    It’s safer than C++, sure, but half of other languages are safer. Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Same with JS & TS. When people move from C++ to another language for more safety, Rust is not their only option. Couple decades ago everything was written in C or C++. Desktop apps, mobile apps, web servers (cgi-bin, then COM objects for asp.classic). People wanted higher level, easier to use, faster to compile, and safer languages. Java was the first popular one, then C#, then the rest of them followed. C++ is continuing to lose the market it once had. 15 years ago, people generally stopped using C++ for web servers. Some still do for unusual requirements, but most people don’t. 10 years ago, most people stopped programmed mobile apps in C++ (I did before that time, for WinCE and PalmOS), now it’s mostly managed languages there. Recently the same happened for desktop apps, no one likes Electron but it does the job, and people do use the software. Embedded and videogames have already started the transition, IMO. Moving from C++ to better languages is a long trend, the industry is doing it for decades now. I don’t think Rust is a universally good option for that. Has issues with usability, labor market, libraries, platform support, and community. Good one for niche stuff, like some components of a web browser, or a bare metal hypervisor, but that’s it.
    - pcwalton 7y ago
      I agree that there are many other fine languages that people should be considering.
    - 0815test 7y ago
      > When people move from C++ to another language for more safety, Rust is not their only option. That's arguably missing the point. For a very long time, managed, GC-based languages like Java or Go were the only option for workable memory safety! (Yes, I'm ignoring a lot of stuff because it's practically irrelevant. No need to tell me about ATS and the like, thank you so much.) Cyclone and now Rust have changed that, which makes for a real paradigm shift in the industry, at least potentially. Rust even contributes meaningfully to thread safety by getting rid of simple data races, which are a huge can of worms not just in C/C++ but managed languages as well!
      - Const-me 7y ago
        > which are a huge can of worms not just in C/C++ but managed languages as well Multithreading with mutable shared state is harder in general. That's language agnostic. But it's easier to do correctly the way managed languages do. They don't usually create threads, they use thread pool and post messages to each other. This is language-agnostic too, I've tried doing same in C++ and it works, e.g. https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/DxVisuals/Hlsl/Async/CompileWorker.h https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/Dx... but with a GC and async-await it's much easier. > which makes for a real paradigm shift in the industry, at least potentially I think for most people, getting stuff done is more important than shifting paradigms. Rust is less productive than managed languages (GC helps, BC interferes), compiles slow, slightly less safe. For network people, golang is quite popular already, .NET core wants there, too. Game developers use too much C++ libraries, don't need security (console games are sandboxed or run under HW hypervisor), their most painful C++ issue is build time, and Rust is even worse. Low-level embedded, driver, linux OS kernel developers need C, too much integration and too many weird target platforms. HPC and ML people need manual SIMD and corresponding libraries. CUDA people need nVidia support. Open a job board, type C++ and press search. Do you see many positions except listed above, where people are still writing C++?
blub 7y ago
It's a very good idea because you don't have to hire or retrain the people to perform the work and maintain it. Instead you can just talk about how it'a a good idea.
- pjmlp 7y ago
  Microsoft security unit also thinks that way. https://www.youtube.com/watch?v=PjbGojjnBZQ https://www.youtube.com/watch?v=PjbGojjnBZQ https://github.com/microsoft/MSRC-Security-Research/tree/master/presentations/2019_02_BlueHatIL https://github.com/microsoft/MSRC-Security-Research/tree/mas... "Future development should be a mix of C#, Rust and constrained C++." Which is also a reason why they aren't that bothered into keeping plain old C around on VC++, beyond ISO C++ requirements.
  - blub 7y ago
    Microsoft say a lot of things. I'll consider listening when they will (re)write their stuff in Rust. TBH what MS does development-wise is irrelevant for me, since I gave up on their platforms a long time ago. But if they put their money where their mouth is, it might give Rust the push it needs. Wouldn't count on it though, MS can't even figure out what own development story to support for more than a couple of years.
    - pjmlp 7y ago
      Then start listening. Azυre IoT Edge is written in C# and Rust, Visual Studio Code uses Rust for its search, the Web framework Actix is written by Microsoft employees and used internally at Azure, they are helping port Firefox to HoloLens and that included hiring Rust devs.
      - blub 7y ago
        First of all, thanks for letting me know which Rust projects MS are directly or indirectly involved in. It's more than I expected, but only because my expectations were very low. Do you consider that list in any way impressive or representative for the MS organization? I mean writing the search function of their hobby project text editor in language X is not exactly a ringing endorsement. Neither is anything which has IoT in its name.

Rewriting stable, network-facing, C or C++ software in Rust is a very good idea, because that way that software will require less ongoing maintenance to avoid security problems in the future.

Const-me 7y ago

We don’t know yet how much Rust software will cost in ongoing maintenance to avoid security problems. Unsafe keyword disables many safety features. It already caused security issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-... That particular one was fixed long ago, but unsafe is used a lot in libraries, both in standard and third-party crates. The reasons include native interop e.g. OS kernel calls, language limitations e.g. in collections and other data structures, also sometimes they’re performance optimizations.

pcwalton 7y ago
Yes, we do. Empirically, there have been far fewer memory safety problems in the Rust components of, for example, Firefox than there have been in the C++ components. That particular memory safety issue was not a security issue, because it did not cause any problems in actual software. Rust is very conservative about issuing CVEs for any issue which could conceivably be a security problem. (The equivalent would be if C++ the language issued a CVE because the language lets you clear an array while you're iterating over it. The CVEs for exploitable problems that this kind of thing enables are for the vulnerable software, letting C++ off the hook.) In my opinion, Rust is too conservative and shouldn't even call those things security issues until they affect real products, because it leads to misunderstandings like this.
- Const-me 7y ago
  It’s safer than C++, sure, but half of other languages are safer. Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Same with JS & TS. When people move from C++ to another language for more safety, Rust is not their only option. Couple decades ago everything was written in C or C++. Desktop apps, mobile apps, web servers (cgi-bin, then COM objects for asp.classic). People wanted higher level, easier to use, faster to compile, and safer languages. Java was the first popular one, then C#, then the rest of them followed. C++ is continuing to lose the market it once had. 15 years ago, people generally stopped using C++ for web servers. Some still do for unusual requirements, but most people don’t. 10 years ago, most people stopped programmed mobile apps in C++ (I did before that time, for WinCE and PalmOS), now it’s mostly managed languages there. Recently the same happened for desktop apps, no one likes Electron but it does the job, and people do use the software. Embedded and videogames have already started the transition, IMO. Moving from C++ to better languages is a long trend, the industry is doing it for decades now. I don’t think Rust is a universally good option for that. Has issues with usability, labor market, libraries, platform support, and community. Good one for niche stuff, like some components of a web browser, or a bare metal hypervisor, but that’s it.
  - pcwalton 7y ago
    I agree that there are many other fine languages that people should be considering.
  - 0815test 7y ago
    > When people move from C++ to another language for more safety, Rust is not their only option. That's arguably missing the point. For a very long time, managed, GC-based languages like Java or Go were the only option for workable memory safety! (Yes, I'm ignoring a lot of stuff because it's practically irrelevant. No need to tell me about ATS and the like, thank you so much.) Cyclone and now Rust have changed that, which makes for a real paradigm shift in the industry, at least potentially. Rust even contributes meaningfully to thread safety by getting rid of simple data races, which are a huge can of worms not just in C/C++ but managed languages as well!
    - Const-me 7y ago
      > which are a huge can of worms not just in C/C++ but managed languages as well Multithreading with mutable shared state is harder in general. That's language agnostic. But it's easier to do correctly the way managed languages do. They don't usually create threads, they use thread pool and post messages to each other. This is language-agnostic too, I've tried doing same in C++ and it works, e.g. https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/DxVisuals/Hlsl/Async/CompileWorker.h https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/Dx... but with a GC and async-await it's much easier. > which makes for a real paradigm shift in the industry, at least potentially I think for most people, getting stuff done is more important than shifting paradigms. Rust is less productive than managed languages (GC helps, BC interferes), compiles slow, slightly less safe. For network people, golang is quite popular already, .NET core wants there, too. Game developers use too much C++ libraries, don't need security (console games are sandboxed or run under HW hypervisor), their most painful C++ issue is build time, and Rust is even worse. Low-level embedded, driver, linux OS kernel developers need C, too much integration and too many weird target platforms. HPC and ML people need manual SIMD and corresponding libraries. CUDA people need nVidia support. Open a job board, type C++ and press search. Do you see many positions except listed above, where people are still writing C++?

blub 7y ago

It's a very good idea because you don't have to hire or retrain the people to perform the work and maintain it. Instead you can just talk about how it'a a good idea.

pjmlp 7y ago
Microsoft security unit also thinks that way. https://www.youtube.com/watch?v=PjbGojjnBZQ https://www.youtube.com/watch?v=PjbGojjnBZQ https://github.com/microsoft/MSRC-Security-Research/tree/master/presentations/2019_02_BlueHatIL https://github.com/microsoft/MSRC-Security-Research/tree/mas... "Future development should be a mix of C#, Rust and constrained C++." Which is also a reason why they aren't that bothered into keeping plain old C around on VC++, beyond ISO C++ requirements.
- blub 7y ago
  Microsoft say a lot of things. I'll consider listening when they will (re)write their stuff in Rust. TBH what MS does development-wise is irrelevant for me, since I gave up on their platforms a long time ago. But if they put their money where their mouth is, it might give Rust the push it needs. Wouldn't count on it though, MS can't even figure out what own development story to support for more than a couple of years.
  - pjmlp 7y ago
    Then start listening. Azυre IoT Edge is written in C# and Rust, Visual Studio Code uses Rust for its search, the Web framework Actix is written by Microsoft employees and used internally at Azure, they are helping port Firefox to HoloLens and that included hiring Rust devs.
    - blub 7y ago
      First of all, thanks for letting me know which Rust projects MS are directly or indirectly involved in. It's more than I expected, but only because my expectations were very low. Do you consider that list in any way impressive or representative for the MS organization? I mean writing the search function of their hobby project text editor in language X is not exactly a ringing endorsement. Neither is anything which has IoT in its name.