Thema: GUI LowLevel

[FlashBurn]

Und solange man annimmt, dass die Hardware funktioniert, ist sie ebenfalls streng deterministisch... von defekter Hardware gehen wir hier ja nicht gerade aus.

Ich will damit auch nur sagen, dass es die Dinge sind, die man nicht einplant bzw. einplanen kann, die alle so schön deterministisch sind, die einem dann in der Praxis nen Strich durch die Rechnung machen.

Ja, die kann man mit Statistik erschlagen.

Jap, aber halt nicht zu 100%.

[Jidder]

Ich glaube ihr solltet eure Ironiedetektoren mal kalibrieren lassen.

[erik.vikinger]

Hallo,

Ich glaube ihr solltet eure Ironiedetektoren mal kalibrieren lassen.

Also ich hab meine Aussagen betreffend des unterstellten Determinismus eigentlich alle ernst gemeint.

Der nun seit 50 Jahren tote Physiker hieß übrigens Erwin Schrödinger. Wer sich die Gedanken hinter seinem bekannten Tierexperiment ansieht versteht besser was gemeint ist.
Eigentlich lehne ich ja die Existenz von Chaos grundsätzlich ab, IMHO ist Chaos nur ein Hilfskonstrukt von Leuten die zu Faul sind ein System komplett auszumessen um es eben komplett zu kennen, aber jedes mal wenn ich das Zimmer meines Sohnes betrete weiß ich das es Chaos wirklich real gibt.


Grüße
Erik

[FlashBurn]

Eigentlich lehne ich ja die Existenz von Chaos grundsätzlich ab

Ich wollte mit der Chaostheorie auch nur darauf hinaus, des ich dem Menschen die Fähigkeit abspreche, ein so komplexes System wie die Natur 100%ig genau vorraus zu sagen. Dazu gibt es einfach zu viele Faktoren und alleine schon das Erfassen/Messen aller Faktoren (im Endeffekt müsste man ne komplette Momentaufnahme des gesamten Systems, sprich des gesamten Universums machen, um alle Faktoren zu kennen) ist einfach unmöglich. Weil ja jeder Faktor rein theoretisch einen Einfluss haben könnte, der das Ergebnis verändert (die meisten Wirkungen dürften sich selbst unserer Vorstellungskraft entziehen).

Und ein System als abgeschlossen zu betrachten, ist auch nur ein Hilfskonstrukt um externe Einflüsse ausschließen zu können und damit Sachen einfacher zu machen.

[erik.vikinger]

Hallo,

im Endeffekt müsste man ne komplette Momentaufnahme des gesamten Systems, sprich des gesamten Universums machen, um alle Faktoren zu kennen

Es ist natürlich unmöglich eine vollständige Momentaufnahme das gesamten Universums zumachen, selbst ich bestreite das nicht, aber das Universum deswegen als chaotisch zu bezeichnen ist eben auch keine Lösung. Darauf zielt meine Weigerung der Akzeptanz des Chaos ab, auf nicht mehr und nicht weniger.

die meisten Wirkungen dürften sich selbst unserer Vorstellungskraft entziehen

Hm, zumindest die Fantasie wird doch allgemein als grenzenlos bezeichnet, vielleicht sollten wir die Meinung der Allgemeinheit (also des Pöbels) in diesem speziellen Fall doch mal ernst nehmen.

Und ein System als abgeschlossen zu betrachten, ist auch nur ein Hilfskonstrukt um externe Einflüsse ausschließen zu können und damit Sachen einfacher zu machen.

Bei den meisten physikalisch Dingen trifft das sicher zu, ja, aber Software ist IMHO tatsächlich ein abgeschlossenes System weil alle potentiellen Einflüsse ja auch durch die Software kontrollierbar sind. Die Auswirkungen die ein IRQ potentiell haben kann sind durch die Software vorgegeben da auch der IRQ-Handler ein Teil der Software ist und damit unter der Kontrolle des Softwareentwicklers steht. Selbst die Zeitpunkte an denen ein IRQ möglich ist sind durch die Software vorgegeben da die zugrunde liegende Hardware ja von der Software konfiguriert/manipuliert wird und damit ebenfalls unter der Kontrolle des Softwareentwicklers steht. Wir schließen jetzt mal Fehler in der Hardware aus und nehmen auch an das der Softwareentwickler die vollständige Hardwaredokumentation komplett gelesen und verstanden hat.


Grüße
Erik

[FlashBurn]

Was ist eigentlich mit so sachen, das es möglich ist von außen fremden Code einzuschleußen, passt das da noch rein? Ich meine damit nicht mal unbedingt Buffer-Overflows oder sowas, sondern, war es nicht sogar Firewire (oder Thunderbolt??), dass einem Gerät zuviel Möglichkeiten (hardwaretechnisch) gegeben wurden, so dass Code ohne Eingriff der Software eingeschleust werden kann.

[Svenska]

firewire war der übeltäter. thunderbolt wird wohl ähnlich sein.
und zum thema gui: die grafikkarte ist da keine ausnahme. opengl im browser hardwarebeschleunigt heißt, webseitencode hat vollzugriff auf physischen speicher (falls keine iommu aktiv).

