Ich versuche genau zu verstehen, was Userland ist. Jeder, den ich frage, sagt: „Alles, was nicht Kernel ist.“ Aber das ist für mich nicht greifbar. Wenn ich lese, dass der Kernel diesen Treiber im Userland ausführen kann oder so etwas, kann ich mir nicht wirklich vorstellen, was passieren wird! Ich wäre also dankbar, wenn mich jemand diesbezüglich aufklären würde.
Antwort1
Auf einer konzeptionellen Ebene ist der Kernel alles, was auf einer „privilegierteren“ Ebene des Hardwareschutzes läuft. Das wäre etwa Ring 0 auf x86-Prozessoren, Systemmodus auf ARM, Kernelmodus auf MIPS, Supervisormodus auf 68xxx usw. Der Kernel ist normalerweise unterbrechungsgesteuert, entweder Software-Unterbrechungen (Systemaufrufe) oder Hardware-Unterbrechungen (Festplattenlaufwerke, Netzwerkkarten, Hardware-Timer).
Auf derselben konzeptionellen Ebene ist „User Land“ das, was im Modus mit den geringsten Privilegien läuft (Ring 3 auf x86-CPUs, Benutzermodus auf ARM oder MIPS usw.). User Land nutzt die Art und Weise, wie der Kernel kleinere Hardwareunterschiede ausgleicht und allen Programmen dieselbe API präsentiert. Beispielsweise haben einige WLAN-Karten möglicherweise zusätzliche Steuerregister im Vergleich zu anderen oder verfügen über mehr oder weniger integrierten Puffer für eingehende Pakete. Der Treibercode berücksichtigt diese Unterschiede (manchmal indem er erweiterte oder ungewöhnliche Funktionen ignoriert) und präsentiert allen Programmen dieselbe Socket-API.
Einige Prozessoren (z. B. x86, VAX, Alpha AXP) haben mehr als zwei Modi, aber die generische Unix-Architektur verwendet die Zwischenmodi nicht.
Die Programme und Prozesse, die Sie unter Unix, Linux oder *BSD laufen sehen, sind das Benutzerland. Da Prozesse unterbrechbar sind, sehen Sie den Kernel nie laufen, sondern nur Nebeneffekte, wie die read()Rückkehr eines Systemaufrufs oder die Ausführung einer Signalhandlerfunktion.
Um Ihre konkrete Frage zu beantworten: Unter Unix, Linux und *BSD ist ein „Treiber“ normalerweise ein kleines Stück Software, das sich mit den spezifischen Besonderheiten eines Hardwareteils befasst: einer Netzwerkkarte, eines Laufwerks, einer Grafikkarte. Die Treibersoftware muss fast immer im Ring 0/Supervisor-Modus/Kernelspeicher ausgeführt werden, um Zugriff auf Hardware-Interrupts oder den zugeordneten Speicher der Hardware oder was auch immer zu haben. Der Treiber kümmert sich um bestimmte Hardwarefunktionen und sorgt dafür, dass diese Hardware in die standardisierte oder konventionelle Ansicht des Kernelcodes passt, wie Hardware funktionieren sollte. Wenn ein Treiber im Userland ausgeführt wird, muss der Kernel daher einem Userland-Programm Dinge wie zugeordneten Speicher oder Geräteregister oder Interrupts oder andere spezielle Funktionen anzeigen. Das kann schwierig sein, da die speziellen Funktionen, die ein Gerät möglicherweise benötigt, nicht ohne weiteres in die übliche API im Unix-Stil passen, die Userland-Programmen präsentiert wird. Auch die Planung ist ein Problem, da Userland-Programme normalerweise nicht so schnell auf Interrupts reagieren.
Antwort2
Die meisten modernen CPUs haben eineKerneloder Supervisor-Modus und eine eingeschränkteBenutzerModus. Dies ist eine Hardwarefunktion der CPU. „Userland“ ist ein anderer Name für Code, der im Benutzermodus ausgeführt wird.
Ein großer Unterschied zwischen den Modi besteht darin, wie die MMU der meisten modernen CPUs unter ihnen reagiert.
Eine MMU ermöglicht es einem Kernel, Blöcke (oder Seiten) des RAM so umzuordnen, dass sie in einer anderen Reihenfolge zu codieren scheinen, als sie physisch im RAM sind, und auch, dass Benutzermoduscodefangenoder "Fehler" zurück zum Kernelmodus, wenn auf bestimmte Seiten zugegriffen wird. Der Benutzermodus kann nicht ändern, was die MMU macht, das kann nur der Kernelmodus.
Die MMU ermöglicht es dem Kernelmoduscode, alle möglichen coolen Dinge zu tun, wie zum Beispiel:
- „Anordnen“ oder „Zuordnen“ des Speichers zum Benutzermoduscode, sodass dieser Code denkt, er verfüge über zusammenhängenden RAM.
- Implementieren Sie ein dynamisches Speicherverwaltungsschema, bei dem ein Prozess Speicher anfordern muss, bevor er versucht, ihn zu verwenden.
- Stoppen Sie Benutzerprozesse, wenn sie Speicher verwenden, für den sie nicht vorgesehen sind.
- Lagern Sie am wenigsten genutzte Seiten auf die Festplatte aus, wenn der freie Speicher knapp wird, und lagern Sie sie wieder ein, wenn ein Prozess versucht, auf sie zuzugreifen.
Sie sehen, dass die MMU zusammen mit dem Kernel-/Benutzermodus der Eckpfeiler eines Multitasking-Betriebssystems ist. Mit diesen Tools lässt sich ein System erstellen, das mit höherstufigen Dingen wie der Idee von Prozessen funktioniert. Ein Kernel verwaltet Seitentabellen für jeden Prozess und programmiert die MMU grundsätzlich neu, bevor er in den Benutzermodus wechselt und die Kontrolle für seinen Zeitabschnitt an einen Prozess übergibt. Dinge wie mallocund Sachen, bei denen ein Prozess Speicher beansprucht, veranlassen den Kernel, MMU-Seitentabellen zu ändern.
Auch hier kann der Benutzermodus nichts mit den Seitentabellen machen (und muss nicht wirklich wissen, dass sie existieren). Wenn er Speicher benötigt, muss erAnrufder Kernel, der einen Wechsel vom Benutzermodus in den Kernelmodus bewirkt. CPUs bieten einen einfachen Mechanismus namensSoftware-Interruptum dies zu tun,und es gibt andere schnellere Möglichkeiten, die der Linux-Kernel verwendet.
Aufgrund dieses Schutzes, der im Benutzermodus besteht, kann der Kernel diesen Prozess stoppen, wenn ein Programm abstürzt oder verrückt spielt und sich selbst überschreibt. Im Kernelmodus besteht dieser Schutz nicht, sodass der Kernel und damit auch Ihr gesamtes System nicht mehr funktionieren. Wenn ein nicht behebbarer Fehler wie dieser im Kernelmodus auftritt, nennt man das Kernel Panic. SieheWas ist eine „Kernel Panic“?für Details.
Kernel kann diesen Treiber auf dem Userland ausführen
Der Kernel- oder Supervisor-Modus von CPUs verhindert auch, dass der Benutzermodus direkt auf E/A-Geräte zugreift. Die Idee ist, dass dazu der Kernel aufgerufen werden muss. Unter Linux ist Code, der direkt mit Geräten kommuniziert (sie werden im Kernel-Modus ausgeführt),Gerätetreiber(Eine Art vonKernelmodul, können Sie sie mit Befehlen wie lsmod, insmod, modprobe, und bearbeiten rmmod).
Was passiert, wenn Ihr Gerätetreiber, der im einfachsten Setup im Kernelmodus laufen würde, einen Fehler hat und etwas Schlimmes tut, wie zufällige Sachen im RAM zu überschreiben (und da er im Kernelmodus ist, hat er uneingeschränkten Zugriff auf den gesamten RAM und kann den Kernel selbst überschreiben). Es wäre schön, wenn wir den Gerätetreiber im Benutzermodus laufen lassen könnten, sodass er dem Kernel selbst oder anderen Prozessen nichts antun kann.
Leider ist der Wechsel vom Benutzer- in den Kernelmodus (ein sogenannterKontextwechsel) ist langsam, da grundsätzlich der gesamte Zustand der CPU für jeden Prozess oder den Kernel selbst ein- und ausgeschaltet werden muss. Es stehen also zwei Dinge im Widerspruch: Sicherheit oder Geschwindigkeit, und daher ist dies ein Streit- und Designpunkt.
Kernel, die versuchen, so viel wie möglich im Benutzermodus zu tun, heißenMikrokerne, und Linux ist das Gegenteil, das heißtmonolithisch. Es gibt User-Mode-Treiber für Linux (siehe FUSE als Beispiel) und es gibt sogar einenRahmendas es erlaubt.
Antwort3
Aufbauend auf dem, was Bruce gesagt hat, muss aller Code, der dem Kernel zur Verfügung gestellt wird, vertrauenswürdig sein. Wenn es irgendwie möglich ist, dass der Kernel bösartigen Code ausführt, ist das Spiel vorbei. Hier kommt die Privilegientrennung zwischen vom Benutzer ausgeführtem Code und vom Kernel ausgeführtem Code ins Spiel. Code, der von einem Benutzer ausgeführt wird, muss nicht unbedingt 100 % frei von Schadcode sein. Er wird nicht direkt vom Kernel ausgeführt.
Userland-Programme interagieren einfach mit exponierten Teilen des Kernels, wie APIs und geladenen Modulen. Ein Beispiel wäre iptables. Es gibt mehrere Kernelmodule (.ko) oder „Treiber“, die tatsächlich die Arbeit von erledigen iptables, sie sind Teil desNetfilter-Framework. Wenn Sie Befehle ausführen, /sbin/iptablesverwenden Sie die Userland-Komponente, die wiederum mit den Netfilter-Modulen kommuniziert, die in den Kernel geladen werden. Dies ermöglicht eine Trennung, sodass Benutzercode nicht versehentlich vom Kernel ausgeführt werden kann.
Antwort4
In Unix/Linux-Betriebssystemen unterscheiden wir zwischenBenutzerbereichUndKernelspeicher. Das sind lediglich Synonyme für Userland und wo der Kernel hingehört.
Man kann es sich folgendermaßen vorstellen. Man kann mit allem interagieren, was im Userspace passiert. Das ist im Kernelspace nicht der Fall. Daemons, Bibliotheken und Anwendungen gehören zum Userspace. Der gesamte Code, der außerhalb des Kernels des Betriebssystems läuft, gehört zum Userspace (Userland).
Der Kernel-Speicherplatz ist der Ort, an dem der Kernel selbst ausgeführt wird. Es handelt sich um einen eingeschränkten Bereich, auf den nicht einmal Root Zugriff hat. Der Root-Benutzer kann jedoch einige Kernel-Parameter über eine vom Kernel bereitgestellte Schnittstelle (procfs, sysfs) manipulieren.
Der Systemspeicher ist ein gutes Beispiel, um den Unterschied zwischen Kernel- und Benutzerspeicher zu erklären. Ein Daemon (der im Benutzerspeicher ausgeführt wird) benötigt Speicher, um ausgeführt zu werden. Der Kernel verwaltet den gesamten verfügbaren Speicher. Der Daemon erhält vom Kernel „virtuellen Speicher“, wobei der Daemon nicht weiß, ob es sich um physischen Speicher, Swap-Speicher oder etwas anderes handelt. Der Kernel bestimmt, welche Art von Speicher der Prozess erhält. Denn die Speicherverwaltung erfolgt im Kernelspeicher. Andere Dinge, die im Kernelspeicher stattfinden, sind Prozessplanung, Kommunikation zwischen Prozessen, Speicherschutz und -verwaltung, Systemaufrufe ...
Was genau ist Userland?
Userland ist also das, was der Daemon tut (oder tun kann), wenn er mit den Ressourcen des Betriebssystems interagiert (E/A, Netzwerk, Speicher, CPU-Zeit). Diese Ressourcen sind im Kernelbereich vor dem Prozess verborgen.
Die kurze Antwort:
Es ist das, was für den Piloten das Cockpit eines Flugzeugs ist.