SoylentNews is people
SoylentNews
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.
(Score: 4, Interesting) by Snotnose on Sunday April 30, @09:32PM (8 children)
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)
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)
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.
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)
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
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
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
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
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
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... 😂