Monthly Archives: June 2011

Need an ATI R300

The ATI R300 is a very “special” and rather old GPU. It supports OpenGL 2 with one well-known limitation: there is no full non-power-of-two-texture support. KWin has code to handle this situation, nevertheless I broke our R300 support completely one week ago just before the branching of 4.7 without noticing it.

R300 used to be a very important Notebook GPU chip, so we cannot just stop to support it. I am sure that I will fix the regression with the help of users willing to test my patches, but for the long run it’s no solution. Even if we fix this regression I am (after reading our code again) very sure that some new features are not working at all with R300.
Given the situation that we do not notice such regressions during development, it is likely that changes will break support in future again (at least I am not able to develop correctly without testing ;-) . This makes it very difficult as we cannot easily bisect. I see only one real solution: I need to have such a GPU to be able to test recent changes for regressions and implement the (rather trivial) adjustments for R300.
If anyone has such an old card and would be willing to donate it for KWin development, please get in contact with me.
Thanks.

=-=-=-=-=
Powered by Blogilo

Wie sicher ist WebGL wirklich?

WebGL erlaubt es OpenGL in Webseiten einzubetten, also 3D Grafiken auf der lokalen Hardware direkt zu rendern. WebGL baut auf der API von OpenGL ES 2.0 auf, welches selbst eine Untermenge (und Teilweise Übermenge) von OpenGL 2 ist. Eine Webseite, die WebGL einbindet, funktioniert somit prinzipiell auf aller Hardware die entweder OpenGL 2 oder OpenGL ES 2.0 unterstützt. Das ist so ziemlich jedes moderne Smartphone und auch jede Grafikkarte der letzten Jahre.

