Du bringst hier einiges durcheinander. Die Hardware-Ressourcen verwaltet Linux über dedizierte Subsysteme, die man sich als eine Sammlung von Unterprogrammen innerhalb des Kernels vorstellen kann. Der Scheduler hingegen verwaltet weder RAM noch irgendwelche Massenspeicher-Protokolle, sondern ist allein für die Taskwechsel zuständig, sprich, alles was er verwaltet ist die Zuteilung von Rechenzeit einer oder mehrerer CPUs an Prozesse bzw. Threads.
Auch hat ein root-User keinen Zugriff auf privilegierte Bereiche des Kernels. Er muss genauso wie ein 0815-User per System Calls mit dem Kernel kommunizieren. Er hat dabei Zugriff auf weitere Calls, die einem normalen User nicht zur Verfügung stehen. Merke: root-Rechte nicht mit Kernelspace verwechseln. Wenn ein Programm mit root-Rechten im Kernelspace herumwurschteln will, wird es genauso mit einem SEGFAULT aus dem Speicher gekickt wie jedes andere Programm auch. Ein Unterprogramm innerhalb des Kernels (z.B. als Bestandteil eines NIC-Treibers oder eines Dateisystems) kann hingegen wirklich machen, was es will. Spinnt so ein Subsystem rum, ist es mit der Stabilität vorbei, da es alles ins Nirvana reißen kann. Ein klitzekleiner Fehler hat also im Kernelspace u.U. eien verheerende Wirkung. Ein Userspaceprogramm hingegen stürzt einfach mit einem SEGFAULT ab, ohne andere Programme oder gar den Kernel zu beeinflussen. Und hier setzt das Konzept des Microkernels an.

Microkernel sind in ihren Fähigkeiten gegenüber monolithischen Kerneln arg beschränkt. Vereinfacht gesagt kümmert sich ein Microkernel fast nur um Scheduling und Interprozesskommunikation und bringt gerade mal so viel Ressourcenverwaltung mit, dass er sich selbst und die Userspace-Daemons starten kann. Sämtliche Ressourcenverwaltung wie Dateisysteme wird auf Userspace-Programme ausgelagert. Prozesse im Userspace können nur auf ihre eigenen Ressourcen zugreifen und müssen sich mit anderen Prozessen oder dem Kernel nachrichtenbasiert unterhalten. Wenn ein solcher Prozess Amok läuft, kann er so nur sich selbst, aber nicht die anderen Prozesse oder gar den Kernel abschießen, so zumindest die Theorie. Die Möglichkeit der nachrichtenbasierten Kommunikation stellt dann der Microkernel zur Verfügung. Beispiel: Wenn ein Treiber absemmelt, bleiben die anderen Prozesse wie Speicherverwaltung und Dateisysteme intakt und der betreffende Treiber z.B. kann neu gestartet werden. Ziel des ganzen ist also ein robusteres System und eine Vereinfachung der Entwicklung. Allerdings hat sich herausgestellt, dass die korrekte Kommunikation der einzelnen Daemons eine ganz eigene Komplextität mitbringt, bei monolithischen Kerneln viel einfacher zu bewerksteligen ist.