Speicherschutz für GPUs und GPGPU - Computing notwendig?

[Coda]

- GPU-beschleunigte Webbrowser benötigen dringend präemptives multitasking und Speicherschutz
Wofür denn? Da wird die GPU genau dafür benutzt was sie schon seit immer gut kann. Grafik ausgeben.

- IOMMUs für GPUs sind bereits weit verbreitet
Ja. Und? Das gab's auch schon mit AGP. Ist aber etwas völlig anderes.

Ich kann mir daher nicht vorstellen dass da erst bis zum nächsten WIndows gewartet wird.
WDDM 2.0 wird es vor Windows 8 nicht geben und solange gibt es keinen gemeinsamen virtuellen Speicherraum und Multitasking für die GPU in Windows.

Nochmal: Dafür bracht es Kerneländerungen und sowas einschneidendes kommt nicht mit einem Service Pack. Zudem ist D3D11 nichtmal ein Jahr alt. Der Release-Zyklus ist bisher 3+ Jahre.

---

Split aus Bobcat Core - Ontario APU - Low-Power-CPU (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8414855#post8414855)
-puntarenas

[Partner]

Tun sie nicht.Mit nichts als einer arroganten Urteilsbekundungen auf Argumente zu antworten erachten die meisten Menschen als äußerst takt- und niveaulos. Das sollte eigentlich jedem bereits im Jugendalter geläufig sein. Zumal man schon allein an den letzten zwei Seiten erkennen kann dass dies bei dir scheinbar übliche Methode ist. :rolleyes:

[Coda]

Ich kann nichts dafür, wenn Fakten als Arroganz ausgelegt werden.

http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/pri103_wh06.ppt

Lesen und verstehen. Vor allem Seite 8. Windows Vista/7 sind WDDM 1.x und daran wird sich auch nichts ändern.

[Partner]

Wofür denn? Da wird die GPU genau dafür benutzt was sie schon seit immer gut kann. Grafik ausgeben.Klar, wozu braucht man präemptives Multitasking und Speicherschutz für die CPU? Für Anwendungen und Netzzugriffe wird die CPU genau dafür benutzt was sie schon seit immer gut kann. Irgendwas ausgeben.

Wird echt lustig wenn die ersten Webseitenwürmer Grafikspeicherinhalte ausspionieren (wie z.B. geöffnete Fenster/Tabs oder sogar bereits geschlossene).

Ja. Und? Das gab's auch schon mit AGP. Ist aber etwas völlig anderes.Hä? Wie kann man den Fakt dass heute massenweise IOMMUs in GPUs verbaut werden müssen nicht als einen Bedarfsgrund für virtualisierten Grafikspeicher ansehen?!

WDDM 2.0 wird es vor Windows 8 nicht geben und solange gibt es keinen gemeinsamen virtuellen Speicherraum und Multitasking für die GPU in Windows.

Nochmal: Dafür bracht es Kerneländerungen und sowas einschneidendes kommt nicht mit einem Service Pack. Zudem ist D3D11 nichtmal ein Jahr alt. Der Release-Zyklus ist bisher 3+ Jahre.Kerneländerungen sind üblich für Servicepacks und sogar bei normalen Updates. Gutes Beispiel ist die Aktualisierung von WDDM auf Version 1.1 bei Vista. NA HOPLA!


Ich kann nichts dafür, wenn Fakten als Arroganz ausgelegt werden.Das du eine deiner Urteilsbekundungen nachträglich editierst spielt da welche Rolle?

http://download.microsoft.com/downlo...ri103_wh06.ppt

Lesen und verstehen. Vor allem Seite 8. Windows Vista/7 sind WDDM 1.x und daran wird sich auch nichts ändern.Zunächst sollte man festhalten dass diese WinHEC2006-Präsentation völlig überholt ist. Was das auch so mit einem Argument zu tun haben soll kannst nur du nachvollziehen.

PS.: Übrigens ist die Behauptung einer Veröffentlichungsfrequenz von "3+ Jahre" wohl kaum als Argument nachvollziehbar.

[Gipsel]

Klar, wozu braucht man präemptives Multitasking und Speicherschutz für die CPU? Für Anwendungen und Netzzugriffe wird die CPU genau dafür benutzt was sie schon seit immer gut kann. Irgendwas ausgeben.Das ist kein hinkender Vergleich, der hat gar keine Beine!
Wird echt lustig wenn die ersten Webseitenwürmer Grafikspeicherinhalte ausspionieren (wie z.B. geöffnete Fenster/Tabs oder sogar bereits geschlossene).Und was hindert irgendwen jetzt daran, z.B. den Framebuffer auszulesen? Den Zugriff auf die privaten Daten in einem anderen Kontext ist übrigens auch schon heute gar nicht soo einfach. Kannst es ja mal versuchen.

Also im Prinzip forderst Du die Verhinderung der Möglichkeit Screenshots zu machen. Auf was anderes läuft das doch nicht hinaus. Du weißt aber schon, daß jetzt das auch schon geht (was will ein Wurm denn damit anfangen?) und sich durch GPU-beschleunigte Browser sich da überhaupt nichts ändert, oder?

[davidzo]

prinzipiell ist es gar nicht so schwierig mithilfe von html5 und javascript die rechner der clients(besucher) als farmen für seine eigenen computingaufgaben zu benutzen. wäre doch n gutes konzept, man bräuchte nur so eine art verteiltes tracking wie bei bittorrent und dann fangen die rechner an ihre Work units im browser zu berechnen, während sie per ajax mit dem webserver weiter kommunizieren.

Die zustandekommende rechenleistung wird als clouddienst vermietet und mit dem verdienst daraus bucht man wieder den adspace den man braucht um die rechenleistung der clients über den browser auszunutzen. in der freizeit kann man dann an social not working seiten arbeiten die noch mehr anreiz und traffic generieren. ab einer bestimmten Größe sollte der rechenleistungsertrag die kosten des adspaces weit überschreiten.

ist zwar ein verdammt ineffizientes konzept, aber mit so 50.000 studiVZ nutzern hat man echt schon keine schlechte serverfarm :biggrin:

[Gipsel]

prinzipiell ist es gar nicht so schwierig mithilfe von html5 und javascript die rechner der clients(besucher) als farmen für seine eigenen computingaufgaben zu benutzen. [..]Das wäre dann aber eine normale Verwendung und kein Wurm oder ähnliches, wie von Partner befürchtet ;)

[Partner]

Das ist kein hinkender Vergleich, der hat gar keine Beine!Und was ist daran bitte so anders?

Und was hindert irgendwen jetzt daran, z.B. den Framebuffer auszulesen?Der ist ja meist weniger interessant als was sonst so im Speicher schlummert und GDI ist eben ein heftiges Nadelöhr im Gegensatz zu den APIs die jetzt genutzt werden sollen.

Den Zugriff auf die privaten Daten in einem anderen Kontext ist übrigens auch schon heute gar nicht soo einfach. Kannst es ja mal versuchen.Was ich so alles bei irgendwelchen Entwicklungsfehlern für Grafikspeicherinhalte sehe, ohne dass da irgend ein protection fault geworfen wird, zeigt meiner Meinung nach dass dies nicht so schwer sein kann.

Also ich würde eine Wette eingehend dass dies die offensichtlichste Knalltüte für die nächste Zeit sein wird.