Persönlich betrachte ich WebGL als den größten Durchbruch im Web Bereich der letzten Jahre und als viel wichtiger als HTML 5. WebGL hat das Potential eine neue Ära einzuleiten. Vor allem im Bereich der Web basierten Spiele sehe ich ein unglaubliches Potential für diese Technologie. Aktuell wird für vieles immer noch Flash verwendet, was größtenteils über die CPU ineffizient rendert. Aber auch viele Webdienste wie z.B. Kartendienste können von 3D Beschleunigung profitieren.
OpenGL ist der offene Industriestandard für 3D Grafik und steht in direkter Konkurrenz zu einer proprietären API, welche nur von einem Softwarehersteller kontrolliert wird. Mit OpenGL laufen Anwendungen auf allen verfügbaren PC Plattformen, mit OpenGL ES 2.0 ist der boomende Markt der Smartphones und Tablets abgedeckt, auf dem es noch keinen konkurrierenden Standard gibt und mit WebGL betritt OpenGL erneut einen Bereich in dem es noch keinen vergleichbaren Standard gibt. Es ist erfreulich zu sehen, dass der offene Standard hier vor der Konkurrenz ist und die Technologie vorantreibt.
Sollte WebGL sich als bevorzugter Vermarktungsweg für moderne Spiele durchsetzen, wäre dies ein schwerer Schlag für die konkurrierende API und den Webbrowser des selben Herstellers, der WebGLnicht unterstützt. OpenGL Anwendungen würden ohne jegliche Anpassung auf allen verfügbaren Plattformen über den Webbrowser laufen, sämtlicher Portierungsaufwand entfällt komplett. Zusätzlich gibt es dem Hersteller der Anwendung ein bewehrtes Distributionsmedium (das Web) in die Hand.
Zuletzt hörte man einiges an Kritik bezüglich der Sicherheit von WebGL (z.B. bei fefe), vor allem möchte der Konkurrent von OpenGL, WebGL nicht in seinen Webbrowser einbauen aus Sicherheitsgründen. Die Sicherheitsproblematik läuft zusammen auf die Tatsache, dass Anwendungen aus dem Web Zugriff auf die lokale Hardware bekommen und nativen Code ausführen können. Zusätzlich gibt es auch (noch) keine Sandbox um den Code abzuschotten und da auf die Hardware zugegriffen werden kann, wird auch einiges des Codes im Kernelmode ausgeführt.
Das ist soweit natürlich alles korrekt, nur macht es die Technologie WebGL grundsätzlich nicht zu einem Sicherheitsproblem. OpenGL für sich ist eigentlich eine riesige Sandbox. OpenGL ist ein Zustandsautomat bei dem die eigentliche API nur dazu da ist den Zustand zu setzen. Also zum Beispiel eine Textur zu laden und anzugeben, dass die nächsten Zeichenbefehle diese Textur verwenden sollen. Das eigentliche Zeichnen der Geometrie erfolgt mit sogenannten Shadern. Es gibt dabei einen Vertexshader zum Umwandeln von Vertices im Anwendungskoordinatensystem nach Clipcoordinaten und den Fragmentshader um jedes vom Vertexshader bestimmte Fragment zu zeichnen. OpenGL verwendet zur Programmierung dieser zwei Shader Zustände eine eigene Programmiersprache namens OpenGL Shading Language (GLSL).
GLSL ist eine sehr domain spezifische Sprache speziell für die Anforderungen der 3D Grafikprogrammierung. Der Vertexshader bekommt als Eingabewerte Attribute pro Vertex und als Ausgabewerte liefert er variierende Werte, die an den Fragmentshader weitergegeben werden und als Eingabeparameter verwendet werden. Der Fragmentshader produziert nun einen Farbwert. Zusätzlich können beide Shader auf gemeinsamen Speicher zugreifen: auf den OpenGL Zustand über sogenannte “uniform” Werte und auf Texturen.
Die Shader in GLSL werden vom OpenGL Treiber in hardwarespezifischen Assemblercode kompiliert. Der Compiler sollte dabei sicherstellen, dass der Code nichts machen kann, was OpenGL nicht erlaubt, also z.B. auf Speicher außerhalb des Kontexts zuzugreifen. Jede Textur und auch jeder Shader wird nämlich in einem Kontext erstellt und ein Objekt darf nur auf Objekte des selben Kontexts zugreifen. Wenn der Shader vom Treiber nicht kompiliert werden kann, so wird ein Fehler zurückgeliefert auf den der Anwendungscode reagieren muss.
Die Technologie WebGL ist also selbst die Sandbox, die angeblich nicht existiert. Ein Shader kann nur graphikspezifischen Code ausführen und es wäre mir auch noch kein Fall bekannt, bei dem GPU Code auf die CPU “ausbrechen” könnte. Die einzige verbleibende Gefahr wäre somit das setzen der Zustände um den Shader auszuführen. Dabei besteht eigentlich auch kein Problem, denn OpenGL ist sehr fehlertolerant und bei einem fehlerhaften Ansprechen der API wird ein GL_ERROR zurückgeliefert was im schlimmsten Fall zu Darstellungsfehlern führt. Die OpenGL API ist somit auch Bestandteil der Sandbox.
Wie wir sehen bietet die Technologie WebGL außreichend Sicherheit. Mittels der Technologie ist es nicht möglich Schadprogramme auf den Client zu bekommen. Die Vorwürfe gegenüber der Technologie sind daher einfach falsch.
Anders sieht es mit den Implementierungen aus. In der Theorie sollte OpenGL sicher sein, jedoch kann ich aus eigener Erfahrung sagen, dass dies nicht der Fall ist. Alle Treiber (egal ob offen oder proprietär) haben Fehler und können die Anwendung zum Absturz bringen, bei legalen und illegalen OpenGL Befehlssequenzen. Somit ist ein Angriffspotential denkbar: ist man in der Lage über die richtigen Befehle in WebGL den Treiber zum Absturz zu bekommen, kann man im schlimmsten Fall Code auf der CPU ausführen. Dies ist ein reales Angriffsszenario, dessen sich die Browserhersteller bewusst sind. So hatte ein Mozilla Entwickler vor der Veröffentlichung von Firefox 4 z.B. auf der KWin Mailingliste nach den Erfahrungen zur Stabilität insbesondere der freien Treiber nachgefragt.
Von dem theorethischen Angriffsszcnario zu einem Exploit ist es dennoch ein weiter und meiner Meinung nach sehr unwahrscheinlicher Weg. Zum einen ist es schwer den OpenGL Treiber gezielt zum Absturz zu bringen, zum anderen diesen Absturz zum Angriff auszunutzen. Abstürze lassen sich nach der Erfahrung mit KWin meistens nur in einer bestimmten Kombination von OpenGL Befehlen, Treiberversion und Hardware erreichen. Ein Angreifer müsste also den Angriff speziell auf Hardware und Treiber zurechtschneiden. Natürlich wäre solch ein Fall dann eine Möglichkeit den Browser remote abstürzen zu lassen, dies ist natürlich schon einmal sehr schlecht, lässt sich aber von Browserherstellerseite sehr leicht beheben indem WebGL Kontexte in einen eigenen Prozess ausgelagert werden.
Die viel größere Schwierigkeit dürfte sein den Crash zum Angriff auszunutzen. Außer GLSL (was ja nicht auf der CPU sondern GPU ausgeführt wird) gibt es keine Codebestandteile, die direkt ausgeführt werden. Die WebGL API zum Setzen des OpenGL Zustands verwendet JavaScript und sollte somit vom restlichen System abgeschottet sein. Die API selbst erlaubt auch ausschließlich nur das Setzen der Zustände. Die einizige Möglichkeit größere Speichermengen über Buffer anzusprechen (um zum Beispiel Angriffscode abzulegen) ist das Laden von Texturen was jedoch in der WebGL API im Vergleich zur OpenGL C-API abgesichert wurde.
Falls es mittels Texturen und OpenGL API möglich ist einen Treiber so zum Absturz zu bekommen, dass Code ausgeführt werden kann, so ist das ein grundsätzliches Problem was nichts mit der Technologie WebGL zu tun hat. Moderne Webbrowser verwenden OpenGL auch zum Rendern der Canvas womit es denkbar ist, dass durch das einfache Einbinden desselben gefährlichen Bildes der Browser zum Absturz gebracht werden kann und der Schadcode ausgeführt werden kann.
Wie wir sehen ist der Vorwurf gegenüber der Technologie WebGL nicht sicher zu sein, schlicht falsch. Genaugenommen betrifft es nur sich fehlverhaltende Implementierungen deren Schwachstellen generell ausgenutzt werden können, egal ob es sich um WebGL, hardwarebeschleunigtes Rendern der HTML Canvas oder harwarebeschleunigtes Flash oder Silverlight handelt. WebGL ist hier im Vergleich zu anderen Lösungen wie hardwarebeschleunigtes Flash sogar besser, da es sich abschotten lassen kann.
Ich möchte hier nicht sagen, dass der Einsatz von WebGL ungefährlich ist. Sicherlich besteht durch die Instabilität der OpenGL Implementierungen und der recht neue Einsatz in Webbrowsern ein Gefährdung. Jedoch betrifft diese alle Technologien, die auf OpenGL (oder auch Direct3D) zugreifen. Das Argument des Konkurrenzherstellers klingt daher für mich als vorgeschoben und nach FUD um der Konkurrenz zu schaden und die konkurrierende API nicht im eigenen Webbrowser einsetzen zu müssen.

