Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Sunday April 30, @05:43PM   Printer-friendly

A complete reimplementation of decades-old code is out the of the question:

Historically, the vast majority of security issues encountered on the Windows platform have been memory-related bugs. Rust can provide a highly effective solution to this long-standing problem, and Windows programmers are well aware of its potential.

Although Rust is still a relatively recent programming language, Microsoft has already embraced the technology as one of the most promising upgrades for Windows core programming. Redmond's software engineers have been diligently rewriting crucial parts of the operating system in Rust, bringing significant improvements in both performance and security to the underlying code.

Rust is a fast, memory-efficient programming language created by Graydon Hoare while working at Mozilla, the first company to officially sponsor and adopt it for their experimental browser engine, Servo. As a typical compiled language, Rust offers native performance for various types of applications, including computer software, low-resource devices, and embedded appliances.

Aside from its performance, one of Rust's main attractions is the fact that the language was designed to provide memory safety from the outset, thereby eliminating many categories of bugs and potential vulnerabilities at compile time. Notably, memory safety bugs account for 70% of the CVE-listed security vulnerabilities fixed in Windows since 2006.

According to David "Dwizzle" Weston, VP of OS Security and Enterprise at Microsoft, some Rust code has been implemented in the Windows kernel already. Speaking at BlueHat IL 2023 in Tel Aviv, Israel, last month, Weston mentioned that Windows 11 could boot in Rust, even though the code's port is currently disabled and concealed behind a feature flag.

Microsoft began rewriting portions of Windows in Rust in 2020, starting with the DirectWrite API (a part of the DirectX framework) which is responsible for managing high-quality text rendering, resolution-independent outline fonts, full Unicode text and layout support, and more. DWriteCore, the Windows App SDK implementation of the DirectWrite API, now comprises approximately 152,000 lines of Rust code and about 96,000 lines of C++ code. In addition to enhancing security, this new code blend has reportedly brought significant performance improvements (5-15%) to font operations.

Windows 10 and 11 are written in C, C++, C#, and Assembly language, with millions of lines of code that will likely never undergo a complete, Rust-based overhaul. However, Windows' main graphics device interface (Win32 GDI) is being ported to Rust, with 36,000 lines of code already converted. "There's actually a SysCall in the Windows kernel now that is implemented in Rust," Weston revealed.

Microsoft is not the only major tech company interested in adopting Rust for its primary software products. The memory-safe programming language is already being used by Amazon, Facebook, Google, and others. Rust has also become part of the Linux kernel. Open-source developers emphasize that Microsoft's commitment to Rust would be excellent news for the language's future.


Original Submission