Meiner Meingung nach kann man es sich nicht leisten für die mehreren Problem die ich genannt habe noch zwei oder gar mehr Jahre zu warten.
Übrigens ist es interessant dass ATI damals für ich glaube R600 angeblich bereits präemptives tasking implementiert hatte und sie sich dann natürlich richtig freuten als MS den Plan für WDDM 2. vorerst verwarf.

[Coda]

Klar, wozu braucht man präemptives Multitasking und Speicherschutz für die CPU? Für Anwendungen und Netzzugriffe wird die CPU genau dafür benutzt was sie schon seit immer gut kann. Irgendwas ausgeben.

Wird echt lustig wenn die ersten Webseitenwürmer Grafikspeicherinhalte ausspionieren (wie z.B. geöffnete Fenster/Tabs oder sogar bereits geschlossene).
Auf den VRAM kann man in einem Protected Mode OS natürlich nur über den Treiber zugreifen und damit bekommen die Prozesse auch nur ihre Daten. Außer man installiert einen Hook. Dann hat der Angreifer aber ohnehin Adminrechte und hat verloren.

Expliziten Speicherschutz mit Page-Tables braucht man erst wenn man die Speicherräume wirklich zusammenlegt. Überhaupt wirkt das Argument sehr an den Haaren herbeigezogen. Es ist nicht so als das das irgend eine Bedrohungslage wäre wegen der man jetzt unbedingt Windows 7 per Service Pack mit WDDM 2.0 versehen müsste. Won't happen.

Kerneländerungen sind üblich für Servicepacks und sogar bei normalen Updates. Gutes Beispiel ist die Aktualisierung von WDDM auf Version 1.1 bei Vista. NA HOPLA!
Vista hat kein WDDM 1.1, auch nicht mit SP2. Da gibt's nur auf Windows 7. Und nein, das ist überhaupt nicht üblich. Service Packs sind für Bug Fixes da.

Zunächst sollte man festhalten dass diese WinHEC2006-Präsentation völlig überholt ist. Was das auch so mit einem Argument zu tun haben soll kannst nur du nachvollziehen.
Da ist überhaupt nichts überholt. WDDM 1.0 und 1.1 bieten die in der Tabelle aufgeführten Eigenschaften und nichts was für WDDM 2.0 geplant ist.

Vielleicht solltest du einfach mal etwas akzeptieren was völlig offensichtlich ist anstatt hier dauernd einen auf Crank zu machen in einem unglaublich asozialen Ton.

Übrigens ist die Behauptung einer Veröffentlichungsfrequenz von "3+ Jahre" wohl kaum als Argument nachvollziehbar.
Ist es wenn man sich mit dem Prozess auskennt schon. Die GPU-Entwickler müssen auch erstmal planen. Wenn überhaupt, dann kommt erstmal ein Minor Upgrade 11.1 auf WDDM-1.x-Basis, aber selbst danach sieht es nicht aus.

[Gipsel]

Und was ist daran bitte so anders?Wie Coda schon sagte, bei der Browserbeschleunigung per GPU macht die ja im Prinzip nichts anderes als die Ausgabe der Grafik (nix mit GPGPU). Da gibt es selten sensible Daten, an die man nicht auch mit einem Screenshot kommt.
Der ist ja meist weniger interessantSiehst Du! als was sonst so im Speicher schlummertWas da wäre?
Also ich würde eine Wette eingehend dass dies die offensichtlichste Knalltüte für die nächste Zeit sein wird.Sicherheitslücken bei Browserbeschleunigung durch GPU (die nicht auf Treiberbugs zurückzuführen sind)? Die Wette halte ich. Die Zugriffe laufen ja, wie Coda richtig anmerkte, über den Treiber, der zum einen recht gut vom Nutzercode gekapselt ist und dem zum anderen auch alle Schutzmaßnahmen der CPU zur Verfügung stehen.
Übrigens ist es interessant dass ATI damals für ich glaube R600 angeblich bereits präemptives tasking implementiert hatte und sie sich dann natürlich richtig freuten als MS den Plan für WDDM 2. vorerst verwarf.
Stimmt nicht. Das war vielleicht mal für RV770 oder Evergreen geplant und wurde jetzt noch mehr nach hinten geschoben (Cayman hat vielleicht den Anfang eines Supports), aber R600 kann definitiv kein präemptives Multitasking. Auch Fermi kann es nicht.

[Trap]

Auf der anderen Seite frage ich mich wieder was die fast schon überdimensionierte GPU in einem Low-Power-Prozessor soll.
Sie soll einen Markt für GPGPU-beschleunigte Software schaffen.

Außerdem kann man damit WoW und Sims spielen (zusammen 15 Mio Käufer), das sind wichtige Marketingmöglichkeiten für ein günstiges Notebook.

[Partner]

Auf den VRAM kann man in einem Protected Mode OS natürlich nur über den Treiber zugreifen und damit bekommen die Prozesse auch nur ihre Daten. Außer man installiert einen Hook. Dann hat der Angreifer aber ohnehin Adminrechte und hat verloren.

Expliziten Speicherschutz mit Page-Tables braucht man erst wenn man die Speicherräume wirklich zusammenlegt. Überhaupt wirkt das Argument sehr an den Haaren herbeigezogen. Es ist nicht so als das das irgend eine Bedrohungslage wäre wegen der man jetzt unbedingt Windows 7 per Service Pack mit WDDM 2.0 versehen müsste. Won't happen.Wie "nur über den Treiber zugreifen"? Mit dem gleichen Argument könnte man sagen es gäbe keine Sicherheitsbedenken beim OS, weil man "nur über den Kernel zugreifen" kann.

Vista hat kein WDDM 1.1, auch nicht mit SP2. Da gibt's nur auf Windows 7. Und nein, das ist überhaupt nicht üblich. Service Packs sind für Bug Fixes da.WDDM 1.1 wurde für Vista mit dem platform update geliefert. Kannst das gerne bei MSDN nachprüfen.
Es werden sehr oft Änderungen am Kernel mit Updates vorgenommen.

Da ist überhaupt nichts überholt. WDDM 1.0 und 1.1 bieten die in der Tabelle aufgeführten Eigenschaften und nichts was für WDDM 2.0 geplant ist.Ja und?

Vielleicht solltest du einfach mal etwas akzeptieren was völlig offensichtlich ist anstatt hier dauernd einen auf Crank zu machen in einem unglaublich asozialen Ton.Du bist derjenige der ständig auf Argumentationen anderer mit Pauschalurteilen antwortet, und du kannst es scheinbar einfach nicht verkraften dass du, wie jeder andere auch, bei manchen Dingen einfach falsch liegst.

Wenn du an diesem Diskussionsforum nicht teilnehmen willst kannst du dich einfach fernhalten.

Ist es wenn man sich mit dem Prozess auskennt schon. Die GPU-Entwickler müssen auch erstmal planen. Wenn überhaupt, dann kommt erstmal ein Minor Upgrade 11.1 auf WDDM-1.x-Basis, aber selbst danach sieht es nicht aus.OK, wir werden sehen.

[Partner]

Wie Coda schon sagte, bei der Browserbeschleunigung per GPU macht die ja im Prinzip nichts anderes als die Ausgabe der Grafik (nix mit GPGPU). Da gibt es selten sensible Daten, an die man nicht auch mit einem Screenshot kommt.
Siehst Du!Was da wäre?Im Grafikspeicher sind meist sämtliche Oberflächen abgebildet. Dazu kommen noch z.B. I/O Textpuffer von DirectWrite usw. und andere Dinge.
Das sollen keine sensiblen Daten sein?