=-=-=-=-=
Powered by Blogilo

Neues Spielzeug

Es sollte ja kein Geheimnis mehr sein, dass der X Server mitlerweile angezählt ist und mit Wayland der potentielle Nachfolger bereits in den Startlöchern steht. Auch wenn es noch lange dauern wird bis wir X endlich in den Ruhestand schicken können, ist für mich bereits der Zeitpunkt gekommen, mich etwas intensiver mit der neuen Technologie zu beschäftigen. Für KWin ist es wichtig früh Wayland Anwendungen zu integrieren, da man unter KDE Plasma Wayland nicht benutzen kann, wenn KWin Wayland nicht unterstützt.

Letzte Woche habe ich angefangen KWin um ein Wayland Backend zu erweitern. Glücklicherweise ist das Wayland Server Protokol extrem einfach gehalten wodurch man sehr schnell erste Ergebnisse erreichen kann:
Dieser Screenshot ist sehr interessant. Das Terminal Fenster ist ein Wayland Client, die Fensterdekoration ist jedoch ein klassisches X11 Fenster. Wir kombinieren hier also beide Technologien. Dies zeigt sehr schön die Strategie, die wir bei KDE Plasma einschlagen: schrittweise Unterstützung für Wayland Fenster implementieren ohne unseren bestehenden Desktop zu zerstören. Erst wenn wir volle Unterstützung implementiert haben, werden wir X11 verlassen und auf Wayland wechseln. Bis dorthin werden wir eine Strategie fahren bei der Wayland Clients unter X11 verwaltet und gerendert werden.
Auch wenn der Screenshot schon nach sehr viel aussieht, darf man sich nicht täuschen lassen. Bis wir auf Wayland sind, ist noch ein weiter Weg. Viel muss erst noch implementiert werden. Für mich ist das gerade extrem spannend und ich fühle mich wie ein kleines Kind mit einem neuen Spielzeug. Schritt für Schritt kann ich nun die Fenster benutzbar machen. Dabei lerne ich auch richtig viel noch über KWin Interna. Mit dem X11 Fenstermanagement musste ich mich eigentlich nie beschäftigen, da es vollständig und korrekt implementiert ist. Nun bin ich dabei Fenstermanagement für Wayland nachzuimplementieren.
Richtig toll ist wie viel einfach so ohne jegliche Anpassung funktioniert. Vor allem unser Effekt Framework interessiert sich überhaupt nicht dafür ob ein Fenster nun X11 oder Wayland ist. Es wird einfach integriert und angezeigt. Auch wie man im Screenshot sehen kann, ist es den Fensterdekorationen egal ob sie ein X oder Wayland Fenster dekorieren.
Experimentierfreudige Nutzer können das ganze auch schon testen (auch wenn es extrem langweilig ist) wenn sie selbst aus den Quellen bauen. Bis das ganze in Distributionen verfügbar wird, wird noch einiges an Zeit vergehen. Da wir ja in Feature Freeze für 4.7 gerade sind, werden all Änderungen erst in 4.8 erscheinen und auch dann ist es fraglich ob Distributionen mit den entsprechenden Build Flags bauen werden (wer hat denn schon Wayland in den Repos?). Bei OpenSUSE wird es wahrscheinlich in den Factory Builds verfügbar sein, sobald die Änderungen in den master branch einfließen. Bei Kubuntus Project Neon ist das auch denkbar, jedoch könnte die Wayland und Mesa 7.11 Abhängigkeit das ganze erschweren.