[FlashBurn]

und zum thema gui: die grafikkarte ist da keine ausnahme. opengl im browser hardwarebeschleunigt heißt, webseitencode hat vollzugriff auf physischen speicher (falls keine iommu aktiv).

Aber nur auf vom GUI "genehmigten" RAM oder?

[Svenska]

DMA ist DMA.
Shaderprogramme sind Code, der auf der Grafikkarte ausgeführt wird... und den man vorher aus Performancegründen nicht analysiert.

[FlashBurn]

Ich wusste nicht das man mit Hilfe von Shadercode soviel (auf jeglichen Speicher zugreifen) machen kann. Ist dass dann aber nicht immer ein Problem (auch bei normalen Anwendungen)?

[erik.vikinger]

Hallo,

Was ist eigentlich mit so sachen, das es möglich ist von außen fremden Code einzuschleußen, passt das da noch rein?

Hm, das ist in der Tat eine hochgradig philosophische Frage. Ich drücke mich jetzt einfach mal vor einer richtigen Antwort und definiere das der Schadcode Teil des geschlossenen Systems "Software" ist.


Solange Shadercode ungeprüft in die Grafikkarte gespielt wird stellt dieser auch immer ein Sicherheitsrisiko dar, egal welche Anwendung den einschleppt.

Sollte sich Thunderbolt wirklich so durchsetzen wie Intel und Apple das wollen dann müssen auf jeden Fall auch IOMMUs zur Standardausrüstung aller PCs gehören, nebst einem OS das diese IOMMUs auch anständig zu nutzen weiß. Bei meinem privaten Laptop hab ich den Chip fürs Firewire vom Mainboard dauerhaft entfernt, das erspart mir nicht nur ein potentielles Sicherheitsleck sondern bringt auch minimal längere Akkulaufzeit.


Grüße
Erik

[Svenska]

Ich wusste nicht das man mit Hilfe von Shadercode soviel (auf jeglichen Speicher zugreifen) machen kann. Ist dass dann aber nicht immer ein Problem (auch bei normalen Anwendungen)?

Eher nein. Code, der von der CPU ausgeführt wird, unterliegt dem Speicherschutz, der von CPU und Betriebssystem garantiert wird. Wenn du 3D-Spiele meinst: Ja, das ist auch ein prinzipielles Problem, aber nicht praktisch relevant (wenn die Software erstmal im System ist, reicht ein Standard-Exploit des OS; bei Sandbox-Umgebungen wie Browsern ist das schon schwieriger).

[FlashBurn]

Solange Shadercode ungeprüft in die Grafikkarte gespielt wird stellt dieser auch immer ein Sicherheitsrisiko dar, egal welche Anwendung den einschleppt.

Wird der Code denn vom Treiber überprüft und selbst wenn, auch die (Treiberprogrammierer) machen Fehler?

Was mich daran nur gerade wundert, wieso habe ich davon noch nie was gehört? Ich meine das ist doch schon nen potentielles Risiko, vorallem wenn man dann an WebGL denkt.

[Svenska]

Wird der [Shader]Code denn vom Treiber überprüft und selbst wenn, auch die (Treiberprogrammierer) machen Fehler?

Nein, wenn du den Code auf der CPU analysierst, könntest du ihn auch gleich dort ausführen. Das will man aus Performance-Gründen nicht.

Was mich daran nur gerade wundert, wieso habe ich davon noch nie was gehört? Ich meine das ist doch schon nen potentielles Risiko, vorallem wenn man dann an WebGL denkt.

Wenn du Hardwarebeschleunigung um jeden Preis möchtest, dann ist ein potentielles Risiko nicht wichtig genug. Siehe z.B. hier.

[FlashBurn]

Auch wenn´s total OT ist, aber das mit dem Bundestrojaner ist im Mom viel interessanter, vorallem da wir uns da auf das verlassen was einige wenige sagen, die auch auch verarscht worden sein können.

[erik.vikinger]

Hallo,

Wenn du Hardwarebeschleunigung um jeden Preis möchtest, dann ist ein potentielles Risiko nicht wichtig genug.

Wie wahr!
Ich finde ja hier wären die HW-Designer mal in der Pflicht bestimmte physische Adressbereiche (z.B. 0xFEExxxxx) hardcodiert auszufiltern damit wenigstens ein paar der ernsten Design-Probleme der x86-Plattform-Architektur versteckt werden.

Siehe z.B. hier.