Sicherheitslücken bei Browserbeschleunigung durch GPU (die nicht auf Treiberbugs zurückzuführen sind)? Die Wette halte ich. Die Zugriffe laufen ja, wie Coda richtig anmerkte, über den Treiber, der zum einen recht gut vom Nutzercode gekapselt ist und dem zum anderen auch alle Schutzmaßnahmen der CPU zur Verfügung stehen.Klar, wenn man OGL/D2D/D3D/OCL/DCompute perfekt kapselt gibt es kein Problem. Nur sind diese APIs und HTML5/Flash/Silverlight einfach mal sehr komplex und daher kann man mit Sicherheit davon ausgehen dass es Lücken gibt.

Wie grotesk das Sicherheitsproblem ist zeigt sich z.B. daran dass man den kompletten Grafiktreiber mit einer zulässigen Zeichenanweisung in die Ewigkeit befördern kann weil einfach keine Kontextwechsel innerhalb einer Anweisung möglich sind. Willkommen zurück in den 90er Jahren!

Stimmt nicht. Das war vielleicht mal für RV770 oder Evergreen geplant und wurde jetzt noch mehr nach hinten geschoben (Cayman hat vielleicht den Anfang eines Supports), aber R600 kann definitiv kein präemptives Multitasking. Auch Fermi kann es nicht.Mir hat ein ATI-Mitarbeiter persönlich erzählt dass für die Produkte zur Vista-Veröffentlichung so etwas wie ein task state segment für präemptives tasking enwickelt wurde.

[Gipsel]

Im Grafikspeicher sind meist sämtliche Oberflächen abgebildet. Dazu kommen noch z.B. I/O Textpuffer von DirectWrite usw. und andere Dinge.
Das sollen keine sensiblen Daten sein?Wie gesagt, eigentlich nichts, woran man nicht im Prinzip auch per Screenshot kommen würde. Und die Textpuffer mitsamt Paßwörtern oder so stehen gewiss nicht im Grafikkartenspeicher, so wie Du Dir das vielleicht vorstellst. Was sollte die GPU denn mit dem Text anfangen? Den kann die doch gar nicht rendern! Das wird natürlich schön von Direct2D aufbereitet (wenn Du DirectWrite mit GDI benutzt, ändert sich sowieso nichts und die GPU ist praktisch unbeteiligt), was im Prinzip einen Vertex-Buffer erzeugt, der dann per D3D(!) gerendert wird. Im GPU-Speicher liegt also ein Vertexbuffer, kein Text (beim DirectWrite-Aufruf sollten da sowieso schon ***** bei Paßwörtern stehen, die lassen sich da also auch nicht draus rekonstruieren).
Klar, wenn man OGL/D2D/D3D/OCL/DCompute perfekt kapselt gibt es kein Problem. Nur sind diese APIs und HTML5/Flash/Silverlight einfach mal sehr komplex und daher kann man mit Sicherheit davon ausgehen dass es Lücken gibt.Wie bei jeder anderen Software auch, die ebenfalls auf der CPU läuft ;)
Ich sehe einfach kein wirkliches Problem, da die sensiblen Daten eigentlich üblicherweise im Hauptspeicher bleiben und nicht im VRAM der GPU. Und selbst wenn, ist es wie gesagt gar nicht so einfach, Daten aus einem fremden Kontext zu lesen. Wenn man einen Puffer alloziert und später darauf zugreift, wird üblicherweise schon überprüft (das macht die GPU in Hardware), ob man sich innerhalb der Grenzen bewegt, die der Puffer groß ist. Zumindest bei Texturen ist es ziemlich unmöglich, auf andere Bereiche zuzugreifen, bei Puffern im globalen Speicher müßte ich es mal ausprobieren.
Wie grotesk das Sicherheitsproblem ist zeigt sich z.B. daran dass man den kompletten Grafiktreiber mit einer zulässigen Zeichenanweisung in die Ewigkeit befördern kann weil einfach keine Kontextwechsel innerhalb einer Anweisung möglich sind.Das ist aber kein Sicherheitsproblem. Mit einem abgestürzten Grafiktreiber erlangt man Zugriff auf was genau? Das bewirkt doch im Prinzip nur, daß man keinen Zugriff mehr auf die GPU hat und auch keine Daten mehr von dort zurückbekommt.
Mir hat ein ATI-Mitarbeiter persönlich erzählt dass für die Produkte zur Vista-Veröffentlichung so etwas wie ein task state segment für präemptives tasking enwickelt wurde.Allein, es ist nicht da (in keiner einzigen Doku oder Präsentation ist irgendwas davon erwähnt, eher das Gegenteil). Mein Stand ist, daß das mal für Vista/Win7 geplant war als auch noch WDDM 2 dafür auf der Roadmap stand, das allerdings nach einigem Widerstand von mindestens einem großen IHV auf sehr viel später verschoben wurde, und demzufolge auch in der Hardware nicht zu finden ist. Meiner Meinung nach macht erst Cayman die ersten Schritte in diese Richtung.
Übrigens zeigt Dein obiges Beispiel mit der Unmöglichkeit des Kontextwechsels innerhalb eines Draw Calls schon die Abwesenheit jeglicher Präemption ;)

[Coda]

Vor allem wird auch page table Speicherschutz nichts daran ändern, dass man auf Windows Screenshots machen kann. Der Zugriff auf den Treiber wird anderen Prozessen ja nur erlaubt, weil es entsprechende APIs gibt.

Unter Windows im Protected Mode kann man den VRAM natürlich nicht beliebig lesen. Nur der Treiber und der Kernel dürfen das und können den Prozessen die Rechte darauf beliebig einteilen.

Das Thema ist sowas von hirnrissig.

Wie "nur über den Treiber zugreifen"? Mit dem gleichen Argument könnte man sagen es gäbe keine Sicherheitsbedenken beim OS, weil man "nur über den Kernel zugreifen" kann.
So wie es dasteht. Die App selber hat keinerlei Zugriffsmöglichkeiten auf die Speicherbereiche ohne eine öffentliche API dafür zu verwenden, die wiederrum den Treiber damit beauftragt die Daten zu kopieren.

Klar, wenn man OGL/D2D/D3D/OCL/DCompute perfekt kapselt gibt es kein Problem. Nur sind diese APIs und HTML5/Flash/Silverlight einfach mal sehr komplex und daher kann man mit Sicherheit davon ausgehen dass es Lücken gibt.
Bitte beschreib doch mal einen Angriffsvektor. Ich kann dir absolut nicht folgen.

Natürlich kann ein User-Space-Programm Sicherheitslücken haben, aber das führt doch noch lange nicht dazu dass der Treiber alle Daten der GPU preisgibt. Man bekommt natürlich Zugriff auf die GPU-Daten der angegriffenen Applikation. Wie auch auf ihren CPU-Speicherbereich.

Wo bitte gibt es da jetzt zusätzliche "Sicherheitslücken"?

Du bist derjenige der ständig auf Argumentationen anderer mit Pauschalurteilen antwortet, und du kannst es scheinbar einfach nicht verkraften dass du, wie jeder andere auch, bei manchen Dingen einfach falsch liegst.
Ich und Gipsel liegen aber nicht falsch. Das ist das Problem an der Sache.

[Gauß]

Das durch die GPU-Nutzung eine weitere, potentielle Schwachstelle hinzukommt, steht fest. Nur wie signifikant ist diese?

