Thema: Allgemeiner Ressourcen-Allocator

[kevin]

Eine richtige IOMMU ist natürlich auch was feines, kostet aber dann tatsächlich etwas Performance. Das Problem ist das diese IOMMU ja eigentlich sehr viele verschiedene Kontexte parallel beherrschen muss (für jedes Peripherie-Gerät einen eigenen) um auch wirklich die gewünschte Flexibilität zu erreichen und dafür ist dann wieder einiges an Speicher erforderlich (zusätzlich müssen diese Paging-Tables gepflegt werden). Wimre war die ursprüngliche Idee hinter der IOMMU die Benutzung von echten HW-Komponenten direkt aus einer VM heraus ohne dass das darin laufende OS (und auch die HW) überhaupt wissen muss das es in einer VM läuft.

Usermode und VM sind ja prinzipiell erstmal keine so großartig unterschiedlichen Konzepte.

[erik.vikinger]

Hallo,

Usermode und VM sind ja prinzipiell erstmal keine so großartig unterschiedlichen Konzepte.

Das ist richtig (ist sogar fast das selbe), aber VMs hat man für gewöhnlich nur wenige aber User-Mode-Prozesse sind normalerweise ne ganze Menge vorhanden und wenn man ein Gerät in die VM holen will dann ist das eine recht statische Angelegenheit aber wenn man per IOMMU kontrollieren will welche HW-Komponente in welchen User-Space-Adressraum greifen darf dann ist das eine sehr dynamische Angelegenheit. Ich will damit zum Ausdruck bringen das eine IOMMU zwar prinzipiell für die Absicherung des physischen Speichers funktioniert aber das dem möglicherweise erhebliche praktische Probleme im Wege stehen (um das beurteilen zu können müsste man sich erst mal die Spezifikationen genau durchlesen).


Grüße
Erik

[kevin]

Ich glaube, wenn man nicht nur die Hardwareseite, sondern auch die Software auf die Praxis beschränkt, dass es dann wieder recht statisch ist: Es kommen und gehen ein Haufen Prozesse, die aber allesamt überhaupt keinen Zugriff auf Hardware haben. Treiber werden in der Regel genau einmal gestartet und laufen dann, bis der Rechner ausgeschaltet wird.

Aber Details habe ich mir natürlich auch noch nicht angeschaut.

[erik.vikinger]

Hallo,

Es kommen und gehen ein Haufen Prozesse, die aber allesamt überhaupt keinen Zugriff auf Hardware haben.

Aber die Hardware benötigt Zugriff auf deren Adressräume, oder willst Du immer kopieren? Genau das meinte ich mit dynamisch. Jedes mal wenn irgendein Prozess eine Datei oder Socket oder was anderes lesen/schreiben will dann muss kurz dieser entsprechende Abschnitt für die jeweilige HW-Komponente freigeschaltet werden und danach wieder gesperrt werden. Besonders lustig wird es wenn in einem Prozess 2 verschiedene unausgerichtete Puffer sich eine Page teilen und der Prozess damit 2 unterschiedliche Vorgänge über unterschiedliche (oder noch schlimmer die selbe) HW-Komponenten durchführen möchte.

Ansonsten hast du natürlich Recht.


Grüße
Erik

[kevin]

Hm, stimmt, bei einer VM muss man wohl nur den physischen Speicher des Gasts mappen und der bleibt über die Dauer unverändert. Ist die Frage, wie teuer es ist, wenn ein Treiber vor jedem DMA-Vorgang erstmal die passenden Rechte beantragen müsste, damit die IOMMU entsprechend aufgesetzt wird.

[erik.vikinger]

Hallo,

Ist die Frage, wie teuer es ist, wenn ein Treiber vor jedem DMA-Vorgang erstmal die passenden Rechte beantragen müsste, damit die IOMMU entsprechend aufgesetzt wird.

Ich denke es ist eh ein Syscall erforderlich damit der Treiber überhaupt die physischen Pages, zu dem virtuellem Speicher den er (oder sein Client) hat, erfährt (und diese physischen Pages gesperrt werden). In diesem Syscall könnte der Kernel auch gleich noch die IOMMU managen. Nachdem die HW fertig ist muss der Treiber auch wieder die physischen Pages entsperren und da könnte der Kernel das zugehörige IOMMU-Mapping auch wieder entfernen. Ich denke das man dafür insgesamt kaum (oder gar keine) Änderungen in den Treibern machen müsste. Die Frage ist wie Aufwändig das Management der IOMMU ist.

