Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Microsoft Programming

Microsoft To Explore Using Rust (zdnet.com) 146

Microsoft plans to explore using the Rust programming language as an alternative to C, C++, and others, as a way to improve the security posture of its and everyone else's apps. From a report: The announcement was made yesterday by Gavin Thomas, Principal Security Engineering Manager for the Microsoft Security Response Center (MSRC). "You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities," Thomas said. "We are a response organization, but we also have a proactive role, and in a new blog series we will highlight Microsoft's exploration of safer system programming languages, starting with Rust." The end game is to find a way to move developers from the aging C and C++ programming language to so-called "memory-safe languages." Memory-safe languages, such as Rust, are designed from the ground up with protections against memory corruption vulnerabilities, such as buffer overflows, race conditions, memory leaks, use-after free and memory pointer-related bugs.
This discussion has been archived. No new comments can be posted.

Microsoft To Explore Using Rust

Comments Filter:
  • by SuperKendall ( 25149 ) on Wednesday July 17, 2019 @12:07PM (#58940358)

    if Microsoft is looking into Rust, I better just wait to learn it so I can focus on the largely bloated R# later on.

  • Not exactly (Score:5, Funny)

    by phantomfive ( 622387 ) on Wednesday July 17, 2019 @12:09PM (#58940368) Journal

    "You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities,"

    No, I was thinking, "Microsoft has a security team? Why haven't you done your job??"

    • by lkcl ( 517947 )

      "You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities,"

      No, I was thinking, "Microsoft has a security team? Why haven't you done your job??"

      because they go to their boss and they say, "i have a great idea on how to improve the security of windows!" and their boss asks, "will it make us money or will it lose us money?" and they reply, "it will lose money but..." and they are interrupted, and told, "well go away and come back with an idea that makes us money".

      after six months, they quit. this is not a joke response. this is actually how it is and has been. this idea *might* be the first - ever - since the security team was set up OVER TWENTY Y

  • I wonder why Microsoft haven't yet created their own safe C-like language. Google has Go. Mozilla has Rust. Of course they've created C#/F# but they are for .Net applications.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Rust is "safe" from Microsoft's perspective as it is not controlled by another corporation that also sells operating systems. Swift in the case of Apple and as you pointed out Google having Go. Both of course sell their own operating systems. Mozilla does not, if anything Microsoft can certainly throw some cash their direction and have things go their way a bit more.

      I'm glad that Microsoft didn't go to try to invent some new language that will take people some time to become proficient in.

    • by WaffleMonster ( 969671 ) on Wednesday July 17, 2019 @12:58PM (#58940666)

      I wonder why Microsoft haven't yet created their own safe C-like language. Google has Go. Mozilla has Rust. Of course they've created C#/F# but they are for .Net applications.

      They have checked C.
      https://www.microsoft.com/en-u... [microsoft.com]

    • by boa ( 96754 )

      I wonder why Microsoft haven't yet created their own safe C-like language. Google has Go. Mozilla has Rust. Of course they've created C#/F# but they are for .Net applications.

      Microsoft kinda tried to make C "safer" by adding all the crappy *_s() functions to the C standard, like sprintf_s().

  • by Anonymous Coward

    As I am Googling rust+security+code and find:
        How Rust’s standard library was vulnerable for years and nobody noticed
        https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6

  • by dlleigh ( 313922 ) on Wednesday July 17, 2019 @12:32PM (#58940524)

    Oh, give me C, lots of pointers and assembly inner loops
    Don't fence me in
    Let me write algorithms without bureaucratic hoops
    Don't fence me in
    Let me code by myself in the midnight gloom
    And listen to the humming of the machine room
    Memory-safe languages will be my doom
    Don't fence me in

  • Hoping that MS could take the ideas behind Rust and create a better language. However those ideas aren't innovative and I can't say I like MS language designs much...

  • by thereddaikon ( 5795246 ) on Wednesday July 17, 2019 @01:11PM (#58940740)

    The post has 35+ comments but only two are visible when browsing +2.

    My take on Rust, it prevents you from making a lot of common mistakes you see in C/C++ which is a good thing. The politics surrounding it are stupid, but so much is anymore. Just shut up and code.

    • My take on Rust, it prevents you from making a lot of common mistakes you see in C/C++ which is a good thing.

      Bricks are 100% free of ALL coding mistakes yet not very useful for programming. (Redstone excluded)

      Most languages can be tweaked with constraints necessary to make x type of mistake go away including C. Rust itself has facilities for doing "unsafe" memory things by disabling constraints.

      In terms of language evaluation the tradeoffs including remaining capabilities have to be evaluated not just the headline x is prevented from happening.

      My own personal belief is general purpose language selection is effec

      • My own personal belief is general purpose language selection is effectively semantic rearrangement of deck chairs. Meaningful progress in productivity and safety will only come from pushing adoption of higher level domain specific solutions.

        I agree, on a certain level it is just arguing over semantics. That is assuming other aspects being equal such as the compiler and rest of the toolchain.

      • by roca ( 43122 ) on Wednesday July 17, 2019 @05:09PM (#58942040) Homepage

        The original post has numbers showing that memory safety issues are holding steady at 70% of all security vulnerabilities in C and C++ software over the last decade. Rust eliminates these in safe code. Experience in large Rust applications (the Rust parts of Firefox, my own 140K line project) shows that you very rarely need to use 'unsafe' in Rust. When you do, the usage can almost always be encapsulated in small libraries that you can audit carefully and reuse across projects. That experience also shows that Rust can be used productively in very performance-demanding environments.

        Thus there is good reason to believe that Rust would eliminate ~70% of security vulnerabilities in situations where C and C++ are currently used. That is not just "rearranging deck chairs".

        • The same argument can also be made for C++. You can easily encapsulate unsafe operations.

          The reason why there are a lot of vulnerabilities in C++ is because there is much more code in it, a lot of it much older, and written by people with poor programming skill.
          There is no end to the stupidity of what some people can write and the problems they can cause. If anything memory "safe" languages are a problem because they give a false sense of security. All they do is turn one type of bug into another type of bu

    • My take on Rust, it prevents you from making a lot of common mistakes you see in C/C++ which is a good thing.

      At the expense of...?

      Sorry, but I make it a habit to never believe anyone who tells me any change from a widely used programming language in active use is all benefits and no drawbacks.

      • At the expense of being rather complicated. C has one pointer type. Java has two. Rust has four (I don't know how many C++ has, but it's enough that they are hard to keep track of, even not counting custom implementations. Rust is probably better than C++ if the libraries you need are available).
  • by Anonymous Coward

    Why not spend the effort on improving the tooling (static and runtime analysis tools, integration into IDEs, compiler warnings/errors, &c.) for existing languages that people actually use? These tools have already come a LONG way in the relatively few years since Rust was first dreamt up. The Rust borrow checker is not the only solution to the problem of memory safety, it's a rather extreme solution with some serious practical drawbacks, and it has no benefit to existing code in other languages. Effort

    • by Waffle Iron ( 339739 ) on Wednesday July 17, 2019 @01:46PM (#58940970)

      By the time you improve expensive, sucky tools like Coverity to be as air-tight as the Rust borrow checker, it would be implementing rules on your code that are just about as strict and annoying as the Rust borrow checker.

      The only way around that would be to develop AI that thoroughly understands your algorithms and systems interactions at a high level so that it can evaluate whether any unsafe conditions could ever actually happen even with "relaxed" rules. At that point, the AI might as well write all your code on its own and you'd be out of a job anyway.

    • Why not spend the effort on improving the tooling (static and runtime analysis tools, integration into IDEs, compiler warnings/errors, &c.) for existing languages that people actually use?

      Because, the tools still need to be able reason about the language. That's hard with C. Working out whether a pointer is valid or invalid in C with static analysis is impossible in general, hard in specifics. In Rust, you can tell for large parts of your code base, and the other bits are flagged as unsafe. Of course, Rust has just taken most of these techniques from "other languages that nobody uses".

      The borrow checker does have some drawbacks. The rust team is working hard to decrease them. Are the drawbac

  • by UnknownSoldier ( 67820 ) on Wednesday July 17, 2019 @01:32PM (#58940876)

    If Microsoft is serious about security AND high performance then I'll believe Microsoft when you can ship games on the Xbox written in Rust because there are reasons almost everyone uses C++ for console development.

    • There is one small team in one part of Microsoft that cares about Rust. That's it
  • by Anonymous Coward

    All vendors should consider if their choice of programming language (often made decades ago) is still the right one for today.

    We should applaud Microsoft for being willing to accept that programmers sometimes need a bit of help writing better/safer code, and are willing to look outside their glass buildings for good ideas.

  • by AHuxley ( 892839 )
    the CoC looking over all the code in use.
    All comments must be doubleplusgood.

You are always doing something marginal when the boss drops by your desk.

Working...