Die angenommene Möglichkeit alle Oberflächen auszulesen, währe schon ein ernstzunehmendes Risiko wenn man Bedenkt dass man so leicht eine Übersicht z.B. auf Bankdaten, diverse Kommunikationskonten usw. erlangen könnte.

Dass z.B. bei Silverlight sogar HLSL-Programme erlaubt sind macht meiner Meinung nach deutlich dass es sich eben nicht einfach um eine sehr übersichtliche Schnittstelle zur/zum GPU(-Treiber) handelt, und daher viele Sicherheitslücken denkbar sind. Jeder der mit diversen Shaderbuffer-Typen gearbeitet hat weiß, dass es bisher keinen wirklich wirksamen Speicherschutzmechanismus auf GPUs gibt.

Eigentlich war ja die Frage ob vielleicht schon sehr bald eine moderne Speicher- und Instruktionskontrollarchitektur zwischen OS/ICD und der GPU nötig ist. Das mögliche Sicherheitsproblem ist, so denke ich, da nur eines von vielen Gründen dass dies dringend nötig ist.

[Gipsel]

Die angenommene Möglichkeit alle Oberflächen auszulesen, währe schon ein ernstzunehmendes Risiko wenn man Bedenkt dass man so leicht eine Übersicht z.B. auf Bankdaten, diverse Kommunikationskonten usw. erlangen könnte.Beantworte mir eine Frage: Was gewinnt man eigentlich gegenüber einem Screenshot (oder einer Serie davon)?
Und am besten beschreibst Du auch gleich mal, wie Du auf die Resourcen eines anderen Prozesses zugreifen willst. Geht das wirklich einfacher, nur weil jetzt GPU-Beschleunigung vom Browser benutzt wird?

[davidzo]

lol, die printscreen funktion kann ich auch so hacken ohne in den grafiktreiber einzugreifen und das wäre dann universell nutzbar, nicht nur in 3d beschleunigten programmen.

Man leute, ich denke immer hier schreibt jemand was spannendes, können wir diese offtopic diskussion mal langsam beenden?

[Gauß]

Beantworte mir eine Frage: Was gewinnt man eigentlich gegenüber einem Screenshot (oder einer Serie davon)?Nun weil doch alle Oberflächen im VRAM liegen, also alle Inhalte der Webrowser, Fenster und so.

Und am besten beschreibst Du auch gleich mal, wie Du auf die Resourcen eines anderen Prozesses zugreifen willst. Geht das wirklich einfacher, nur weil jetzt GPU-Beschleunigung vom Browser benutzt wird?Öh ich kann mich erinnern mal über ein rendertarget hinaus gelesen zu haben und da waren Fensterinhalte aus nem anderen Kontext dabei. Am häufigsten sieht man's wenn der Treiber aus der Reihe tanzt, was man ja wirklich problemlos verursachen kann.

Die indirekte und zum Teil sogar direkte Zugriffsmöglichkeit von Web-Dokumenten/Scripts auf die GPU-Treiber wird doch eindeutig ausgeweitet, also steigt auch das Risiko dies auszunutzen. Vertehe echt nicht wieso das nicht einleuchtend ist?


Übrigens, J.Carmack hat doch vor kurzem behauptet dass er sich derzeit aktiv dafür einsetzt das der VRAM alsbald komplett virtualisiert wird.
Naja, es gibt doch nun wirklich einige gute Gründe die Anbindung der GPU zu modernisieren und ich kann mir schon vorstellen dass da auch kurzfristig (ein bis zwei Jahre) was gemacht wird.

[Gauß]

lol, die printscreen funktion kann ich auch so hacken ohne in den grafiktreiber einzugreifenSoso, du willst mir sagen dass du einen kompletten security exploit bei einem modernen OS einfach "auch so hacken" kannst? Oder wie willst du sonst an den framebuffer neben der diskutierten, möglichen Schwachstelle rankommen?

und das wäre dann universell nutzbar, nicht nur in 3d beschleunigten programmen.Heutzutage liegen praktisch alle Fensterinhalte im VRAM. Das ist ja das Problem.

Man leute, ich denke immer hier schreibt jemand was spannendes, können wir diese offtopic diskussion mal langsam beenden?Klar, irgendwelche völlig sinnlosen Spekulationen über mögliche Leistung usw. sind ja so spannend. :rolleyes:

Eine Modernisierung der GPU-Anbindung des OS ist von großer Bedeutung für den Erfolg von APUs. Deswegen wird das auch hier diskutiert.

[davidzo]

Soso, du willst mir sagen dass du einen kompletten security exploit bei einem modernen OS einfach "auch so hacken" kannst? Oder wie willst du sonst an den framebuffer neben der diskutierten, möglichen Schwachstelle rankommen?

hast du nicht gelesen was ich geschrieben habe? Ich muss gar nichts programmieren um den framebuffer im vram auslesen zu können. das ist doch schon builtin in jedem aktuellen desktopOS. alles kann ich auch durch einen simplen druck der print screentaste bekommen. ob ich dazu nun ein virtuelles usbdevice benötige welches den tastendruck auslöst oder einen stick mit microcontroller an den rechner stecke der mir dann auch gleich den inhalt speichert, per rf übermittelt oder was auch immer - an die Zwischenablage kommt jedes programm heran, da hilft auch kein speicherschutz und printscreen funktioniert überall.

[Gauß]

hast du nicht gelesen was ich geschrieben habe? Ich muss gar nichts programmieren um den framebuffer im vram auslesen zu können. das ist doch schon builtin in jedem aktuellen desktopOS. alles kann ich auch durch einen simplen druck der print screentaste bekommen. ob ich dazu nun ein virtuelles usbdevice benötige welches den tastendruck auslöst oder einen stick mit microcontroller an den rechner stecke der mir dann auch gleich den inhalt speichert, per rf übermittelt oder was auch immer - an die Zwischenablage kommt jedes programm heran, da hilft auch kein speicherschutz und printscreen funktioniert überall.Eh... es geht hier um die potentielle Sicherheitsschwachstelle durch die stark zunehmdenen Einflussmöglichkeit von Web-Dokumenten/Scripts auf die GPU(-Treiber). Das man nen screenshot mit der printscreen-Taste machen kann ist vielleicht gerade so für meine Oma überraschend. :wink:

[Coda]

Wie genau hast du denn bitte mit "Web-Dokumenten/Scripts" Zugriff auf das Browser-Rendering? Da sind ja mindestens noch zwei Abstaktionsebenen dazwischen.

[Gipsel]

