Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Windows Programming Build

First Rust Code Shows Up in the Windows 11 Kernel 42

According to Azure CTO Mark Russinovich, the most recent Windows 11 Insider Preview build is the first to include the memory-safe programming language Rust. Thurrott reports: "If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel," Russinovich tweeted last night. It's not clear which Insider channel he is referring to, however.

Regardless, that that was quick: Microsoft only went public with its plans to replace parts of the Windows kernel with Rust code in mid-April at its BlueHat IL 2023 security conference in Israel. At that event, Microsoft vice president David Weston said that "we're using Rust on the operating system along with other constructs" as part of an "aggressive and meaningful pursuit of memory safety," a key source of exploits. And it's not just the Windows kernel. Microsoft is bringing Rust to its Pluton security processor as well.
This discussion has been archived. No new comments can be posted.

First Rust Code Shows Up in the Windows 11 Kernel

Comments Filter:
  • I wonder if they are eventually going to replace the entire kernel using Rust.

    If you currently want to see an OS written entirely in Rust, check out Redox: https://www.redox-os.org/ [redox-os.org]
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      Memory safety is a problem, but it isn't the only problem. You can write shitty, buggy code in any language. Including Rust.
    • Unfortunately, the problems within Windows kernels cannot be solved with language swap.
    • I wonder if they are eventually going to replace the entire kernel using Rust.

      That depends on whether this was on purpose or if someone was just cruising the kernel source and noticed something wrong. Alarms were sounded, "here there be rust!", panic ensued. Who did that? Why would anyone do that? Does anyone even use Windows 11?

      All questions whose answers are about as interesting as ferrous oxide.

  • by techno-vampire ( 666512 ) on Thursday May 11, 2023 @05:38PM (#63515105) Homepage
    Now that they're finding Rust in the Windows kernel, they're going to have to be putting on a good coat of Rust-Oleum [wikipedia.org] to keep it from spreading all over the place!
    • Good point. Instead of Windows locking up it will be seizing up. Rust-Oleum may work, but nothing beats an old school hot oil treatment.
      • I've got such a bad case of dust contamination I can barely bluescreen!
      • Rust-Oleum may work, but nothing beats an old school hot oil treatment.

        Except, you know, acid tanking and re-coating with zinc. You're all like "my band-aid can outperform your band-aid" when both are half-assery. Granted, that was unintentionally perfect of you both, because we're talking about Windows and slipping some Rust code into the kernel can't fix what's wrong with it... which isn't so much the kernel as everything else.

  • unsafe {
    ,,,
    };

    unsafe {
    ...
    };

    unsafe {
    ...
    };

    Only joking a little... there's so much raw pointer fuckery, every Windows kernel mode code in Rust I've seen can barely go 5 lines without unsafe coming up.
    • That's probably because it has to use FFI, which you basically can't do without dereferencing raw pointers, which is something that applies to every language, even scripted ones like Python. However I don't think FFI will be needed that much for what I think they implemented, which is a replacement for DWriteCore. Moreover, FFI isn't usually a source of memory errors as all you're typically doing there is unmarshaling raw data at the referenced memory, which is generally hard to get wrong as usually if you

  • by account_deleted ( 4530225 ) on Thursday May 11, 2023 @07:57PM (#63515341)
    Comment removed based on user account deletion
  • by account_deleted ( 4530225 ) on Thursday May 11, 2023 @07:57PM (#63515345)
    Comment removed based on user account deletion
  • Comment removed based on user account deletion
    • by gweihir ( 88907 )

      In the end, Rust is just another futile attempt at writing secure code with cheap, semi-competent coders. That will never work. The whole thing is bogus, but it has some very loud screamers on its side that have no insight but a deep conviction that they are right. Essentially a cult.

      • Comment removed based on user account deletion
        • by gweihir ( 88907 )

          Hehe, indeed. What crappy tech you can push with good PR was nicely demonstrated with systemd a while ago.

        • A cult with money and a good PR department. All the cults I have started have failed, pretty much because of not having had any of that. Some of them weren't even completely about evil stuff. So unfair.

          If you want a cult to succeed long enough to turn into a religion, you need to secure lots of land early on, probably through donors. So next time, make sure that your cult appeals to the well-heeled, and/or the elderly (who can will you their property.)

    • by vyvepe ( 809573 )

      It is still more curious that most of those mentions include the "memory-safe" tag, as if it was something unusual (most of modern languages are memory safe)

      The reason why Rust is talked a lot about is because it can be used as a low level system language while still providing memory safety. Most memory safe languages cannot be used for writing e.g. an operating system or a real time application. Rust can.

      • Comment removed based on user account deletion
        • by vyvepe ( 809573 )
          If there are some other language suitable for system programming then please let me know. By system programming, I mean a low level stuff like an operating system kernel or a driver and not e.g. a "system of web services". By real time, I mean hard real time systems. That means that all the languages with a garbage collector do not qualify.
          • Comment removed based on user account deletion
            • Comment removed based on user account deletion
            • by vyvepe ( 809573 )

              You cannot use a language which needs GC for a hard real time system in general. Hard real time system is not about performance (computational throughput over a longer time) but about always obeying maximum latency requirements (for some parts of the code). You can use a language with GC for some parts of an operating system or some (part(s) of) driver(s). These are the parts which do not have hard real time requirements or the parts which can run safely with GC disabled. Notice that real time systems have

              • Comment removed based on user account deletion
                • Comment removed based on user account deletion
                  • by vyvepe ( 809573 )

                    The last real time system I worked on had deadline 64 microseconds. The system was not a hard real time. I could miss the deadline once and the hardware would not blow up. It would blow up if I was unlucky and I would miss the deadline at least 2 times in a row.

                    The time required for a garbage collection depends on the application and the type of garbage collector. Typical JVM garbage collection should take about 5 - 35 milliseconds, should always be below 500 milliseconds. Overall an application should not

      • The reason why Rust is talked a lot about is because it can be used as a low level system language while still providing memory safety. Most memory safe languages cannot be used for writing e.g. an operating system or a real time application. Rust can.

        The language seems to me to be a bit too heavy handed in the concurrency department for this to become reality.

    • Comment removed based on user account deletion
  • https://github.com/rust-lang/r... [github.com]
    Intentionally written in decimal rather than hex
    const PROBLEMATIC_CONSTS: &[u32] = &[
            184594741, 2880289470, 2881141438, 2965027518, 2976579765, 3203381950, 3405691582, 3405697037,
            3735927486, 4027431614, 4276992702,
    ];

    • by nagora ( 177841 )

      Okay. That is pretty pathetic.

      I mean, who even sits down and thinks of making sure that 0xB00B135 is hidden?

    • Intentionally written in decimal rather than hex
      const PROBLEMATIC_CONSTS: &[u32] = &[
      184594741, 2880289470, 2881141438, 2965027518, 2976579765, 3203381950, 3405691582, 3405697037,
      3735927486, 4027431614, 4276992702,
      ];

      This is troubling: intentional obfuscation of source code to explicitly hide its function, half-assed implementation and injection of politics and judgement where inappropriate.

      Should programmers also expect their instructions to be surprise countermanded and be told to F0AD by the morality/ideology officer baked into Rust tools if they use this language? Is Rust protestware?

      Some have no understanding of the value of trust and how easy it is to lose. These stunts even harmless easter eggs have no place in

    • For anyone too lazy to convert these to hex: 0xb00b135, 0xabadbabe, 0xabbababe, 0xb0bababe, 0xb16b00b5, 0xbeefbabe, 0xcafebabe, 0xcafed00d, 0xdeadbabe, 0xf00dbabe, 0xfeedbabe.

      The worst offense of the very worst offenders here is just being kinda juvenile. Even for a style guide, it's petty to call these "problematic" if these particular values matter. I was just explaining to someone the other day why the "use this software for good, not evil" clause in the JSON license is at best unenforceable, and at wors

  • It's closed source. There could be anything in there and we'd be none the wiser.
  • Interesting!

As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs.

Working...