Thema: GUI LowLevel

[TheThing]

Ich sehe den Thread gerade eben erst, und möchte nochmal bei den Shadern einhaken.
Ich weiß jetzt nicht, wie das bei D3D aussieht, aber GLSL-Shader können nicht einfach auf irgendwelchen RAM zugreifen.
Ein Beispiel: http://pastebin.de/21920
Der Shader bekommt seine Daten entweder aus Buffern, die vorher von der Anwendung (und dadurch vom Treiber) an die "in-Variablen" gebunden werden (die bekommt der Shader per Vertex) oder per uniform (Daten per Render-Call). Das Weiterreichen von Daten innerhalb der Shader erfolgt mit out/in, die Ausgabe kommt per out entweder in den Framebuffer oder in Multiple-Render-Targets (muss vorher von der Software gebunden werden).
So etwas wie Pointer o.Ä. kennt die Sprache gar nicht, der Zugriff auf Daten erfolgt in einem sehr engen Rahmen.
Von daher scheinen mir diese Entrüstungen, die es über WebGL und Shader gab, ziemlich übertrieben.

[Dimension]

Bei VirtualBox sind die Extensions für 3D-Hardware-Beschleunigung standardmäßig deaktiviert.

Wenn ich das richtig sehe, bedeutet die Ausführung von Shader-Code auf der GPU dort eine Verletzung des Sandbox-Prinzips. Auch bin ich mir nicht ganz sicher ob Grafiktreiber im Allgemeinen Vorkehrungen gegen Schadcode getroffen haben.

Bezüglich DMA ging ich bisher davon aus, dass bestimmte Bereiche im RAM gemappt werden. Falls das zutrifft könnte man Speicherschutz mit Segmenten erreichen. Abgesehen davon bin ich nicht sehr glücklich darüber, dass die Ingenieure von PC-Hardware davon auszugehen scheinen, dass Bedrohungen für ein System ausschließlich durch Software bestehen und folglich den Hardware-Komponenten eines Systems bedingungslos vertrauen.

[erik.vikinger]

Hallo,


das Problem sind nicht die Programme in den High-Level-Shader-Sprachen die für generische abstrakte Shader entwickelt werden sondern der fertig kompilierte Objekt-Code der von den realen Shadern ausgeführt wird. Dort gibt es meines Wissen nach echte 64Bit-Pointer in den modernen Shadern (sowohl bei AMD, NVidea als auch bei Intel). Die GPUs haben auch eine Art MMU, mit der ganz gewöhnliches Paging gemacht wird, damit die Texturen und sonstigen Daten die ja verstreut im physischen RAM liegen zusammenhängend benutzt werden können, die GPUs haben quasi eine eigene virtualisierte Sicht auf den RAM. Deswegen macht es auch theoretisch nichts aus ob Texturen u.ä. wirklich im lokalen GPU-RAM oder nur im normalen Haupt-RAM liegen, von der Performance mal abgesehen. In den Treibern wird wohl keine Sicherheitsüberprüfung des Shader-Objekt-Code stattfinden, dazu müsste dort eine recht umfangreiche Code- und Daten-Flussanalyse durchgeführt werden um feststellen zu können ob irgend ein Pointer nicht doch mal auf Speicherbereiche zeigt die eigentlich nicht gewünscht sind. Spätestens wenn die Shader-Programme in der Lage sind Texturen u.ä. zur Laufzeit von der SW flexibel zur Verfügung gestellt zu bekommen ist auch das nicht mehr sinnvoll möglich.
Es gibt also sehr viele Punkte an denen man ansetzen könnte um mit Hilfe der GPU den normalen RAM zu manipulieren, z.B. einfach nur das GPU-Paging zu verbiegen um anderen physischen Speicher anzusprechen. Ich wette hier stecken die Viren-Programmierer noch in der sehr frühen Konzeptionierungsphase, aber sollte WebGL wirklich so kommen wie derzeit beabsichtigt dann dürfte das ein neues lukratives und sicher auch interessantes Betätigungsfeld für die Viren-Programmierer und deren Kontrahenten bei den AV-SW-Herstellern werden. Ich gehe davon aus das die Einführung von WebGL in erster Linie der Aufrechterhaltung der Einnahmequellen der AV-SW-Hersteller dient.

Bezüglich DMA ging ich bisher davon aus, dass bestimmte Bereiche im RAM gemappt werden.

Wie bzw. durch welche HW-Komponente soll das den passieren? Ohne eine IOMMU hat jede busmasterfähige HW vollen Zugriff auf den gesamten physischen Adressraum, sogar auf andere HW-Komponenten (falls der Chipsatz das unterstützt, in der PCI-Spec steht dazu "implementierungsspezifisch"). Das trifft übrigens nicht nur auf PCI und seine Erben zu sondern gilt auch für EISA, VLB u.a.m. Das einzigste was wirklich hilft ist eine gute IOMMU die direkt im Chipsatz steckt und jeden Zugriff der von der Peripherie-HW kommt filtert und nur vom OS-Kernel kontrolliert wird.

Falls das zutrifft könnte man Speicherschutz mit Segmenten erreichen.

Sowas traust Du Dich vorzuschlagen? Respekt! Die bösen Segmente will doch heute niemand mehr haben. Die waren schließlich zu DOS-Zeiten ein Quell grenzenloser Freude.