Nun weil doch alle Oberflächen im VRAM liegen, also alle Inhalte der Webrowser, Fenster und so.Das ist keine Antwort auf meine Frage, was man gegenüber einem Screenshot im richtigen Moment gewinnt.
Öh ich kann mich erinnern mal über ein rendertarget hinaus gelesen zu haben und da waren Fensterinhalte aus nem anderen Kontext dabei. Am häufigsten sieht man's wenn der Treiber aus der Reihe tanzt, was man ja wirklich problemlos verursachen kann.Super, dann hättest Du eine komplizierte Möglichkeit, einen Screenshot zu machen! ;)
Und ich kann mich daran erinnern, bereits geschrieben zu haben, daß eine GPU (zumindest die ATIs machen es) bei Zugriffen auf Texturen (bei Rendertargets aber genauso) die erlaubten Adressen auf die jeweils allozierte Puffergröße beschränken (plus eventuelle Pad-Area, aber da sind auch keine Daten eines anderen Kontextes drin). Wenn das mal nicht klappen sollte (überprüfe das lieber noch mal ;)), ist daran nicht die GPU-Beschleunigung per se oder der "fehlende Speicherschutz" (Partner-Zitat) schuld, sondern ein fehlerhafter Treiber, der das nicht richtig handhabt. Und das ist schlußendlich ein Stück Software, was auf der CPU läuft und natürlich Bugs haben kann, wie jede andere Software auch. Der Speicherschutz der CPUs ist auch nichts wert, falls das OS die Pagetable-Einträge wie Kraut und Rüben setzt.
Die indirekte und zum Teil sogar direkte Zugriffsmöglichkeit von Web-Dokumenten/Scripts auf die GPU-Treiber wird doch eindeutig ausgeweitet, also steigt auch das Risiko dies auszunutzen. Vertehe echt nicht wieso das nicht einleuchtend ist?Ich verstehe echt nicht, wo jetzt groß eine prinzipiell neue Gefahr auftauchen soll. Wie davidzo schon schrieb, so ziemlich jedes OS sieht die Möglichkeit von Screenshots vor. Und das sollte soch erheblich einfacher sein, als nach potentiellen Lücken im Grafiktreiber zu suchen, womit man dann letztendlich auch nicht an mehr rankommt. ;)

[Gauß]

Wie genau hast du denn bitte mit "Web-Dokumenten/Scripts" Zugriff auf das Browser-Rendering? Da sind ja mindestens noch zwei Abstaktionsebenen dazwischen.Was ist da der Unterschied zu anderen, erfolgreichen security exploits?

[Coda]

Bitte erklär doch erstmal nochmal genau was so ein Exploit schlimmeres machen können soll als ein anderer der "normale" Browserbugs ausnutzt.

So ergibt diese Diskussion einfach keinen Sinn.

[Gauß]

Das ist keine Antwort auf meine Frage, was man gegenüber einem Screenshot im richtigen Moment gewinnt.
Super, dann hättest Du eine komplizierte Möglichkeit, einen Screenshot zu machen! ;)
Und ich kann mich daran erinnern, bereits geschrieben zu haben, daß eine GPU (zumindest die ATIs machen es) bei Zugriffen auf Texturen (bei Rendertargets aber genauso) die erlaubten Adressen auf die jeweils allozierte Puffergröße beschränken (plus eventuelle Pad-Area, aber da sind auch keine Daten eines anderen Kontextes drin). Wenn das mal nicht klappen sollte (überprüfe das lieber noch mal ;)), ist daran nicht die GPU-Beschleunigung per se oder der "fehlende Speicherschutz" (Partner-Zitat) schuld, sondern ein fehlerhafter Treiber, der das nicht richtig handhabt. Und das ist schlußendlich ein Stück Software, was auf der CPU läuft und natürlich Bugs haben kann, wie jede andere Software auch. Der Speicherschutz der CPUs ist auch nichts wert, falls das OS die Pagetable-Einträge wie Kraut und Rüben setzt.Deswegen soll ja auch zwischen dem komplexen Treiber und der GPU eine schlanke und damit potentiell sicherere Speicherverwaltung arbeiten. Bisher wird da eben bis auf der API-Ebene nichts gemacht. Und was selbst da nur an Sicherheitsaufwand betrieben wird ist einfach lachhaft und hat eigentlich nur was mit Fehleranalyse zu tun.

Warum sonst wurde das wohl für WDDM2 angekündigt?

Ich verstehe echt nicht, wo jetzt groß eine prinzipiell neue Gefahr auftauchen soll. Wie davidzo schon schrieb, so ziemlich jedes OS sieht die Möglichkeit von Screenshots vor. Und das sollte soch erheblich einfacher sein, als nach potentiellen Lücken im Grafiktreiber zu suchen, womit man dann letztendlich auch nicht an mehr rankommt. ;)Ja wie willst du denn "einfach" einen Screenshot per Web-Dokument/Script machen? Für alles was auf der CPU läuft wird inzwischen ein enormer Sicherheitsaufwand betrieben.

[Gauß]

Bitte erklär doch erstmal nochmal genau was so ein Exploit schlimmeres machen können soll als ein anderer der "normale" Browserbugs ausnutzt.

So ergibt diese Diskussion einfach keinen Sinn.Das Problem ist das für die GPU-Domäne im Gegensatz zur CPU fast garkeine effektiven Sicherheitsmechanismen existieren.

Wie bereits gesagt: warum sonst ist da wohl eine deutliche Verbesserung für WDDM2 geplant?

[Coda]

Das Problem ist das für die GPU-Domäne im Gegensatz zur CPU fast garkeine effektiven Sicherheitsmechanismen existieren.
Natürlich gibt es die. Der Treiber und das Betriebssystem handhaben die komplette Sicherheit in Software.

Das ist heutzutage auch völlig ausreichend. Die GPU macht ja nichts von sich aus, auch kann man nicht über GPU-Programme auf fremde Prozesse zugreifen. Man kann nichtmal in beliebigen Speicherbereichen auf der GPU rumschreiben. Nur in die Buffer die der Prozess vom Treiber kennt.

Die GPU ist dabei als PCIe-Gerät nicht gefährlicher als der SATA-Controller oder die Netzwerkkarte. Die schreiben auch direkt in den RAM.

Warum sonst wurde das wohl für WDDM2 angekündigt?
Weil es homogenes Multiprocessing zwischen GPU und CPU erlaubt so wie heute schon bei CPU/CPU ohne kopieren zu müssen? Inkl. Cache-Kohärenz?

Man kann dann "GPU Threads" direkt auf Programmdaten starten und dabei beispielsweise auch übliche Synchronisierungsmittel wie Mutexes verwenden. PCIe 3.0 hat dafür jetzt schon atomare Transaktionen eingeführt.

Wenn die GPU aber Zugriff auf den physikalischen RAM der CPU hat muss sie auch den Speicherschutz des darauf laufenden Programms berücksichtigen. Das ist derzeit einfach nicht der Fall, weil sie höchstens in den PCIe-Aperture-Speicher schreibt wenn der Treiber das anfordert.

[Gauß]

Weil es homogenes Multiprocessing zwischen GPU und CPU erlaubt so wie heute schon bei CPU/GPU ohne kopieren zu müssen? Inkl. Cache-Kohärenz?

Man kann dann "GPU Threads" direkt auf Programmdaten starten und dabei auch übliche Synchronisierungsmittel wie Mutexes verwenden.

Wenn die GPU aber Zugriff auf den physikalischen RAM der CPU hat muss sie auch den Speicherschutz des darauf laufenden Programms berücksichtigen. Das ist derzeit einfach nicht der Fall, weil sie höchstens in den PCIe-Aperture-Speicher schreibt wenn der Treiber das anfordert.Ja, aber für WDDM2 wurde ein explizites Sicherheitskonzept entwickelt. Das Dinge wie priveligierter Speicher auch andere Vorteile hat, sagt nicht dass nicht aus gutem Grund Wert auf Sicherheit gelegt wurde.

[Coda]

Du hast nichts davon verstanden was ich geschrieben habe, oder?

Es gibt derzeit faktisch keinen Bedarf für Speicherschutz auf der GPU, weil es keinen gemeinsamen Adressraum gibt. Die GPU ist kein gleichwertiger Koprozessor sondern ein Client der CPU und muss sich an die Regeln des Treibers und OS halten. Was ist daran nicht verständlich?

[Gauß]