Wenn der Kernel den virtuellen Adressraum für die HW geschickt nutzt dann könnte er auch in diesem immer nur die aktuell benötigten Mappings eintragen und käme mit einem einzigen Kontext aus. Weil diese Mappings dann am besten jeweils an einem Stück sind hätte die HW weniger mit Scatter/Gather zu tun und die Treiber müssten nicht riesige Listen mit physischen Pages bekommen. Nachteil ist das wenn es nur einen virtuellen HW-Adressraum gibt das dann jede HW an alle aktuell erreichbaren Speicherbereiche ran kommt und nicht nur dahin was die jeweilige HW auch wirklich benötigt, aber zumindest nicht an die Bereiche die keiner freigegeben hat und damit ist das immer noch ein erheblicher Fortschritt.


Grüße
Erik

[Svenska]

Hallo,

Trotzdem bin ich nicht der Meinung das man Funktionalität nur für ein "einheitliches Interface" in den Kernel verschieben muss, sowas geht doch auch anders.

Richtig. Wenn dieses Interface aber den Hardwaretreibern die Arbeit erledigen soll oder ohnehin universell ist (WLAN, TCP/IP), dann ist es meiner Meinung nach im Kernel gut aufgehoben. Oder in einer zum Kernel gehörenden Library. Das sind immer Einzelfallentscheidungen. Tut man es nicht, implementiert man in den Hardwaretreibern die Funktionalität mehrfach.

Aber insbesondere bei Grafiktreibern sollte die Implementation aus Geschwindigkeitsgründen im Kernel selbst stattfinden

Warum "sollte"? Sollte man nicht lieber ordentliches und schnelles IPC implementieren? Nur weil MS das nicht hinbekommen hat heißt es nicht dass das nicht geht.

Es ging bei Microsoft nicht (wobei es bei Vista wieder probiert wurde; aber die Systeme selbst sind langsamer, da fällt das evtl. nicht auf), bei Linux hat man sich dazu entschieden, die Grafiktreiber in den Kernel zu ziehen und FreeBSD hat sogar Geldmittel dafür in Aussicht gestellt.

Das sind aber alles (teil-)monolithische Designs. Bei einem Mikrokernel hast du ohnehin Leistungsverlust für Syscalls, sodaß das IPC viel mehr optimiert sein muss. Da fällt das mit der Grafikkarte nicht mehr ins Gewicht.

Ganz simpel wäre die Lösung, dass ein Prozess nach jedem Syscall seine Zeitscheibe verliert.

Ich schließe mich hierzu taljeth's Meinung an, das wäre definitiv zu simpel.

Die Zahl Eins ist an der Stelle ist willkürlich (und langsam). Du kannst da ja ein dynamisches Limit angeben, um den Missbrauch von Syscalls für DoS zu verhindern.

Du kannst den Port ja zeitweise sperren, das kann die Applikation selbst tun ("ich weiß, dass ich hier keine Syscalls machen werde, also verbiete ich mir das selbst").

Also für Syscalls erscheint mir so ein (selbst auferlegtes) Verbot nicht geeignet, dann könnte das Programm ja nicht mal mehr ein Error-Log führen oder Speicher anfordern oder andere ganz banale Dinge erledigen. Wenn dann muss man sowas schon etwas feiner unterteilen (z.B. keine Netzwerk-Kommunikation also TCP/UDP/usw.).

Auch wieder wahr. Wenn man aber für die verschiedenen Dinge verschiedene Ports hat, dann wird das wieder möglich.

Ist genau das gleiche, wie wenn Anwendungen als root gestartet werden, ein Socket öffnen, und dann als User "nobody" weiterlaufen (Apache).

Das funktioniert aber nur weil auch der User "nobody" immer noch verschiedene Dinge machen darf.

Im Optimalfall die Notwendigen und kein bisschen mehr.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Tut man es nicht, implementiert man in den Hardwaretreibern die Funktionalität mehrfach.

Das ist ganz klar Quatsch. Jede Funktionalität sollte immer nur genau ein mal Implementiert sein.

Das sind aber alles (teil-)monolithische Designs.

Ganz recht. Keines der von Dir genannten OSe würde ich als Micro-Kernel bezeichnen, noch nicht mal als etwas Micro-Kernelig.

Bei einem Mikrokernel hast du ohnehin Leistungsverlust für Syscalls

Das halte ich für eine unbewiesene Behauptung.

Du kannst da ja ein dynamisches Limit angeben, um den Missbrauch von Syscalls für DoS zu verhindern.

Wie sollte man den sowas implementieren? Stell Dir mal grep vor, wenn die Dateien überwiegend klein sind dürfte die meiste CPU-Zeit für Syscalls drauf gehen.

Wenn man aber für die verschiedenen Dinge verschiedene Ports hat, dann wird das wieder möglich.

Hm, damit lagert man aber die Zugriffskontrolle dann doch auf die einzelnen Services aus. Ich denke da reicht es schon wenn die Services sich um die Dinge kümmern die eben spezifisch für diesen Service sind, noch ganz allgemeine Dinge da mit reinnehmen zu wollen finde ich irgendwie ungeschickt.