Abgesehen davon bin ich nicht sehr glücklich darüber, dass die Ingenieure von PC-Hardware davon auszugehen scheinen, dass Bedrohungen für ein System ausschließlich durch Software bestehen und folglich den Hardware-Komponenten eines Systems bedingungslos vertrauen.

Willkommen in der Realität! Dieses bedingungslose Vertrauen erstreckt sich übrigens auch auf die Treiber, mit der passenden Konfiguration kann jede busmasterfähige HW eine echte Bedrohung werden (falls dem nicht eine IOMMU Einhalt gebietet, aber die wird vom OS-Kernel sicher auch nur anhand der Wünsche der potentiell fehlerhaften Treiber konfiguriert, wenn Du Dir jetzt mal mein IPC-Konzept anschaust wirst Du vielleicht feststellen das Segmente hier einiges zu bieten haben). Wenn Du die Bedrohungen durch Firewire kennst und Dir überlegst was ein vollwertiger PCI-Express-Link nach draußen erst alles anstellen kann dann dürfte es Dir sicher auch schwer fallen die Idee von Thunderbolt zu verstehen.


Grüße
Erik

[TheThing]

Du sprichst also vom fertigen Code, der dann auf der GPU läuft? An den komme ich per WebGL doch gar nicht ran.
Bei normaler Software ist das wieder was anderes, da kam mit OpenGL 4 (.2 ?) gerade die Möglichkeit, die fertigen Shader vom Treiber abzuholen und später wieder zu laden, um zeitaufwändiges neu-kompilieren beim Programmstart zu verhindern

[Dimension]

OT: Gibt es ein standardisiertes Protokoll zur Kommunikation mit OpenGL-Hardware? Wenn ja, würde ich damit irgendwann Grafikprimitive, GUI Komponenten und Desktop beschleunigen. Ansonsten gibt es auch noch Mesa3D.

[erik.vikinger]

Hallo,

Du sprichst also vom fertigen Code, der dann auf der GPU läuft? An den komme ich per WebGL doch gar nicht ran.

Ja. Ist doch egal, es gibt Wege und das reicht. Und wer richtigen Schadcode erstellen will wird sicher nicht den Compiler im Treiber benutzen sondern andere/eigene Wege finden.

Die Hersteller der GPUs sind auf jeden Fall sehr daran interessiert sich von den Wettbewerbern durch spezielle Features abzuheben (was ansich ja auch völlig legitim ist und zu jeder gesunden Marktwirtschaft dazugehört), damit die Programme diese Features aber auch nutzen können müssen sie den genauen Typ der vorhandenen GPU identifizieren können und das wird sicher auch bei WebGL gehen. Damit wird aber auch die Möglichkeit eröffnet GPU-spezifische Shader-Programme zu laden und die dürften im Interesse schneller Start-Zeiten und kurzer Download-Zeiten bereits vorkompiliert sein. Bis hier ist alles so wie von den GPU-Herstellern und von den Anwendungsentwicklern gewünscht nur leider profitieren davon auch die Schadcode-Programmierer, wenn Du da eine gute Idee hast wie die ersten Gruppen trotzdem zu ihren Zielen kommen und gleichzeitig die letzte Gruppe ausgeschlossen wird so wird man Deine Ideen sicher berücksichtigen ansonsten gehe ich davon aus das die WebGL-Designer eben dieses Risiko einfach eingehen werden und die Anwender werden es früher oder später auch müssen wenn sie nicht vom graphischen Schnick-Schnack im Web komplett ausgeschlossen werden wollen.

OT: Gibt es ein standardisiertes Protokoll zur Kommunikation mit OpenGL-Hardware?

Nein. Und es gibt auch keine "OpenGL-Hardware", es gibt höchstens GPUs mit deren Features es möglich ist einen OpenGL-konformen Treiber zu entwickeln. OpenGL beschreibt wimre nur eine High-Level-API (das Interface zwischen Treiber und Applikation) und eben die Funktionalitäten die damit verfügbar gemacht werden sollen.


Grüße
Erik

[erik.vikinger]

Hallo,


ich hab zu dem Thema Busmaster-fähige HW und IOMMU noch ein wenig nachgedacht.
Moderne HW unter stützt ja für gewöhnlich das Scatter/Gather um die Daten, die sich im physischen RAM ja total zerstreut befinden (Paging sei dank), wieder anständig zusammen zu suchen. Wenn sich im Chipsatz immer eine IOMMU befindet dann gibt es doch damit die Möglichkeit das sich die von der HW benötigten Daten wieder linear am Stück in einem zusätzlichen virtuellen Adressraum befinden und somit die Notwendigkeit für Scatter/Gather-Unterstützung in der HW entfällt. Das würde sicher die Entwicklung von Treibern erleichtern, wer das nicht glaubt sollte sich mal die zugehörigen Strukturen in EHCI, xHCI oder AHCI ansehen, und auch die HW etwas weniger komplex machen. Auch die GPUs bräuchten keine eigene MMU mehr da das ja schon alles die IOMMU macht.
Ich hoffe das sich das Konzept von IOMMUs möglichst bald durchsetzt, da ich davon ausgehe das damit einiges für die Computer-Sicherheit getan werden kann.

Hat denn einer von Euch vor die IOMMU in sein OS mit einzubinden?


Grüße
Erik