Du hast nichts davon verstanden was ich geschrieben habe, oder?

Es gibt derzeit faktisch keinen Bedarf für Speicherschutz auf der GPU, weil es keinen gemeinsamen Adressraum gibt. Die GPU ist kein gleichwertiger Koprozessor sondern ein Client der CPU und muss sich an die Regeln des Treibers und OS halten. Was ist daran nicht verständlich?Hä? Es ist/war doch kein gemeinsamer Adressraum für CPU&GPU mit WDDM2 geplant. :confused:

"Was ist daran nicht verständlich" das auch ich der Meinung bin das die Daten im VRAM sensibel sein können? Alle Sicherheitskonzepte von WDDM2 (die ich kenne) sind allein für die GPU-Domäne ausgelegt.

[Coda]

Hä? Es ist/war doch kein gemeinsamer Adressraum für CPU&GPU mit WDDM2 geplant. :confused:
Natürlich. Sonst gibt das ganze Konzept doch gar keinen Sinn.

Mit WDDM2 gibt es dann ja auch Page-Table-Speicherschutz für die GPU. Wo ist denn der Widerspruch?

das auch ich der Meinung bin das die Daten im VRAM sensibel sein können?
Der Zugriff auf diese Daten ist aber ausschließlich über den Treiber und das OS möglich. Der User-Space-Prozess hat direkt keinen Zugriff darauf. Das OS kann also jede nur erdenkliche Zugriffsverwaltung in Software machen.

Alles was derzeit möglich ist, ist GEWOLLT und wird sich mit WDDM 2.0 auch nicht ändern, weil man dafür alte APIs zurückziehen müsste. Klar jetzt?

[Gauß]

Ja. JETZT gibt es aber noch keinen.

Mit WDDM2 gibt es dann ja auch Page-Table-Speicherschutz für die GPU. Wo ist denn der Widerspruch?Ja aben. Mein Punkt war das die Sicherheitsmaßnamen:
- GPU-seitiger Speicherschutz
- preemptive tasking
- priveligierter Speicher

... eben "nur" für die diskutierte Sicherheitlücke auf der GPU-Domäne geplant wird. Ich wollte damit zeigen das dies also offensichtlich ernstgenommen wird.

Der Zugriff auf diese Daten ist aber ausschließlich über den Treiber und das OS möglich. Der User-Space-Prozess hat direkt keinen Zugriff darauf. Das OS kann also jede nur erdenkliche Zugriffsverwaltung in Software machen.

Alles was derzeit möglich ist, ist GEWOLLT und wird sich mit WDDM 2.0 auch nicht ändern, weil man dafür alte APIs zurückziehen müsste. Klar jetzt?Ne. Das macht überhaupt keinen Sinn!
Der Speicherseitenschutz usw. wird nur für das diskutierte Problem implementiert und selbstverständlich werden die alten Treiber für das neue WDDM umgeschrieben und profitieren daher auch davon.

[Gipsel]

die diskutierte Sicherheitlücke auf der GPU-DomäneWelche? Wo diskutiert?
das diskutierte Problem
ebda

[Coda]

Ne. Das macht überhaupt keinen Sinn!
Natürlich ergibt das Sinn. Man kann nicht einfach das Verhalten von System-APIs brechen mit neuen Windows-Versionen.

Der Speicherseitenschutz usw. wird nur für das diskutierte Problem implementiert und selbstverständlich werden die alten Treiber für das neue WDDM umgeschrieben und profitieren daher auch davon.
Das können sie überhaupt nicht, weil heutige GPUs keinen Speicherschutz unterstützen.

[Gauß]

Natürlich ergibt das Sinn. Man kann nicht einfach das Verhalten von System-APIs brechen mit neuen Windows-Versionen.Aber das wird es doch auch nicht. Es ist nur zwingend nötig unterhalb der API Änderungen vorzunehmen. Dass auch die APIs dies mit irgend einer Funktionalität unterstützen, ist doch nur optional.

Das können sie überhaupt nicht, weil heutige GPUs keinen Speicherschutz unterstützen.Stimmt, wie das in Hardware aussieht ist natürlich eine Frage der Gegebenheiten. Nur kann man entweder einen Emulationstreiber verlangen oder es wird halt einfach die spezifische Funktion nicht unterstüzt, eben genauso wie bei DEP und so weiter.

Achso, mir fällt gerade ein dass ich bei irgend einer Präsentation zu CUDA auf der Siggraph gehört habe das Nvidia bei der kommenden Generation virtualisierten Speicher anbieten wird.


Was eigentlich wirklich überfällig ist, ist task preemption. Ich meine es ist doch wirklich lachhaft das alle Welt von GPGPU redet und man sich bei den fundamentalen Grundlagen noch im letzten Jahrhundert befindet.

[Coda]

Aber das wird es doch auch nicht. Es ist nur zwingend nötig unterhalb der API Änderungen vorzunehmen. Dass auch die APIs dies mit irgend einer Funktionalität unterstützen, ist doch nur optional.
Und was sollen die "Änderungen unterhalb der API" dann als Sicherheitsgewinn bringen?

Ich sage es nochmal: Du kannst auch jetzt nicht auf beliebige Daten auf der GPU zugreifen. Man bekommt nur auf das Zugriff was das OS/Treiber einem erlaubt. Schlagt euch das endlich aus dem Kopf.

Stimmt, wie das in Hardware aussieht ist natürlich eine Frage der Gegebenheiten. Nur kann man entweder einen Emulationstreiber verlangen oder es wird halt einfach die spezifische Funktion nicht unterstüzt, eben genauso wie bei DEP und so weiter.
Da kann man nichts emulieren. Page-Tables und die Zugriffsrechte dafür müssen in Hardware gemacht werden. Das muss schließlich bei jedem Speicherzugriff geprüft werden. WDDM 2.0 wird neue GPUs voraussetzen.

Achso, mir fällt gerade ein dass ich bei irgend einer Präsentation zu CUDA auf der Siggraph gehört habe das Nvidia bei der kommenden Generation virtualisierten Speicher anbieten wird.
Das bezweifelt ja auch niemand.

Es geht nur darum, dass das unter Windows Vista/7 nichts bringen wird. Dafür braucht man ein neues Betriebssystem mit WDDM 2.0.

Was eigentlich wirklich überfällig ist, ist task preemption. Ich meine es ist doch wirklich lachhaft das alle Welt von GPGPU redet und man sich bei den fundamentalen Grundlagen noch im letzten Jahrhundert befindet.
Keine Frage. Bezweifel ich auch nicht. Braucht man aber auch HW-Support und WDDM 2.0/2.1 dafür.

[Gauß]

Und was sollen die "Änderungen unterhalb der API" dann als Sicherheitsgewinn bringen?Och nee, jetzt geht das schon wieder los...

Zum letzten mal:
vom Treiber koordinierter Speicher: komplex und ohne Standard, daher anfällig
protected mode auf GPU: schlank und standardisiert, damit sicherer

Und nochmal: Halt nichts Anderes als auf der CPU-Domäne! Ja, ich weiß dass du nicht zustimmst das die Fensterinhalte (und all der andere Kram der immer mehr zunimmt) im VRAM sensibel sind.

Ich sage es nochmal: Du kannst auch jetzt nicht auf beliebige Daten auf der GPU zugreifen. Man bekommt nur auf das Zugriff was das OS/Treiber einem erlaubt. Schlagt euch das endlich aus dem Kopf.Nochmal: Das Problem ist eben das die Treiber keinen wirksamen Speicherschutz betreiben. Wenn du z.B. mal ernsthaft mit CUDA gearbeitet hast, müsstest du das eigentlich wissen.