Der Artikel ist interessant, aber noch interessanter (zumindest für mich) ist der Link auf Attacken gegen die IOMMU von Intel. Einer der häufigsten Sätze in dem PDF ist "This attack should never be possible on a well-designed architecture.", wenn das mal kein echtes Lob an Intel ist. In diesem Dokument werden eine ganze Menge an x86-spezifischen Design-Features aufs Korn genommen (vor allem im Zusammenhang mit Interrupts). Ich muss feststellen das meine Entscheidung in meinen CPUs keinen Local-APIC o.ä. haben zu wollen (und nur einen einzigen IRQ-Controller im Chip-Satz) mir doch unzählige Problemen erspart. x86 ist die Plattform auf der die fortschrittlichsten Schutzmechanismen (SMEP/IOMMU/....) existieren (von meiner Plattform, die ja eben noch nicht existiert, mal abgesehen ) und trotzdem ist es die anfälligste Plattform überhaupt, einfach nur weil das meiste davon extrem stümperhaft entwickelt/implementiert wurde oder weil man Problem-Relikte aus der Urzeit mitschleppt. Klar sind bei x86 auch deswegen so viele Lücken gefunden worden weil man dort auch am meisten sucht aber ich bin trotzdem der Meinung das die allgemeine Computer-Sicherheit auf diesem Planeten einen echten Schritt nach vorn machen würde wenn man x86 einfach komplett einstampft und verschwinden lässt.


Grüße
Erik

[FlashBurn]

Andere Architekturen z.B. ARM kennen doch auch DMA (und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante). Wie sicher ist das denn dort?
Dort kann doch bestimmt auch der Shader-Code dann auf den gesamte RAM zugreifen oder? Bzw. kann man dort nicht z.B. auch steuern wieviel RAM z.B. die Graka bekommt? Dann könnte man also auch ganz leicht diesen Bereich verändern.

[Svenska]

Klar sind bei x86 auch deswegen so viele Lücken gefunden worden weil man dort auch am meisten sucht aber ich bin trotzdem der Meinung das die allgemeine Computer-Sicherheit auf diesem Planeten einen echten Schritt nach vorn machen würde wenn man x86 einfach komplett einstampft und verschwinden lässt.

Selbst Intel hat's schon oft genug versucht (iAPX 432, i860, i960 und auch ARM) und nicht geschafft. Microsoft hat's mitgetragen (WinNT für PowerPC, MIPS, DEC Alpha) und es ist nichts draus geworden. Du wirst diesen Dreck einfach nicht los. ARM ist im mobilen Bereich weit überlegen, aber weder im Server- noch im Workstation-Bereich denkt man auch nur darüber nach.

Andere Architekturen z.B. ARM kennen doch auch DMA (und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante). Wie sicher ist das denn dort?

Wer suchet, der findet. Kein System ist hundertprozentig sicher. Aber ein System, was von Grund auf einfach konzipiert ist, kann man einfach schützen. Bei einer Plattform, wo der simulierte Tastaturcontroller den RAM-Zugriff und den CPU-Reset steuern können muss, ist das nicht mehr so einfach möglich.

Gruß,
Svenska,
dem das ganze Thema hier viel zu OT ist.

[erik.vikinger]

Hallo,

und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante

Warum sollen die HW-Geräte auf anderen Architekturen nicht auch Scatter/Gather unterstützen können? Ob die HW-Geräte mit verstreutem physischen Speicher zurecht kommen hat nichts mit der CPU zu tun.

Gegen busmasterfähige HW-Geräte hilft grundsätzlich nur eine anständige IOMMU (und dazu noch eine gescheite Routing-Strategie im Chipsatz), egal auf welcher Plattform. Das Problem an x86 ist das dessen Komplexität total aus dem Ruder gelaufen ist. Weißt Du genau wie viele Ausführungsmodi eine moderne x86-CPU überhaupt hat? Neben den 4 PM-Ringen (und noch dem Real-Mode und Virtual-Real-Mode) gibt des da noch den SMM (und weil der eine Design-Katastrophe mit Sicherheitslecks ist dazu noch einen SMM-Monitor oder so ähnlich), irgendwas fürs TXT und bestimmt gibt es noch ein paar Dinge die sich meiner Vorstellungskraft gänzlich entziehen. Alle anderen CPU-Architekturen haben genau 2 (mache auch 3) Modi: "UserMode" und "SystemMode" (manche noch einen "ÜberSystemMode" um damit z.B. Page-Table-Walks in SW machen zu können). Simplizität ist für sichere Designs ein essentiell wichtiges Design-Paradigma.

wo der simulierte Tastaturcontroller den RAM-Zugriff und den CPU-Reset steuern können muss

Das muss man sich erst mal in aller Ruhe zwischen den Hirnwindungen setzen lassen, was es bei x86 alles an Unsinn gibt. Ich habe wirklich Ehrfurcht vor jedem der dafür allen ernstes versucht ein anständiges OS zu programmieren das all diese wirren Dinge auch erfolgreich benutzt.


Grüße
Erik

[freecrac]

Gerade das periodische händische Umkopieren des gesamten Framebuffers von einem SW-Buffer im normalen RAM in den Video-Speicher der Grafikkarte ist deutlich aufwendiger als wenn die Grafikkarte sich die Bilddaten selber per Busmastering aus dem Speicher holt.

Also man kopiert ja meistens nicht den gesamten Framebuffer (das will man ja gerade vermeiden), sondern nur das was sich geändert hat und dazu muss man auch lesen und das ist aus dem Grakaspeicher sehr langsam. Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).

Im "VBE-AF07.pdf" von vesa.org unter public documents steht einiges über den Treiber "VBEAF.DRV". Ich selber habe noch keine Erfahrungen damit gemacht.

Dirk