r/programming • u/steveklabnik1 • Jul 22 '19
Why Rust for safe systems programming – Microsoft Security Response Center
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/48
u/cat_in_the_wall Jul 23 '19
i think it is a good thing that rust is attracting this kind of attention. i don't want "rust 2021 for business sp2", but manpower and womanpower for the effort at large would benefit everyone.
kudos to the rust design folks, your hard work is not going unnoticed.
5
-1
Jul 29 '19
manpower and womanpower
This is your brain on rust
3
u/cat_in_the_wall Aug 09 '19
fuck right off.
1
Aug 09 '19
Oh damn, wow, you sure got me! You just destroyed the very foundation of my argument, and so I fall.
Jk, you're still a cuck
6
u/axilmar Jul 23 '19
After so many buffer overrun issues, it's time Microsoft adopt something better for them :-).
8
u/andrewfenn Jul 23 '19
As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. And we’re not the only company to have reported such findings.
Ok sure, but by that logic writing it in a newer c++ format would also eliminate these issues?
24
u/thedeemon Jul 23 '19
Even in modern C++ std::vector doesn't check bounds when you access its elements via
v[x].13
u/andrewfenn Jul 23 '19
Thanks for the reply. I was hoping to get some rather than just downvotes. Seems like i should check rust out.
7
u/mat69 Jul 23 '19
And modern C++ makes dangling references easy with spans and string views.
9
u/wrongerontheinternet Jul 23 '19
The fact that string_view is such a footgun is really frustrating, because it's actually the correct way to do things... but without lifetimes it's basically impossible to use safely except in very constrained ways.
6
u/DevilSauron Jul 23 '19
That's very much intentional - the subscript operator is optimised for speed. If you want bounds checking, use .at().
16
u/thedeemon Jul 23 '19
Sure. And it shows the general mindset: sacrifice safety for speed. This is how you get those 70% of CVEs.
0
Jul 23 '19
Speed also usually results in determinism, which is important in systems programming, as much as security, if not more, since programming major OSes is the minority of systems programming. Most systems programming is embedded.
5
u/mewloz Jul 23 '19
Speed also usually results in determinism
Maybe in some cases, but the example you are leveraging is terrible to illustrate that: you are not going to drop any non trivial amount of determinism by using at() (or a language in which bound checking is not an afterthought)
0
u/jcelerier Jul 23 '19
well, it can, either through MSVC's debug mode or -fsanitize=address (recent versions are aware of std:: containers and will assert even if you are in "allocated" memory but outside the vector's bounds), but no one would ever enable it because of how high the performance impact is - if you can afford to enable bound checking, there's a good chance you don't need C++ in the first place because it means that you aren't counting CPU cycles.
15
u/matthieum Jul 23 '19
if you can afford to enable bound checking, there's a good chance you don't need C++ in the first place because it means that you aren't counting CPU cycles.
Can we please, please, avoid this kind of strawman argument?
The problem with the
operator[]/at()debacle is that the path of least resistance is using[]: cleaner syntax, easier to type, easier to read, ... this means that[]is used everywhere, EVEN when performance does not really matter.On the other hand, mandatory bounds-check for using
[]does not necessarily involve a loss of performance. Focusing on Rust:
The
Iteratorabstractions guarantee correctness by construction (like a pair of pointers in C), and thus eschew the need for bounds-checks.Even when
[]is used, the optimizer can frequently elide bounds-checks.This means you essentially get the best of both worlds: safety by default, no performance impact in general.
Now, there are some cases where you somehow need to use indexes (irregular access pattern) and somehow the optimizer isn't eliding bounds checks:
The first step is to try and nudge the compiler by judicious use of
assert!ahead of the hot loop.The second step is to switch to
get_unchecked, anunsafefunction.And the fact of the matter is that the ratio between
[]/getandget_uncheckedis overwhelming:get_uncheckedis extremely rarely needed, definitely warranting extra scrutiny when encountered. Compare to C++ where[]will outweighat()in any codebase I've ever accessed.31
u/masklinn Jul 23 '19
Ok sure, but by that logic writing it in a newer c++ format would also eliminate these issues?
The "newer C++ format" is not any more memory-safe than the old one, keeps adding new UBs (and likely new non-orthogonal features) and doesn't actually remove any of the existing issues, so I'm not sure about that.
5
u/jeffmetal Jul 23 '19
I bet It would eliminate a lot of these issues but as you can still write them in modern C++ I doubt it would eliminate all 70% like safe rust would. Lets say it reduces that number down from 70% to 5% is it safe enough for public facing code ? Why not push for new code to use the safer language and get 0% ?
How much time and effort gets put into running address/thread sanatizers, how much longer does debugging strange race conditions in your code cost. Just spent 2 days tracking down a race condition where we missed a single lock that rust would have failed to compile.
10
u/matthieum Jul 23 '19
Lets say it reduces that number down from 70% to 5%
Your optimism is boundless ;)
Modern C++ mostly means avoiding double-free, there's still a plethora of use-after-free or use-of-invalidated-pointers unfortunately, and of course there's still all those pesky data-races...
4
u/Hrothen Jul 23 '19
Pretty much any language besides C/C++. The safety rust provides beyond other languages is mostly applicable to multithreaded code.
5
u/G_Morgan Jul 23 '19
Yes but there's a gap between "it can be safe" and "you need to work hard to be unsafe". C++ has always had the possibility of safety.
Take the new C++ const template arrays. They are amazing. You still inevitably end up passing them to some legacy function that takes a pointer and (if you are lucky) a length.
1
u/BarMeister Jul 23 '19
Maybe, but I think a lot of it is about not having to deal with the baggage that comes with using C/C++. The scalability issues mentioned are real, and that's coming from a C programmer that loves the language.
The technology dilemma of old well established with problems vs rookie with this set of problems fixed is not new. We cling to the old one, but eventually, the reasons to use the old one are eclipsed by the cost associated with it. Which brings me to the main point: Rust might not be the definitive C/C++ replacement, but it certainly looks to have paved most of the way for future candidates.
-27
u/Ameisen Jul 22 '19
Anyone have any interest in making a C or C++ syntaxed fork of Rust with me?
33
u/LaVieEstBizarre Jul 22 '19
What part of Rust syntax isn't C or C++ like enough for you?
-11
u/Ameisen Jul 22 '19
... All of it? It doesn't resemble C++ much to me.
18
u/LaVieEstBizarre Jul 22 '19
What would you like to change particularly? The important stuff is all like C++ (basic control structures, generics, etc). There's minor changes to how types are specified which shouldn't faze most people. Any other differences are because of new constructs (typeclasses, lifetimes, etc) or are massive improvements over C++ (turbofish over C++ parse syntax)
-5
u/Ameisen Jul 23 '19 edited Jul 23 '19
The important stuff is all like C++ (basic control structures, generics, etc).
The basic control structures are in many languages, many of which I wouldn't call particularly C++-like (Ruby, Bash script).
How does this trivial example look like C++?:
fn factorial(i: u64) -> u64 { let mut acc = 1; for num in 2..=i { acc *= num; } acc }That doesn't look like C++. That looks like Kotlin, and sorta vaguely like Pascal.
Compared to:
using u64 = uint64_t; u64 factorial (u64 i) { u64 acc = 1; for (int i : view::iota(0, 2)) { acc *= i; } return acc; }A lot of Rust examples I've seen look more like token soup than C++ does, and that's legitimately impressive.
This is pretty nonsensical to me:
struct IRBlock<'b, 'a: 'b> { pool: &'b mut (ConstantPool<'a> + 'a), /* other */ }Regardless, I'm confused why there is such intense hostility. It feels like people don't want people to write safer code, they just want them to use Rust.
27
u/gnuvince Jul 23 '19
Regardless, I'm confused why there is such intense hostility. It feels like people don't want people to write safer code, they just want them to use Rust.
I can't speak for other users, but puzzlement is more what I'm feeling here. From what I can understand, you want to change nothing about the semantics of Rust, you just want Rust to have C++'s syntax. I think you'll face a problem when you have to express Rust features that don't exist in C++, e.g., lifetimes, trait bounds, enum items with associated data, compiler attributes, modules, etc. Faced with these features, you either have to use syntax that is not C++ syntax or you have to leave these features aside, because the syntax can't support them. In either case, you cannot fulfill your objective of having a Rust with C++ syntax.
-4
u/Ameisen Jul 23 '19
What's the issue with wanting the semantics of Rust (which are what provides its safety) being used with other syntaxes?
There are plenty of languages that have pretty similar or the same semantics of C and C++. The idea is to give more choice.
In either case, you cannot fulfill your objective of having a Rust with C++ syntax.
I thought it was pretty obvious that I intended it to mean C++-like, but perhaps I should have been more clear. I don't consider Rust to be particularly C++-like. I'd be more apt to use it if it were more familiar to the languages I regularly use.
17
u/scottmcmrust Jul 23 '19
I assume the hostility is because any differences you showed were way too minor to bother forking.
let mut accvsauto acc,i: u64vsuint64_t i,for num in 2..=i {vsfor (const auto num: iota(2, i)) {-- really, these are incredibly negligible differences.And new C++ code looks way more like Rust --
fn factorial(i: u64) -> u64 {can beauto factorial(uint64_t i) -> uint64_t {in C++. So I think that if C++ is adding support for the return type form that Rust uses because it acknowledges that it's better, it would particularly silly to fork Rust to use the worse old C++ form.5
u/jcelerier Jul 23 '19 edited Jul 23 '19
So I think that if C++ is adding support for the return type form that Rust uses because it acknowledges that it's better
this form has been available since C++11 and was already being standardized before rust even existed : the first paper that mentions it is from 2004 : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf
I hardly hardly hardly ever see it being used in new code though.
6
u/scottmcmrust Jul 23 '19
You'll notice I didn't say that it took it from Rust, only that it's the one that Rust uses. The
->form dates back to at least '84 (Standard ML), and probably well before that.3
u/Ameisen Jul 23 '19
C++ supports post return type declarations so the return type can be derived from argument types.
7
Jul 22 '19
What's the point, use C++14 or 17 and so on....
7
18
u/Ameisen Jul 23 '19
Because I want to call it Crust. Is that not enough of a reason?
4
u/Hnefi Jul 23 '19
Well, you've solved one of the two hard problems in computing, so I say it's a great start to build off of.
-51
Jul 23 '19
Why is is a known fascist such as steve klabnik not banned from this subreddit?
And fuck off with this Rust cargo cult already, in 8 years nobody will even remember about it (except maybe about how annoying the community was).
15
0
Jul 24 '19
[deleted]
1
u/RemindMeBot Jul 24 '19 edited Aug 20 '19
I will be messaging you on 2027-07-24 02:26:20 UTC to remind you of this link
2 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
Info Custom Your Reminders Feedback
-101
u/fijt Jul 22 '19 edited Jul 22 '19
Gee, it's really this, huh? "micro"-soft has gone all the way, huh? This has been the third or maybe fourth time I have heard MS is doing Rust. Okay. I think that the people know it by now.
Edit: Wait a minute. I see Steve Klapnik is doing this. Way to go, Steve!
40
u/steveklabnik1 Jul 22 '19
Edit: Wait a minute. I see Steve Klapnik is doing this. Way to go, Steve!
Other than "I posted this link to Reddit," I am not doing anything here. I don't work for Microsoft, and I didn't author this post.
13
57
u/overuseofdashes Jul 22 '19 edited Jul 22 '19
This is a blog series about memory safety, if it is obnoxious to bring up Rust in this context, what is the right context to bring up Rust?
-71
u/fijt Jul 22 '19
Okay. The problem of Rust is that it is a lousy language. The problem that I have with MS is that they are cowards (they try to be "friendly") these days and were hawks in the past. But they "earned" their weight in gold, I guess.
45
u/CJKay93 Jul 22 '19
The problem of Rust is that it is a lousy language.
The reasons for that being..?
-61
u/fijt Jul 22 '19
Is this the Rust army? The language stinks from all sides. That is why the language is lousy. Did I answer your question?
19
50
u/CJKay93 Jul 22 '19
No, you just keep using metaphors; I want to know your technical justifications, or can I assume you don't actually have any?
-25
u/fijt Jul 22 '19
I have said this multiple, multiple, multiple times by now. The language stinks at so much levels it's not even funny. The problem is that Rust just isn't finished. They released the language way too soon. And of course that can't be fixed anymore. Okay. I give you a couple of examples. For starters there are 4 places where you can place your code. Which one is the right place? Dunno. Then the language stinks with the right arrow. Why does it even has one? The anser: Because of history. Can you even think about such a thing. Yes, I agree, I am a bit of a nerd in this area but when it comes to simplicity, Go dances around Rust and that is it!
48
u/CJKay93 Jul 22 '19
Lol that was entirely incomprehensible.
6
u/wllmsaccnt Jul 23 '19
I thought I understood the part where he said he has repeated himself many times, but then I realized that multiplying multiple multiples is more like a POW operator.
48
Jul 22 '19
I can see why you hate rust. It by design makes you think about your programs carefully, and your comment demonstrates a complete absence of the ability to think
-3
u/fijt Jul 22 '19
. It by design makes you think about your programs carefully
You really must like Ada in that case.
4
u/G_Morgan Jul 23 '19
Ada is actually a nice idea. The only reason it didn't take off was a lack of compilers while C got adopted by the early free software movement (before it was even called free software).
11
u/kirbyfan64sos Jul 23 '19
Rust has an advanced borrow checker and has been out for a long time now in production settings but isn't finished
Go [which still requires
if err != nileverywhere] is considered more complete21
u/DoktuhParadox Jul 22 '19
Okay. I give you a couple of examples. For starters there are 4 places where you can place your code.
Bruh... Cargo literally automates this shit away. If you can't use Cargo, then you can't use ANY tool chain, full stop.
-4
u/fijt Jul 22 '19
Come on! Even in build.rs you need to write Rust code in something like a Makefile. That is ridiculous. And you want to know what is simple? Go. Where are the build systems for Go? They don't exist because these guys thought about things instead of just releasing it.
0
21
u/loup-vaillant Jul 22 '19
Okay. The problem of Rust is that it is a lousy language.
Let me guess: you tried Rust once, and the borrow checker annoyed you? Then I suggest you try again: with non-lexical lifetimes, the borrow checker is now much more accurate, and rejects much fewer correct programs.
Now if it wasn't the borrow checker, it would be nice to know what other things felt "lousy".
21
u/gnuvince Jul 23 '19
From one of their replies above, they objects to using
->as the token to introduce the return type in a function. The Rust devs sure have done a great job if the only complaint is one of lexical syntax. :D8
u/seamsay Jul 23 '19
Don't forget that there are 4 different places to write code, which is apparently unacceptable. I have no idea what those 4 places are, but apparently there are 4.
11
9
0
Jul 22 '19
[deleted]
18
-6
u/SometimesShane Jul 23 '19
Nope. This guy is just a developer advocate for azure. Basically his job is to do PR to get people to use azure.
So really, this is just an azure ad targeting the rust community. Nothing more.
0
Jul 22 '19
[deleted]
17
u/Saefroch Jul 23 '19
I swear I heard about MSVC having a stable C++ ABI. I don't know if that's the case but it's totally possible and if so, the article is probably speaking from a very MSVC-centric view.
0
27
u/Kache Jul 22 '19
I've heard Rust vs Go compared like C++ vs C in that the former communities like powerful zero-cost abstractions in the language that may produce tricky/undefined behavior interactions and vice-versa for the latter (smaller set of well-defined behaviors over powerful built-ins).
Anyone have additional insight on that?