[MichaelGG]

Can you point to remote execution issues in the CLR? I'm having a rather hard time thinking of any that'd impact an organization. The CLR issues with unsafe code has almost entirely been related to trying sandbox binaries (via CAS or loading .NET apps via browser plugins (same as Java)).

I'm unaware of any time the CLR would provide any useful attack surface. The only ones that come to mind are GDI+ issues that .NET inherits via passthrough. So, citation needed, I guess?

Agreed that use of C/++ code in general is bad and for all the effort spent on mitigation, we'd be better off moving to a proper language, but ... doesn't seem like that's happening.

A rewrite is rather silly; the NT kernel is well respected and capable. You're basically suggesting "throw away everything and start a new company" which certainly doesn't seem like a winning strategy.

[monopolemagnet]

You missed the boat and went off on a strawman fallacy based on a fundamental misunderstanding: Microsoft OS code and libraries, are implemented not just in C/C++/some asm but are also implemented in CLR languages. All that legacy crap in a variety of languages is a huge attack surface. Demanding pointing to closed source proof is an impossible, specious fools' errand.

Have you ever done any Windows NT kernel driver development? Compared to OS X (xnu) kexts or Linux, it's a disaster. XNU and Linux extensions are also not that great because it follows the same, flawed insecure methodology of allowing kernel extensions to modify the kernel, which OpenBSD wisely eliminated.

The other strawman you raise, trying put the wrong words in my mouth, rewriting a massive legacy codebase does not throw everything away. The lessons learned are the most important. Instead, OS and app virtualization can be used to run prior OS/apps while new apps can run in a new environment, sharing a filesystem as needed. That doesn't start over "from scratch, with inexperienced people", which is your incorrect presumption because that would be foolish. Otherwise, the Microsoft ecosystem will continue to accrue technical debt and job security which can never be paid off, because it's stuck in 1993.

The kernel should be the kernel.. a tiny, mostly immutable thing which does just enough to provide process/thread isolation, IPC and such. Even better is capabilities-granted privilege requests to perform unsafe operations, so that drivers are demoted to least-privilege processes. QNX and MINIX loosely follow this, and it's a far more secure and robust benefits of reasonable microkernel architecture approaches.

[asveikau]

> Have you ever done any Windows NT kernel driver development? Compared to OS X (xnu) kexts or Linux, it's a disaster.

I have done NT drivers and linux kernel modules. I disagree with your statement. Can you be more specific?

I'm not saying there are no warts in NT, but your comment doesn't demonstrate any knowledge of where they are.

[monopolemagnet]

What kind of NT drivers (USB, Storage, what)? What kind of Linux kernel modules?

I've worked on storage drivers for Linux (2.6), Mac (10.6+ - 10.8) and Windows.

What like Nt vs Zw? Are you fucking serious? Do I need a badge and certification from you too, your majesty? You haven't proven you've done shit either, but it doesn't matter.

You don't have experience with xnu kexts (which make much more sense, at least more so than the Linux model), so I don't see how you can claim, broad pseudo-expert "opinion" on something you know nothing about.

Regardless, these three approaches are still irrelevant because they're critically flawed: granting transfinite trust to the kernel driver developer to not fuck up. A real microkernel model, only a process would likely crash. QNX runs on billions of devices, including now BlackBerry 10 since they acquired it: game, set, match.

That's the boat you've missed trying to go off into the weeds and make it a personal attack, because you have nothing.

[asveikau]

Calm down. I'm not asking for a badge of certification whatever whatever. I just don't understand what the complaint is and therefore cannot evaluate it.

[Since you asked, the biggest complaint in my filesystem-centric Windows experience is that filesystem drivers are very "heavy". There is not really a layer like Linux VFS which can handle common bug-prone tasks before they get to your driver. The driver is expected to do a lot. But I don't think drivers are easy on any platform.]