> This is likely because of a malicious piece of code in 1 of the
> device drivers written in-house.

Your in-house driver contains malicious code?  Man, you've got far
bigger problems than just some NetBSD issues.

> btw, [in the long term] is it possible to insulate the kernel from
> malicious code in the driver?

No.  Nothing can insulate the rest of the system from malicious code in
any part of the kernel that runs in the privileged hardware mode
(kernel mode, supervisor mode, whatever a particular CPU calls it).
Such code can always take over the system completely if it feels like
it; that is, after all, what privileged mode is all about.

> if UVM allows userland code to selectively read/write kernel memory,
> that should allow us to write driver modules in userspace.

In principle, something of the sort may be possible.  It would be a
very different kernel architecture, though, since it would mean that
practically all driver activity would mean scheduling a userland
process; you'd end up with something closer to QNX or (IIUC) Mach.
Now, it would mean this only for the affected drivers, but doing it for
even one driver means supporting it in the DDI, which is what would
demand the rearchitecting.

I'm also not sure how much good it would do.  In order to protect
against malicious access to other things, you have to either ensure
that you don't have two devices falling in the same page of memory or
you have to take a kernel trap and vet every access.  The former is not
possible for some busses on architectures with fixed-size pages (and
not possible at all for non-memory-mapped I/O like i386 inb/outb,
without additional hardware support - an MMU analog for the relevant
form of access) and the latter pays a severe performance price.  And
you can't even in theory protect against a driver doing malicious
things with the device it handles.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B