Die IHVs müssen für diesen Aufwand eines gemeinsamen Nenners, wie bei so vielen anderen Dingen, gezwungen werden!

Da kann man nichts emulieren. Page-Tables und die Zugriffsrechte dafür müssen in Hardware gemacht werden. Das muss schließlich bei jedem Speicherzugriff geprüft werden. WDDM 2.0 wird neue GPUs voraussetzen.Selbstverständlich könnte man das emulieren. Ob die standardisierte Seitenverwaltung von einem Zwischentreiber oder einer Hardwareeinheit übernommen wird ist doch nur eine Frage der Leistung.

Es geht nur darum, dass das unter Windows Vista/7 nichts bringen wird. Dafür braucht man ein neues Betriebssystem mit WDDM 2.0.Hä wieso das denn? Wenn, dann nur um wieder Geld zu scheffeln.

[Coda]

Zum letzten mal:
vom Treiber koordinierter Speicher: komplex und ohne Standard, daher anfällig
Der Speicher wird vom Betriebssystem gemanaged unter Vista/7, nicht vom Treiber (Damit wird unter anderem erreicht, dass VRAM-Daten nicht "verloren" gehen können und sogar auf die Festplatte geswapped werden). Und ich sehe nicht ein warum das "fehleranfälliger" sein sollte als Hardware. Die Abschottung der CPU-Prozesse funktioniert auch nur, wenn der Kernel keinen Mist baut. Ich sehe da keinen Unterschied. Ring-0-Code ist eben fast immer Sicherheitskritisch und wird dementsprechend auch geprüft.

Und komplex ist daran gar nichts nur den Prozessen die den Buffer erzeugt haben das Mapping zu erlauben. Das ist sogar ziemlich einfach zu machen.

protected mode auf GPU: schlank und standardisiert, damit sicherer
Trugschluss. Es gibt auch HW-Bugs. Und wenn man es in HW sicher bekommt, dann geht es in Software erst recht. Viel einfacher zu verifizieren.

Und nochmal: Halt nichts Anderes als auf der CPU-Domäne! Ja, ich weiß dass du nicht zustimmst das die Fensterinhalte (und all der andere Kram der immer mehr zunimmt) im VRAM sensibel sind.
Das spielt überhaupt keine Rolle ob ich das glaube oder nicht, weil man darauf auch mit WDDM 2.0 noch Zugriff haben wird, weil es APIs dafür gibt :rolleyes:

Selbstverständlich könnte man das emulieren. Ob die standardisierte Seitenverwaltung von einem Zwischentreiber oder einer Hardwareeinheit übernommen wird ist doch nur eine Frage der Leistung.
Was denn bitte für ein "Zwischentreiber"? Wie willst du denn bei jedem Speicherzugriff der GPU einen Treiber aufrufen? Alle anderen Varianten sind der Status Quo. Es gibt schon Software-Speicherschutz.

Bitte bitte lies dich mal ein wie Page-Tables, Speicherschutz und solche elementare Dinge überhaupt funktionieren. Ich sehe da echt riesige Wissenslücken bei dir die immer wieder in der Argumentation durchscheinen.

Hä wieso das denn? Wenn, dann nur um wieder Geld zu scheffeln.
Weil sie dafür WDDM 2.0 vom Windows-8-Kernel aufwändig zurückportieren müssten. Das heißt der Code hat in der Regel schon Abhängigkeiten von Dingen die noch gar nicht vorhanden waren in Windows 7 etc. pp.

Sowas macht Microsoft nicht mit Service-Packs. Und das ist auch mehr als verständlich. Das hat überhaupt nichts mit "Geld scheffeln" zu tun.

[Gauß]

Der Speicher wird vom Betriebssystem gemanaged unter Vista/7, nicht vom Treiber (Damit wird unter anderem erreicht, dass VRAM-Daten nicht "verloren" gehen können und sogar auf die Festplatte geswapped werden). Und ich sehe nicht ein warum das "fehleranfälliger" sein sollte als Hardware. Die Abschottung der CPU-Prozesse funktioniert auch nur, wenn der Kernel keinen Mist baut. Ich sehe da keinen Unterschied. Ring-0-Code ist eben fast immer Sicherheitskritisch und wird dementsprechend auch geprüft.Das Problem ist eben dass es bisher NICHT erforderlich ist alle Speicheroperationen der GPU über den Video Memory Manager vom WDDM zu führen! Und genau darin liegt die Ursache für die vielen beobachteten illegalen Zugriffsmöglichkeiten.

Und komplex ist daran gar nichts nur den Prozessen die den Buffer erzeugt haben das Mapping zu erlauben. Das ist sogar ziemlich einfach zu machen.Es geht um eine fundamentale Kontrolle ALLER Speicherzugriffe.

Trugschluss. Es gibt auch HW-Bugs. Und wenn man es in HW sicher bekommt, dann geht es in Software erst recht. Viel einfacher zu verifizieren.Eine MMU ist aber nun einmal signifikant effizienter als eine VMMU. Und das ist auch der Grund warum die IHVs eben nicht den Video Memory Manager vorziehen.

Das spielt überhaupt keine Rolle ob ich das glaube oder nicht, weil man darauf auch mit WDDM 2.0 noch Zugriff haben wird, weil es APIs dafür gibt :rolleyes:Hä? Dann soll ja der Seitenschutz der MMU einschreiten.

Was denn bitte für ein "Zwischentreiber"? Wie willst du denn bei jedem Speicherzugriff der GPU einen Treiber aufrufen? Alle anderen Varianten sind der Status Quo. Es gibt schon Software-Speicherschutz.Siehe oben.

Bitte bitte lies dich mal ein wie Page-Tables, Speicherschutz und solche elementare Dinge überhaupt funktionieren. Ich sehe da echt riesige Wissenslücken bei dir die immer wieder in der Argumentation durchscheinen.Ja sowieso! :rolleyes:


Weil sie dafür WDDM 2.0 vom Windows-8-Kernel aufwändig zurückportieren müssten. Das heißt der Code hat in der Regel schon Abhängigkeiten von Dingen die noch gar nicht vorhanden waren in Windows 7 etc. pp.

Sowas macht Microsoft nicht mit Service-Packs. Und das ist auch mehr als verständlich. Das hat überhaupt nichts mit "Geld scheffeln" zu tun.Aha, na wenn du soviel von der WDDM2-Entwicklung und dem Windows-8-Kernel weißt, muss es ja stimmen. Nur soviel: selbst absolute Industriegrößen haben da keine Einsicht. :rolleyes:

[Gipsel]

die vielen beobachteten illegalen ZugriffsmöglichkeitenWelche genau? Wo beobachtet?

