They are claiming up to 70% of the vulnerabilities can be avoided in a language like rust, I think a good chunk of the other 30% can be avoided using a language with a type system like rust's. I'm continually amazed at how much an expressive type system can help minimize bugs
This. Going from JS to strict TS eliminated a large portion of bugs, that with a strict state flow (redux in this case) it eliminated 95% of the bugs we encountered in the past.
Typescript makes writing large codebases in js actually possible. But it's still missing a few things and there's not much they can do about it. Pattern matching, and real support for sum types (not just having a 'type' field w/ a string) would be at the top of my list I think. Working with type parameters can also get a bit unweidly, and bounding them with the 'extends' keyword is a pain in the ass. IMO of course.
Is this an influential body inside MS? Sounds like good news for the Rust community that a team like this recommends that a bigco like MS explores Rust.
MS is already exploring Rust via Azure IoT Edge, VSCode search engine, Actix, Firefox for HoloLens.
So it is positive that security group is also pushing for it, alongside .NET and Core Guidelines for C++.
Now how much politic weight they are able to carry, remains an open question. If WinDev was more sympathetic towards DevDiv probably Longhorn would have actually happened, as proven by Singularity and Midori.
Singularity and Midori relied on GC for memory safety, and that was a huge problem for Longhorn/Vista because it was very difficult to write code that would work reliably when memory is critically low.
Rust is a completely different story. Sure, Rust's standard library treats OOM is fatal, which is the right thing for almost all application code, but it's not difficult to create Rust libraries that treat OOM as a recoverable error, or that don't allocate at all.
If the Singularity group had invented Rust instead of Sing# things might have turned out differently.
Yet according to MSR Midori had no issues powering a portion of Bing in production.
Multiple OSes have been written in GC enabled system languages.
Having a GC doesn't mean all memory is required to be GC allocated on the heap, usually the same mechanisms of a language like C++ are also available, e.g. Modula-3, System C#, D and so forth.
Joe Duffy clearly states in one of his Midori talks that WinDev did not believe in Midori, even with it running in front of them.
It would be feasible if WinDev had not sabotaged the work, as it became later visible with moving Longhorn design into COM for Vista, followed up by WinRT, with a .NET toolchain designed by WinDev, partially incompatible with standard .NET features. Sinosfky wasn't that keen in having .NET take the lead.
Now after Midori, and the way things turned out for UWP, we are coming back full circle with .NET 5, XAML Islands and WinUI.
Agreed. Mozilla and Cloudflare and Dropbox are great, but given the language's ambitions it would be a huge benefit to have real commitment from one of the big five.
So 70% of the vulnerabilities are still caused by lack of memory-safety, and that doesn't even account for all the defects that don't end up in a vulnerability. Imagine how much more safety and correctness there would be, if not only those 70% didn't exist, but no time had to be spent to fix them and rather concentrate onto avoiding the other 30%.
This isn't an advisory, it's just a blog post. We're meant not to editorialize titles, and this one was a doozy; the appropriate title is "A proactive approach to more secure code".
I've noticed that happening a lot lately. It's frustrating because the blog post is interesting on its own merits and doesn't need to have a click bait title inserted.
See the recent front-page post about "England selects new face of fifty-pound bill" or something of the sort. The title of the linked BBC article included that Alan Turing had been chosen, yet the poster chose to make it click-bait.
Maybe my lack of English skills, just provided the title that made sense to me, as 1:1 mapping to the title seemed not fully describing their intention.
Depends on which memory safe language they use and how (plus this blog post isn't by the Windows team or about Windows specifically). The biggest thing that slows Windows is lock contention, back-compat, and abstraction layers. Those problems all remain regardless of language choice.
Taking what's probably a joke too seriously for a moment, I don't think that follows at all. This is a research group within Microsoft doing exploratory work, so it shouldn't affect Windows at all. Further, they say they are "starting with Rust", which is not a whole lot slower than C++ (and you can always dip down into a different language for extremely performance sensitive parts).
Windows' slowness is almost all attributable to process startup time and a lot of modern apps being based on Electron, Chrome, JavaScript, and other very process-happy environments. Writing applications in Rust is not going to change Windows' process startup system.
