Kernel vulnerabilities: old or new?

I'm speaking from an uninformed position here so I may just be regurgitating marketing I've heard, but it seems like Microsoft has really taken a leadership position in securing the NT kernel.

Their biggest problem (in recent history) has always been in 3rd party drivers, but I hear less and less about these being exploited lately. Have they sufficiently hardened their DDK to prevent the majority of these problems? Is there something about their driver architecture - some microkernel-esque fault isolation perhaps - that prevents wider system compromise?

I don't see how you could prevent a driver from, say, dereferencing a NULL pointer, but it seems like it would be a nice feature to have a lower barrier to entry for device driver writers. Specifically: can the Linux driver model be crafted such that a hardware manufacturer can provide a driver (in source code form or otherwise) that is sloppily written yet not expose the kernel to further breach? Would running drivers in ring1 instead of ring0 achieve this?

Requiring perfect code in order to support a device, while ideal, seems like a long-term losing proposition. One could make the same argument for network protocols or file systems.

Is this a reasonable goal or is it overkill? Is it anything other than a microkernel architecture that's been dismissed out of hand since Linux 0.01? And perhaps philosophically, is it reasonable to even consider killing and respawning a misbehaving driver?

-

It seems like what I'm really thinking of is a [fixed] kernel API for drivers, but I expect this has already been discussed and rejected many times over. But for example, when descending the drivers/ directory, the 'kmalloc' symbol can be #defined to something invalid, forcing drivers to use ddk_malloc() which has grsec-style checking built-in. (This "kernel API" would be a family of ddk_xxxx() calls.)

Alternately, for code paths where it's deemed more important to be fast than safe (scheduler, SL*B allocators, other "core" code), there can be an audited/ tree as the only place where code has access to versions of the system calls that aren't encumbered by security restrictions. (The ddk_xxxx() calls would naturally live here.)

Or is this just not seen as a problem?