=-=-=-=-=
Powered by Blogilo

Discovering a New World

This weekend a group of KDE hackers met in a small mountain village, Randa, in Switzerland to discuss the future of the KDE Frameworks. I was not present, but started on Saturday an endevour for the future of the KDE Plasma Workspaces. Yesterday evening I arrived in the new world:

desktopgrid-with-wayland
This is not just the Desktop Grid effect. The gears window you can see on each of the desktops is a Wayland client, all other windows are X clients. For me this is a rather historic event, not just for KDE but also and especially for Wayland. Up to now there have only been the demo compositor and the QtCompositor as Wayland Compositors. They are more or less just proof of concept. But this is different event: we have here a normal X11 window manager and are able to integrate Wayland clients into the compositing scene just as if it were an X client. This is not a Wayland compositor, it is a X compositor with an implemented Wayland Server component.
This is the proof that there is a sensible migration path from X11 to Wayland. We can use our normal and known X system and manage Wayland clients in it. There is no need to implement the complete stack on top of Wayland first with possible regression. As we can see the Effect Framework does not need any adjustment to support Wayland Clients, which means we can give the user their known KDE Workspace experience. For the user it is irrelevant if a window is an X or Wayland client, it is just a window. For KDE this means that we don’t need and won’t break the desktop. We will switch to Wayland when we are ready, but at the same time we can offer Wayland to interested developers and users who want to experiment with it. For Plasma Active on the other hand we will switch to an X less Wayland-powered KWin as soon as possible.
Of course there is still a long way to go to get to Wayland. This is just rendering, we still need to implement the complete Window Management, transition the compositing away from X, break out X from KWin and lots more. It’s the result of four days where I spent a few hours each day on hacking on that topic. Which shows how simple the Wayland protocol is, although the documentation could be better ;-)
Now the next steps will be to clean up the code, document it and push it into a git branch. I hope to see many developers to pick up on it and to start implementing the window manager functionality and extending e.g. Plasma Desktop to support Wayland Clients in the Tasks Applet and many more such things.
I will present the complete KWin Wayland strategy at Berlin Desktop Summit in August.

=-=-=-=-=
Powered by Blogilo