Fragen? Antworten! Siehe auch: Alternativlos
Spannend an dem finde ich vor allem den Teil hier:
[Feel free to send this to the FreeBSD lists or whatever to get it fixed. I honestly can't be bothered making a throwaway email and going through the subscription process, nor do I want "TheGrandSchlonging" to appear in FreeBSD commit logs.]TheGrandSchlonging is sein Reddit-Username.Und inhaltlich geht mir das ja ähnlich. Ich ärgere mich jedes Mal, wenn ich irgendwo einen Bug melden will, und die mich erstmal durch irgendeine Account-Prozedur durchtrichtern wollen. Das ist ja nicht so, als bin ich hier der Bittsteller, der was von euch will. Im Gegenteil. Ihr wollt was von mir. Nämlich dass ich euch von dem Bug erzähle, den ich gefunden habe. Also hört mal bitte auf, mir künstliche Barrieren in den Weg zu legen.
Ich hab eh schon vor Jahren völlig aufgehört, nach Bugs in kommerziellen Produkten zu suchen, außer ich werde dafür bezahlt. Und dieser Account-Bullshit und wie die Leute in den Bugtrackern dann teilweise mit ihren Usern umgehen, das ist echt abschreckend und führt nicht zu mehr gemeldeten Bugs.
Aktuelles Beispiel, auch wenn das kein Security-Bug ist, war für mich mpv. mpv ist das Nachfolge-Projekt von mplayer. Mit mplayer oder mpv spiele ich seit gefühlt 20 Jahren meine Video-Dateien ab und hören mir meine mp3-Sammlung unter Linux an. Das Programm ist für mich also eher wichtig. Ich hatte mir ja kürzlich einen Acer Swift 1 gekauft, weil der besonders gute Akkulaufzeit hat und sich besonders gut zum Video-Abspielen eignet dank Hardware-Decoding von H.264, H.265 inklusive 10-Bit Farbtiefe, und VP9. Linux unterstützt das. mpv unterstützt das. Ich spiele also mit mpv ein Video ab und kriege massives Stottern und Frame Dropping. Das habe ich sehr vielen Jahren nicht mehr erlebt, dass ein Player Frames droppt, weil die Performance nicht reicht. Da kommt dann noch so eine von-oben-herab-Fehlermeldung, dass dann wohl das System kacke sei, auf dem man gerade arbeitet, oder zumindest die Treiber, die man verwendet.
Ich habe also vlc probiert, und das flutscht. Da stottert nichts. Stellt sich raus: mpv hat zwar -vo vaapi und -vo xv (dekodiert mit CPU aber macht Farbraumkonvertierung und Skalierung in Hardware) und kann damit stotterfrei dekodieren, aber besteht per Default auf -vo gpu, und der macht irgendwelchen Shader-Kram, der auf Gamer-Hardware prima tut und womöglich auch bessere Qualität liefert (nicht dass ich das hätte beobachten können), und zusätzliche Filter erlaubt, die ich noch nie benutzt habe. Aber auf dem Gemini Lake Atom-Derivat in dem Swift 1 flutscht das halt nicht. Ich habe also einen Bug gefiled, dass sie in der Fehlermeldung möglicherweise auf -vo vaapi hinweisen könnten statt dem Benutzer die am wenigsten hilfreiche Meldung aller Zeiten zu geben ("du hast wohl Scheiß Hardware").
Es gibt auch ein mpv-Wiki, wo drinsteht, dass niemand jemals etwas anderes also -vo gpu nehmen soll, weil das so geil ist, und andere Alternativen werden dort auch gar nicht erwähnt.
Nun kann mir das ja eigentlich alles egal sein. Ich hab ja die Lösung gefunden, nämlich -vo vaapi (damit spielt das Gerät auf Akku über 10h am Stück Video ab und hat dabei eine CPU-Auslastung von unter 5%). Aber das Projekt liegt mir halt am Herzen. Schreiben die zurück: Deine Hardware ist kacke, nein wir ändern das nicht, und wenn wir da ranschreiben, dass vaapi weniger Strom verbraucht als gpu, dann benutzt ja niemand jemals gpu.
Ich kommentierte dann noch, dass wenn sie das nicht fixen, dass die Kunden dann halt zu vlc abwandern, wenn mpv "zu lahm" ist, was es ja nicht wirklich ist, aber es sieht halt so aus. Und sie sollen mal lieber ehrlich sein mit ihren Kunden. Daraufhin meinte dann jemand, ich könne ja gehen, wenn mir mpv nicht gefällt, und machte den Bug zu.
Liebe Leser, wenn ihr jemals in der Situation seit, einen Bugtracker zu pflegen, dann macht lieber gar nichts als euch so zu verhalten. User verprellen ist so das schlechteste, was man tun kann. Fragt euch mal selbst, ob ihr einem Projekt helfen wollen würdet, das euch beim ersten Versuch so den Stinkefinger ins Gesicht hält.
Ich erwähne das, weil FreeBSD so das Gegenteil davon ist. FreeBSD, PostgreSQL und LLVM sind Projekte, die mit Bugreports professionell, zeitnah und sauber umgehen, und wenig überraschend sind die auch echt erfolgreich am Ende. Projekte wie gcc, bei denen auf dem Bugtracker häufig eher User-Abwehr statt Bug-Beseitigung betrieben wird, geraten halt ins Hintertreffen. Und mpv, wenn es sich so verhält, wird als Privatprojekt von irgendeinem Frickel-Nerd in seinem Keller enden, das niemand kennt und niemand benutzt. Schade eigentlich, denn die verspielen da über Jahre aufgebautes Karma.
Update: Ein Einsender kommentiert:
es wird deutlich darauf lhingewiesen (https://www.freebsd.org/security/), dass security-related Krams per Mail an secteam@ berichtet werden soll/kann. Der Link steht auch im Default-motd, sollte also jeder FreeBSD-User mal gesehen haben :)
Oh das wusste ich nicht. Dann gibt es in der Tat nicht so viele Ausreden, den Bug auf reddit zu posten statt den FreeBSDlern zu mailen.
Update: mpv hat den Bug nicht nur geschlossen sondern als "too heated" gelockt, womit weitere Kommentare von Externen nicht mehr erlaubt sind. Gute Arbeit, Jungs. So strahlt man Souveränität aus.
Update: Haha, geil, jetzt werde ich da auch noch als Lügner bezeichnet. Natürlich schön nachdem man mir die Kommentiermöglichkeit weggenommen hat. Tolles Projekt, dieses mpv. Da will man doch mithelfen!1!!
Aber ein Detail noch: In der Zwischenzeit hat sich gezeigt, dass auch -vo gpu flutschen kann, wenn man bloß auch noch --hwdec=auto macht. Ja, ich bin genau so belustigt wie ihr. Die haben eine auto-Option für den Hardware-Decoder und machen die dann nicht an. Der Lacher ist ja, dass -vo xv auch Software-Decoding macht und bei weitem schnell genug ist. Wir wissen also zwei Dinge jetzt: Die CPU ist schnell genug für Software-Decoding, und das OpenGL ist schnell genug fürs Rendering. Aber in Kombination verkackt mpv es. Ich hätte ihnen ja beim Debuggen geholfen. Aber ich helfe nur Projekten, die ihren Usern Menschenwürde zugestehen.
Zu "der WebGL-Lücke" habe ich nichts gesagt, weil das keine Lücke ist, sondern eine Idee der Größenordnung "lasst uns im Winter Russland angreifen". Ich versuche das mal kurz zu erklären. Prozessoren haben heutzutage eine MMU drin. Die MMU erlaubt es, Speicherschutz zu implementieren. Das Betriebssystem kann damit z.B. verhindern, dass irgendwelche Prozesse Speicherbereiche anderer Prozesse oder des Betriebssystems selber kaputtmachen.
Hardware hat sowas nicht. Insbesondere haben Grafikkarten sowas nicht. Früher war das nicht so schlimm, weil auf der Grafikkarte kein Code lief, also jedenfalls kein hochgeladener Code, sondern man konnte halt aus ein paar Operationen auswählen, die dann auf der Grafikkarte ausgeführt werden. Heute haben Grafikkarten eigene Programme, die Shader. Die können u.a. auf den Hauptspeicher des PCs zugreifen. Lesend und schreibend.
Mit anderen Worten: wer Shader auf die Grafikkarte hochladen kann, hat Schreibzugriff auf das Betriebssystem.
Das hat sich noch nicht weit genug herumgesprochen, dass die Malware-Toolkits das regulär benutzen. Aber alle, die sich mit der Technologie mal beschäftigt haben, wissen das. Grafikkarten sind da nicht alleine. Jede Hardware am PCI-Bus kann das. Und PC-Card und ExpressCard sind im Wesentlichen auch nur herausgeführte PCI-Busse. Wer also ein Notebook mit solchen Slots hat, der gibt jedem mit physischem Zugriff auf das Gerät auch softwaretechnisch Vollzugriff auf das Gerät, und zwar ohne dass derjenige rumschrauben müsste.
Und dann gibt es natürlich noch schlechte Ideen wie Firewire, was kein PCI-Bus ist, aber wo man über den Stecker trotzdem Schreibzugriff auf den Hauptspeicher im Rechner hat. Das selbe in Grün. Es sah ja eine Weile so aus, als hätte man aus dem Firewire-Debakel gelernt, aber nein, Intels neueste Technologie, Thunderbolt, führt gleich einen ganzen PCI-Express-Bus per Stecker raus aus dem Gehäuse. SUPER!
Aber zurück zu den Grafikkarten. Wenn man das einmal verstanden hat, dass Shader-Zugriff auf Grafikkarten sicherheitstechnisch Game Over ist, verstehen man auch plötzlich diverse andere Dinge als die schlechte Idee, die sie sind. Z.B. … in "virtuellen Maschinen" 3d-Grafik zu machen. Oder … 3d-Grafik über Netz forwarden! Game Over.
Es gibt eine Hoffnung im dem ganzen Jammertal. IOMMU. IOMMU ist eine MMU für I/O-Zugriffe. Damit könnte man also z.B. einschränken, welche Speicherbereiche die Grafikkarte überhaupt sehen kann. AMD hat sowas schon länger, Intel hat kürzlich nachgelegt. Leider … gibt es da auch schon Angriffe drauf.
Solange es hier keine funktionierende und erprobte Schutz-Technologie gibt, muss man alle 3d-Software (und natürlich erst Recht OpenCL/Cuda/Stream-Kram) so betrachten, als habe man ihr gerade Vollzugriff auf das System erteilt. Denn im Wesentlichen hat man das.
Vielleicht versteht jetzt der eine oder andere, wieso man keinesfalls irgendwelchen Webseiten Shader-Zugriff auf seine Grafikhardware geben will.
Update: Hier kommen gerade ein paar Mails von Leuten rein, die es besser/genauer wissen als ich. Die beiden Haupteinwände sind: a) man kann per WebGL nur GLSL hochladen, nicht binäre Shader, und b) die Grafikkarte kann nicht auf den kompletten Speicher im PC zugreifen, sondern nur auf die Bereiche, die der Treiber eingestellt hat. Soweit ich weiß ist das generell beides richtig.
Allerdings sind ja die Treiber nicht Open Source (Ausnahmen bestätigen die Regel; Benutzer der Open Source GL-Treiber unter Linux können hier möglicherweise ruhiger schlafen). Und Kontextwechsel kosten. Und Grafikkartentreibern geht es um Performance, sogar mehr noch als um Korrektheit. Ich bleibe daher bei meiner Einschätzung. Zumindest bis jemand kommt und es mir noch anders erklärt :-)