This post is good on security and bad on OS design. The last 10 years of OS design has in large part been about finding small facets of the kernel that can be exported to userland via apertures and very-low-level programming interfaces.
The answer "no you can't have these privileged instructions" is incomplete; it's missing "but here's the API that safely wraps them."
Problems like this are part of what makes OS security so interesting. Good security isn't about saying, "no, moron, if I give you that capability you'll be able to own up the kernel." In fact, security is almost never about saying "no". When you tell someone "the only way to build this feature is by writing a driver", you're asking them to write kernel code instead of userland code, which makes security worse.
Well, what that really means is "the only way to build this feature is by writing code that gets signed, either by you or by some trustworthy guy." The trust is supposed to come from the code signing, not from the fact that it's a driver and not a user-mode app.
Code signing is rubber chicken security. It sure sounds good. But the threat with code like this is incompetence, not malice, and nobody --- nobody --- has the resources to audit every Windows driver, or even every OSX driver for that matter.
The problem here is that the interface the MSDN blogger is talking about is brittle. "You can't have those instructions unless you write a driver". Well, they're going to get the instructions, genius. They have a business driver, and business trumps principles every time. So they're going to go through whatever dance MSFT requires this year to ship as a driver, and the kernel's going to get one more piece of incompetent driver code.
Maybe I'm missing some backstory here, but that's my read.
I think pretty much all the OS vendors have equally bad track records with kernel/userland interface design. But, having done a few device driver audits, I respectfully disagree, and submit to you that if your job exposed you to 3rd party driver code, you too would rather MSFT took a risk on kernel APIs than increase the number of drivers.
Don't get me wrong: I would absolutely prefer MSFT write a proper API to handle the necessary requests, rather than leave it to vendors to write drivers.
But in reality no API will cover every corner case. And if the choice is between vendors writing drivers to cover those situations, or Microsoft leaving a 'hole' in the API which allows arbitrary instructions to be passed through, I'll take vendor drivers every time.
This extends to other areas as well. I was shocked the first time I found an "enterprise" app with an interface for executing arbitrary SQL with full permissions. The shock wears off when you see it over and over. It's nuts.
Amen. I'm surprised by how many developers think this is a totally reasonable debugging feature, and think that nobody is going to find it because it's in a hidden diagnostic support section of the application. Note to product developers: we always find these things.
This would be because there are very, very few people, even among your programmers, that can actually consider all of the needed cases when dealing with "business logic".
So you end up having to have an ability to do something dangerous and disaster prone to keep the whole ball of crap from falling apart in a most splendid way.
The answer "no you can't have these privileged instructions" is incomplete; it's missing "but here's the API that safely wraps them."
Problems like this are part of what makes OS security so interesting. Good security isn't about saying, "no, moron, if I give you that capability you'll be able to own up the kernel." In fact, security is almost never about saying "no". When you tell someone "the only way to build this feature is by writing a driver", you're asking them to write kernel code instead of userland code, which makes security worse.