Grüße
Erik

[Svenska]

Hallo,

Tut man es nicht, implementiert man in den Hardwaretreibern die Funktionalität mehrfach.

Das ist ganz klar Quatsch. Jede Funktionalität sollte immer nur genau ein mal Implementiert sein.

Sollte sie. Ist sie aber im Falle von WLAN nicht. Darum gibt es nach wie vor Linux-WLAN-Treiber (z.B. "acx"), die kein WPA oder HostAP unterstützen - weil sie aus der Zeit vor dem "mac80211"-Stack sind. Unter XP ist die Situation ähnlich, dort weiß ich es von einer frühen RTL8180, die kein WPA kann.

Etwas nicht-hardwarespezifisches, was mehrere Treiber benutzen können bzw. was die Basis von Treibern ist, gehört zum Kernel dazu. Nicht unbedingt in den gleichen Adressraum, aber so ziemlich untrennbar. So zumindest meine Meinung.

Das sind aber alles (teil-)monolithische Designs.

Ganz recht. Keines der von Dir genannten OSe würde ich als Micro-Kernel bezeichnen, noch nicht mal als etwas Micro-Kernelig.

Naja, Windows NT ist als Mikrokernel entstanden, bricht aber aus Performancegründen teilweise aus diesem Konzept aus, darum Makrokernel. Das Grundprinzip ist trotzdem ein Mikrokernel.

Bei einem Mikrokernel hast du ohnehin Leistungsverlust für Syscalls

Das halte ich für eine unbewiesene Behauptung.

Wenn ein Syscall durch IPC hindurch mit Services über ein spezifiziertes Protokoll reden muss, dann ist das langsamer, als einfach eine Funktion aufzurufen. Sieh es als unbewiesen an, aber gib mir dann einen Grund an, warum sich monolithische Designs durchgesetzt haben. (Gut, inzwischen findet ein Umdenken statt. Aber die Rechner sind um viele Größenordnungen schneller und Sicherheit wandert in die Köpfe von Designern und Programmierern.)

Gruß,
Svenska

[erik.vikinger]

Hallo,

Etwas nicht-hardwarespezifisches, was mehrere Treiber benutzen können bzw. was die Basis von Treibern ist, gehört zum Kernel dazu. Nicht unbedingt in den gleichen Adressraum, aber so ziemlich untrennbar. So zumindest meine Meinung.

Dieser Meinung kann ich mich ruhigen Gewissens anschließen.

Naja, Windows NT ist als Mikrokernel entstanden, bricht aber aus Performancegründen teilweise aus diesem Konzept aus, darum Makrokernel. Das Grundprinzip ist trotzdem ein Mikrokernel.

Auf Windows 2k/XP trifft das IMHO aber nicht mehr zu. Ich hab dafür mal einen Ethernet-NIC-Treiber geschrieben und der lieft ganz eindeutig in Ring 0 im Kernel-Adressraum (oberhalb 0xC0000000). In meinen Augen ist Windows ein modularer Monolith der in der Lage ist bestimmte Executables (eigentlich ganz normale PE-EXEs nur mit nem extra Flag) zur Laufzeit in seinen Adressraum zu laden.

aber gib mir dann einen Grund an, warum sich monolithische Designs durchgesetzt haben.

Die sind leichter zu programmieren, man kommt damit schneller zum Erfolg. Ja die dunkle Seite der OS-Entwicklerei ist schon ziemlich verführerisch.

(Gut, inzwischen findet ein Umdenken statt. Aber die Rechner sind um viele Größenordnungen schneller und Sicherheit wandert in die Köpfe von Designern und Programmierern.)

Ja, endlich.


Ich hab nochmal ein wenig über eine IOMMU nachgedacht, sowas ist auf jeden Fall ein sehr verlockendes Feature (auch wenn es für die Peripherie-Zugriffe auf den Haupt-Speicher ein klein wenig Performance kostet was aber bei PCIe mit möglichst großen Payloads in Grenzen gehalten werden kann). Ich denke ich werde es als erstes mit ner Black-List probieren und danach (wenn ich Zeit und Lust hab) mal probieren eine IOMMU zu implementieren, wen man das geschickt macht könnte man den Treibern beim festlocken von physischen Speicher immer nur eine HW-virtuelle Adresse geben weil der Kernel den angeforderten physischen Bereich immer in einem zusammenhängenden Bereich in den HW-virtuellen Adressraum legt. Mal sehen wie viel Aufwand das für den Kernel bedeutet und wie viel Aufwand das im Treiber spart. Ein weiterer Vorteil ist das somit der Treiber niemals echte physische Adressen zu sehen bekommt.


Grüße
Erik