Das Ganze ist ja eigentlich hier ziemlich OT. Und wenn außer einem pauschalen "Hilfe, ohne vollständigem Speicherschutz könnte man ja vielleicht irgendwie die Rendertargets eines anderen Prozesses/Kontextes lesen/schreiben" (wie schon gesagt, probier' es doch mal aus!), können wir das auch beenden. Bildschirminhalte sind per Definition keine sensiblen Daten und werden daher auch auf CPU-Seite nicht geschützt und können über "offizielle Wege" in Erfahrung gebracht werden.

[Coda]

Das Problem ist eben dass es bisher NICHT erforderlich ist alle Speicheroperationen der GPU über den Video Memory Manager vom WDDM zu führen! Und genau darin liegt die Ursache für die vielen beobachteten illegalen Zugriffsmöglichkeiten.
Worüber denn sonst? Welche Zugriffsmöglichkeiten?

Kommt nochmal was anderes außer heißer Luft? Es wird langweilig.

Hä? Dann soll ja der Seitenschutz der MMU einschreiten.
Es gibt auch shared memory. Und nein, man wird die APIs nicht brechen.

[Partner]

Worüber denn sonst?Ein signifikanter Teil der Speicherallokation wird weiterhin über DMA-Zugriffe des Miniport Display Driver via Dxgk-Kommandopuffer vom Treiber und nicht von WDDM gehandhabt. Bei ICDs ist das ja sowieso klar.

Kommt nochmal was anderes außer heißer Luft? Es wird langweilig.Was erwartest du denn? Das wir hier einen kompletten Hack einer GPU-Beschleunigten Web-Anwendung als Beweis anfertigen?!
Offensichtlich haben wir hier eine Meinungsverschiedenheit und nur die Zeit wird zeigen wer Recht hat. (Aber eigentlich ist es sowieso wurscht, da wir ja eh keinen Einfluss haben.)

[Coda]

Ein signifikanter Teil der Speicherallokation wird weiterhin über DMA-Zugriffe des Miniport Display Driver via Dxgk-Kommandopuffer vom Treiber und nicht von WDDM gehandhabt. Bei ICDs ist das ja sowieso klar.
Natürlich wird die WDDM-Allokation die durch "pfnAllocateCb" erfolgt im Endeffekt durch den Treiber gehandelt mit Callback auf "DxgkDdiCreateAllocation". WDDM kennt ja nicht die Register-Specs jeder Karte.

Was erwartest du denn? Das wir hier einen kompletten Hack einer GPU-Beschleunigten Web-Anwendung als Beweis anfertigen?!
Mir würde schon eine sehr grobe Skizze davon reichen.

Es fällt mir nämlich absolut nichts ein wo nicht eh schon der Host-Code kompromitiert wäre und ich damit sowieso Zugriff auf Screenshots anderer Apps hätte. Dafür braucht man ja nichtmal Admin-Rechte.

Und mir fällt vor allem nichts ein wodurch ich plötzlich Zugriff auf die Texturen etc. anderer Apps Zugriff hätte oder sogar beliebig auf den ganzen VRAM. Für letzteres braucht man nämlich mit Sicherheit Kernel-Space-Rechte, sprich einen Treiber.

[Xmas]

Und mir fällt vor allem nichts ein wodurch ich plötzlich Zugriff auf die Texturen etc. anderer Apps Zugriff hätte oder sogar beliebig auf den ganzen VRAM. Für letzteres braucht man nämlich mit Sicherheit Kernel-Space-Rechte, sprich einen Treiber.
Zum Beispiel Zugriffe außerhalb der Grenzen eines Arrays in Shadern. Oder schau dir mal NV_shader_buffer_load/NV_shader_buffer_store an.

[Coda]

Danke Xmas. Endlich mal vernünftige Infos.

Ersteres wird sehr schwer auszunützen sein, ist aber tatsächlich ein Problem.

Definiert die Extension tatsächlich Pointer auf den flachen kompletten physikalischen VRAM? Wer definiert sowas? Das umgeht ja wirklich komplett die Sicherheitsmechanismen des OS.

[Nighthawk13]

Hat die GPU nicht schon (internen) Speicherschutz? http://www.beyond3d.com/content/reviews/55/7
The address space itself is 40 bits virtual and physical (prior GPUs were already using a 40 bit virtual address space too, mind you).

We're willing to bet that load/store instructions actually use 32-bit byte addresses which get extended to 40 bits via offsetting, with an MMU handling virtual to physical translation.

Hier werden die Performancecharakterisitiken der TLBs ermitelt:
http://www.sciweavers.org/external.php?u=http%3A%2F%2Fwww.stuffedcow.net%2Ffiles%2Fgpuarch-ispass2010.pdf&p=ieee

Also ich vermute mal, das jeder Grafik/Compute/sonstwas-Context einen eigenem virtuellen VRAM-Adressraum läuft.
Dann wird man mit out-of-bounds Zugriffen kaum sinnvolle Daten bekommen.

Die von XMAS beschriebenen out-of-Bounds Zugriffe zu programmieren sind mit Cuda oder OpenCL kein Problem.

In Cuda z.B:
__device__ int myData[10];

__global__ void hackKernel(int f_upperLimit)
{
int sum=0;
for (int i=0;i<f_upperLimit;i++)
sum += myData[i]; // illegal read access
myData[0] = sum; // prevent optimize away
}

void HackTestHost()
{
dim3 one(1,1,1);
for (int limit=1;limit<400*1024*1024;limit*=2)
{
printf("trying limit %i (%i KB)\n", limit, 4*limit/1024);
hackKernel<<<one, one>>>(limit);
cutilSafeCall(cudaThreadSynchronize());
printf("ok\n");
}
}




Wenn ich das Programm bei mir so starte, kann ich 128MB lesen.
Beim Versuch 256MB zu lesen kommt ein Cuda-Error. Einmal hatte ich auch einen kurzen Blackscreen/Driver-recovery.

Edit: cudaThreadSynchronize samt Fehlerhandling vergessen.. Zeit fürs Bett:freak:
Jedenfalls gehen jetzt nur noch 1MB out-of-bounds Zugriff, bei 2MB steigt er mit Cuda-Fehler aus. Das schläft man doch schon besser:wink:
[bandwidthTest]
e:\develop\NVIDIA GPU Computing SDK 3.2\C\bin\win32\Release\bandwidthTest.exe St
arting...

Running on...

Device 0: GeForce GTX 470
Quick Mode

trying limit 1 (0 KB)
ok
trying limit 2 (0 KB)
ok
trying limit 4 (0 KB)
ok
trying limit 8 (0 KB)
ok
trying limit 16 (0 KB)
ok
trying limit 32 (0 KB)
ok
trying limit 64 (0 KB)
ok
trying limit 128 (0 KB)
ok
trying limit 256 (1 KB)
ok
trying limit 512 (2 KB)
ok
trying limit 1024 (4 KB)
ok
trying limit 2048 (8 KB)
ok
trying limit 4096 (16 KB)
ok
trying limit 8192 (32 KB)
ok
trying limit 16384 (64 KB)
ok
trying limit 32768 (128 KB)
ok
trying limit 65536 (256 KB)
ok
trying limit 131072 (512 KB)
ok
trying limit 262144 (1024 KB)
ok
trying limit 524288 (2048 KB)
e:/develop/NVIDIA GPU Computing SDK 3.2/C/src/bandwidthTest/bandwidthTest.cu(113
) : cudaSafeCall() Runtime API error : unknown error.
Drücken Sie eine beliebige Taste . . .

[Gauß]

http://www.heise.de/newsticker/meldung/Luecke-in-der-WebGL-Implementierung-von-Firefox-4-1262111.html
Tja, wer hat noch mal alles daran grundlegend gezweifelt?

[PatkIllA]

http://www.heise.de/newsticker/meldung/Luecke-in-der-WebGL-Implementierung-von-Firefox-4-1262111.html
Tja, wer hat noch mal alles daran grundlegend gezweifelt?
Komisch dass Mozilla das dann behoben konnte.