This discussion was created by janrinok (52) for logged-in users only. Log in and try again!
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 5, Touché) by bloodnok on Sunday April 30, @06:09PM

    by bloodnok (2578) on Sunday April 30, @06:09PM (#1304077)

    Just when after 40 years of writing C I feel like I am beginning to get the hang of it.

    __
    The Major

  • (Score: 4, Insightful) by Thexalon on Sunday April 30, @07:27PM (14 children)

    by Thexalon (636) Subscriber Badge on Sunday April 30, @07:27PM (#1304080)

    Every computer language and language feature that has ever existed was created to solve a particular problem. And every single one of them is imperfect: Some are too strict, some are too loose. Some have a great model but a lousy implementation, some have a lousy model but a pretty good implementation. Some are great for run-time efficiency, others are great for programming-time efficiency.

    C's main fault is that developing on it can be more frustrating than most because you need to deal with core dumps and seg faults and such, but on the flip side pretty much all programmers have some passing familiarity with it, and it can be exactly what you need for low-level barely-above-the-metal stuff.

    I'm sure Rust's flaws, whatever they are, will be exposed over time too. New languages and new features always take a while before their problems are really obvious - C++ templates were around for a long time before their abuse became a serious problem, for example.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 5, Interesting) by istartedi on Sunday April 30, @09:22PM (13 children)

      by istartedi (123) on Sunday April 30, @09:22PM (#1304088) Journal

      Core dump? You should be so lucky. At least most of those can be tracked to the last change, and are usually sane when you drop in to a debugger.

      The real nightmare is unexpected behavior due to a use-after-free or something that doesn't core dump. You see some function behaving strangely, you drop in to a debugger and an object has values other than what it should. You didn't set anything in it. The caller didn't set anything in it. Something, anything, anywhere in the program did something that set it.

      I hate those so much, and the only thing that makes them worse is when they're "heisenbugs" that don't show up very often. It happens once. Hey, that's not right. Run program again. OK, back to expected output. Every run. Debug? Release? Expected output. You'd swear you went insane but it's right there, logged in your terminal history. One unexpected output. One.

      What you wouldn't give for a core dump.

      If Rust can really stop that kind of insanity (and they're making quite a good show of it), it's time to ball up C and throw it in the wastebasket. C++ should have been there a long time ago. What an absolute kitchen sink full of rotten worms it is.

      --
      Appended to the end of comments you post. Max: 120 chars.
      • (Score: 4, Interesting) by Snotnose on Sunday April 30, @09:32PM (8 children)

        by Snotnose (1623) on Sunday April 30, @09:32PM (#1304089)

        The real nightmare is unexpected behavior due to a use-after-free or something that doesn't core dump. You see some function behaving strangely, you drop in to a debugger and an object has values other than what it should. You didn't set anything in it. The caller didn't set anything in it. Something, anything, anywhere in the program did something that set it.

        Every debugger I used the last 10 or so years before I retired let me set a breakpoint on writing to a specific memory location.

        Then again, I never wrote anything for Windows and have never used a Microsoft debugger. Well, except for the Z-80 one for my TRS-80. But that was when Microsoft still wrote good code.

        --
        I just passed a drug test. My dealer has some explaining to do.
        • (Score: 3, Interesting) by istartedi on Sunday April 30, @09:57PM (6 children)

          by istartedi (123) on Sunday April 30, @09:57PM (#1304094) Journal

          Hmmm, you mean like you're specifying the "raw" memory location of the object in question? ie, "break on write to 0x3344899A?"? I don't recall having ever seen that as an option but having to deal with it professionally is definitely more than 10 years ago. I think such an option could work, as long as the addition of the breakpoint doesn't alter the memory layout (thus changing the address that's written), and as long as the bug occurs in the debug version. That, BTW, is why I was always told to build and test the Release version as well. I never found a way to reliably address these problems (no pun intended) without being diligent as to knowing which changes introduced them.

          And yes, this was Microsoft's debugger and definitely more than 10 years ago.

          --
          Appended to the end of comments you post. Max: 120 chars.
          • (Score: 2) by Snotnose on Monday May 01, @12:07AM (4 children)

            by Snotnose (1623) on Monday May 01, @12:07AM (#1304110)

            Hmmm, you mean like you're specifying the "raw" memory location of the object in question? ie, "break on write to 0x3344899A?"? I don't recall having ever seen that as an option but having to deal with it professionally is definitely more than 10 years ago. I think such an option could work, as long as the addition of the breakpoint doesn't alter the memory layout (thus changing the address that's written),

            They put a software interrupt at that address, the SWI keeps track of what it's replacing. The real fun is when the bug doesn't always write to the same address.

            and as long as the bug occurs in the debug version.

            Aye, there's the rub. It's also why I hate Javascript with a passion. We'd debug our scripts, take them to the factory floor, and they'd fail because reasons. I know JS is a lot different today than it was 20 years ago, but some things just stay with you.

            --
            I just passed a drug test. My dealer has some explaining to do.
            • (Score: 2) by Snotnose on Monday May 01, @02:48AM (1 child)

              by Snotnose (1623) on Monday May 01, @02:48AM (#1304128)

              They put a software interrupt at that address

              And that, my friends, is what they call a brain fart of the first degree.

              I stand by the JS comment though...

              --
              I just passed a drug test. My dealer has some explaining to do.
              • (Score: 2) by istartedi on Monday May 01, @03:12AM

                by istartedi (123) on Monday May 01, @03:12AM (#1304132) Journal

                I assumed what you meant was that they installed some kind of interrupt handler that monitored the address. I didn't give it a 2nd thought. By no means am I an expert on debuggers, but don't they basically execute each machine instruction inside some kind of VM that allows them to trap all exceptions, and create their own exceptions for things like "somebody wrote to a particular address"? In that case if you installed a handler for it, it wouldn't be a traditional interrupt handler. Software interrupt handler seems like a pretty good description of that.

                --
                Appended to the end of comments you post. Max: 120 chars.
            • (Score: 2) by istartedi on Monday May 01, @02:55AM

              by istartedi (123) on Monday May 01, @02:55AM (#1304129) Journal

              Oh, the early days of JavaScript. Remember Netscape Communicator?

              I was working at an ISP back then, and had worked my way out of support in to my first real development job. We worked with the installer customization kits for Netscape and Internet Explorer.

              Out on the floor, I had hated IE 4 with a passion for the way it integrated in to the OS. Support is bad enough when you mess up a user's app. We had several techs preside over the crunch of the entire OS due to that tight integration.

              Anyway, Netscape Communicator was where the tables turned and I started hating Netscape more, and ultimately ignoring it. The installer customization kit played a key role in that turning.

              The Netscape kit was slow. Very slow. I was tasked with analyzing it to see if we could do anything to speed it along.

              The way the Netscape kit "worked" was sort of like you'd be running through the same installation process the user did, except you could add your custom icons, messages, etc. while doing that. Somebody must have thought that was a clever idea, but when I dug in what I saw was all these redundant checks that were basically, "if (installing) do this else if (customizing) do that", and that was IIRC, just the biggest "code smell" in there. Bear in mind hardware was slower then, JavaScript hadn't been optimized, etc. I don't know what else might have been slowing it down. Mercifully I was moved on to something else.

              This reminds me of how, years later, I saw a co-worker going over some slow front end JavaScript with a jr. dev. By then, it seemed like JavaScript couldn't be blamed and it wasn't at fault. The jr. simply hadn't realized the importance of factoring things out of loops, or something else that JavaScript still couldn't optimize safely. He may have also chosen a poor algorithm too. By the end of the day, the senior showed him the light and it ran acceptably.

              Sometimes I wonder if that Communicator customization kit could have been fixed up just as easily by an experienced web dev (which I wasn't); but not enough to track it down. There be dragons!

              --
              Appended to the end of comments you post. Max: 120 chars.
            • (Score: 2, Informative) by shrewdsheep on Monday May 01, @04:07PM

              by shrewdsheep (5215) on Monday May 01, @04:07PM (#1304221)

              A soft interrupt is something that is called like a function, i.e. there is an assembly instruction to "call" the interrupt. Memory breakpoints are implemented by setting the memory page as read only and catching the write of read-only page exception.

          • (Score: 2) by ElizabethGreene on Monday May 01, @07:40PM

            by ElizabethGreene (6748) on Monday May 01, @07:40PM (#1304252)

            The coolest thing I've seen in debuggers in a while is in the "new"* version of WinDBG; It supports Time Travel Trace debugging. With it you can run the app, record it, and repro the issue. Then, in the debugger, you can replay and rewind the app to hunt down a problem. E.g. In grandparent's case you'd take a TTT, see that the exception was because location x was corrupted, and then you can rewind in that trace to every function that touched that memory location. The only downside to it is (shocker) it creates a significant performance impact when you're recording.

            *New is in airquotes here because it's been in the Microsoft Store in preview for several years.

            It's pretty cool stuff.

        • (Score: 0) by Anonymous Coward on Monday May 01, @06:27AM

          by Anonymous Coward on Monday May 01, @06:27AM (#1304150)

          Every debugger I used the last 10 or so years before I retired let me set a breakpoint on writing to a specific memory location.

          I don't really have experience in such stuff (since I avoid using C) but I had the impression too often that when others do such stuff the bug doesn't occur... 😂

      • (Score: 3, Interesting) by acid andy on Sunday April 30, @09:33PM

        by acid andy (1683) Subscriber Badge on Sunday April 30, @09:33PM (#1304090) Homepage Journal

        That kind of thing used to happen quite a lot with my code. I learned to write safer code. Nowadays it quite often happens in library code I'm using instead.

        --
        Master of the science of the art of the science of art.
      • (Score: 2) by Thexalon on Sunday April 30, @09:50PM (2 children)

        by Thexalon (636) Subscriber Badge on Sunday April 30, @09:50PM (#1304093)

        What you wouldn't give for a core dump.

        Of course, we had it tough! We had to try to figure out what had gone wrong from a punch card that translated to, in its entirety, "Syntax error".

        --
        The only thing that stops a bad guy with a compiler is a good guy with a compiler.
        • (Score: 3, Funny) by OrugTor on Monday May 01, @04:43PM (1 child)

          by OrugTor (5147) Subscriber Badge on Monday May 01, @04:43PM (#1304227)

          Luxury! When our programs abended the only notification was the console beeping for half a second. When you tell kids today they don't believe you.

          • (Score: 2) by maxwell demon on Monday May 01, @07:09PM

            by maxwell demon (1608) Subscriber Badge on Monday May 01, @07:09PM (#1304249) Journal

            You had a console? Luxury! We had to inject the bits directly into the circuit, using a special digital syringe!

            --
            The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 3, Insightful) by RedGreen on Sunday April 30, @08:57PM (3 children)

    by RedGreen (888) on Sunday April 30, @08:57PM (#1304084)

    that microsoft and security will every meet let alone be implemented by them. What a joke even to have the two words in any sentence that does not say it will never be done by them correctly. They have shown for decades since the companies inception their incompetence in doing it, they have no clue how to do anything securely. Anyone who requires security should ban their products from being used and at the very least should be held fully accountable for any breaches that happen from using it. This means long term jail sentences for the morons who decide to put their garbage into production and get the inevitable hacking that will happen from using their trash.

    --
    "I modded down, down, down, and the flames went higher." -- Sven Olsen
    • (Score: 4, Insightful) by Rosco P. Coltrane on Sunday April 30, @09:05PM (2 children)

      by Rosco P. Coltrane (4757) on Sunday April 30, @09:05PM (#1304085)

      Microsoft is almost unavoidable at work, and it's been unavoidable for decades. Even the most Unix-friendly shop has at least a couple of Windows machines For Word or Excel.

      When you're almost forced to use a product, what would the maker of the product be incentivized to fix it?

      • (Score: 2) by RedGreen on Sunday April 30, @10:17PM (1 child)

        by RedGreen (888) on Sunday April 30, @10:17PM (#1304099)

        "When you're almost forced to use a product, what would the maker of the product be incentivized to fix it?"

        They get to go and spend twenty or thirty years in jail for each breach for the managers, the programmers get to do ten or fifth-teen. For the company a million dollar fine for each machine breached get a thousand machines breached a quick billion off the bottom line with no expense of the fine for accounting purposes.. I think it could have an effect on their attitude of not giving a shit for all these decades. Keep up with it then corporate death penalty all the investors money gets to go up in smoke.

        --
        "I modded down, down, down, and the flames went higher." -- Sven Olsen
        • (Score: 2) by fliptop on Monday May 01, @12:31AM

          by fliptop (1666) on Monday May 01, @12:31AM (#1304114) Journal

          a million dollar fine for each machine breached

          From my experience the entry point is usually a poorly configured router, a router that is not running the latest firmware (yes Cisco, I'm looking at you [techcrunch.com]), but the most common is an employee who adds a WAP to the network w/o IT's knowledge. Actually, that's kind-of on IT as well for enabling DHCP since most regular users wouldn't be able to snorgulate how to assign a static IP.

          Of course, the shops who can't afford IT staff but have numerous Windows boxes that are unpatched, well that's a different kettle of fish...

          --
          To be oneself, and unafraid whether right or wrong, is more admirable than the easy cowardice of surrender to conformity
  • (Score: 2) by turgid on Sunday April 30, @09:10PM (2 children)

    by turgid (4318) Subscriber Badge on Sunday April 30, @09:10PM (#1304087) Journal

    But Herb Sutter said we must write absolutely everything in C++, no excuses! And if we start to doubt, he'll said a crack team of high priests round to give us a cup of coffee and a doughnut and a little chat about where we are going wrong, to put us back on the straight and narrow. And Meyers has a series of books.

    • (Score: 1, Touché) by Anonymous Coward on Monday May 01, @12:53PM (1 child)

      by Anonymous Coward on Monday May 01, @12:53PM (#1304191)

      You mean Microsoft employee Herb Sutter? Hmmmm, I see a new series of books on the horizon.

  • (Score: 5, Insightful) by RamiK on Sunday April 30, @10:27PM (5 children)

    by RamiK (1813) on Sunday April 30, @10:27PM (#1304101)

    Microsoft has already embraced the technology as one of the most promising upgrades for Windows core programming

    Extend and extinguish to go...

    --
    compiling...
    • (Score: 4, Touché) by Gaaark on Monday May 01, @12:41AM

      by Gaaark (41) Subscriber Badge on Monday May 01, @12:41AM (#1304115) Journal

      I'm waiting for Microsoft to embrace Microsoft: that'll end up good for everyone else!

      --
      --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
    • (Score: 3, Insightful) by maxwell demon on Monday May 01, @06:47AM (1 child)

      by maxwell demon (1608) Subscriber Badge on Monday May 01, @06:47AM (#1304151) Journal

      Well, they embraced and extended JavaScript (remember ActiveX?), but they failed to extinguish it.

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 2) by RamiK on Monday May 01, @10:53AM

        by RamiK (1813) on Monday May 01, @10:53AM (#1304180)

        The EU directly blocked the integration of the browser into the shell so they couldn't take ActiveX into the desktop like they planned.

        --
        compiling...
    • (Score: 2) by turgid on Monday May 01, @09:02AM (1 child)

      by turgid (4318) Subscriber Badge on Monday May 01, @09:02AM (#1304165) Journal

      They will "extend" it with some over-complicated features that break the memory safety in some subtle way for "efficiency" or something and there will be a Microsoft-specific dialect of the language with this new feature. All the Windows developers will code in this special dialect.

      • (Score: 3, Insightful) by RamiK on Monday May 01, @11:10AM

        by RamiK (1813) on Monday May 01, @11:10AM (#1304181)

        My concern is less to do with them bifurcating the language itself (Rust has extensions mechanisms to prevent this) but with their gate-keeping powers through their control over vscode combined with their newly found interest in the language creating a situation where much of the tooling ecosystem will have to prioritize windows support to get any traction much like how Qt ended up.

        --
        compiling...
  • (Score: 2) by jb on Monday May 01, @04:43AM (1 child)

    by jb (338) on Monday May 01, @04:43AM (#1304144)

    Historically, the vast majority of security issues encountered on the Windows platform have been memory-related bugs.

    That is, except for those issues caused by fundamental design flaws in the system architecture ... which from memory was almost all of them.

    • (Score: 5, Funny) by maxwell demon on Monday May 01, @06:48AM

      by maxwell demon (1608) Subscriber Badge on Monday May 01, @06:48AM (#1304152) Journal

      which from memory was almost all of them.

      See? Memory related! ;-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
(1)