Firmware-Blobs für Intel-Grafik

Neuigkeiten rund um GNU/Linux
Antworten
Benutzeravatar
hikaru
Moderator
Beiträge: 13557
Registriert: 09.04.2008 12:48:59

Firmware-Blobs für Intel-Grafik

Beitrag von hikaru » 09.06.2015 10:19:31

Hallo,

gerade habe ich auf Golem diesen Artikel gefunden:
http://www.golem.de/news/skylake-und-br ... 14531.html

Was kauft man denn zukünftig für Hardware, wenn man keine proprietären Blobs will?

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Firmware-Blobs für Intel-Grafik

Beitrag von Lord_Carlos » 09.06.2015 10:27:09

Uhh, wenn ich das richtig verstanden habe ist diese Firmware normal schon vorinstalliert in der hardware. Jetzt wird sie mitgeliefert und muss rein geladen werden.
Ist das ideologisch gesehen schlimmer?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
hikaru
Moderator
Beiträge: 13557
Registriert: 09.04.2008 12:48:59

Re: Firmware-Blobs für Intel-Grafik

Beitrag von hikaru » 09.06.2015 10:38:10

Lord_Carlos hat geschrieben:Uhh, wenn ich das richtig verstanden habe ist diese Firmware normal schon vorinstalliert in der hardware.
Ist das so?

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Firmware-Blobs für Intel-Grafik

Beitrag von Lord_Carlos » 09.06.2015 10:44:03

hikaru hat geschrieben:
Lord_Carlos hat geschrieben:Uhh, wenn ich das richtig verstanden habe ist diese Firmware normal schon vorinstalliert in der hardware.
Ist das so?
So habe ich diesen Text von einem BSD Kernel Hacker verstanden: https://marc.info/?l=openbsd-misc&m=143355112811564&w=2
The firmwares are NOT RUN BY THE HOST CPU.

They are running on the network or other such hardware which you
foolishly purchased!
Die Email ist recht unterhaltsam, lohnt sich zu lesen :D

Ob das auch hier zutrifft weis ich nicht. Aber so habe ich die Situation verstanden.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von catdog2 » 09.06.2015 10:50:56

Uhh, wenn ich das richtig verstanden habe ist diese Firmware normal schon vorinstalliert in der hardware. Jetzt wird sie mitgeliefert und muss rein geladen werden.
Ist das ideologisch gesehen schlimmer?
Kommt drauf an wen du fragst. Ich für meinen Teil sage das ist nicht schlimmer, denn auf welchem Speichermedium der Code liegt beeinflusst dessen Funktion nicht. Ist nur nerviger, wenn sich eine Distribution entscheidet die Blobs nicht direkt mit auszuliefern (was nachvollziehbar ist wenn man sagt man will nur freie Software ausliefern wobei ich etwas Pragmatismus an der Stelle für angebracht halte).

Ansonsten hoffe ich, dass freie Hardware als nächster Schritt nach freier Software bald sinnvoll machbar wird.
Unix is user-friendly; it's just picky about who its friends are.

Benutzeravatar
hikaru
Moderator
Beiträge: 13557
Registriert: 09.04.2008 12:48:59

Re: Firmware-Blobs für Intel-Grafik

Beitrag von hikaru » 09.06.2015 11:02:14

Ich sehe den Zusammenhang nicht. Das einzig Substanzielle das ich aus de Raadts Mail entnehmen kann sind seine schlechten Manieren.

Auf Intel-WLAN-Chips laufen proprietäre Firmwares. Soweit ok. Man kann auch ohne die Chips leben.
Auf Intel-Grafikchips gab es bisher keine austauschbaren Blobs soweit ich weiß, und meiner Erfahrung nach kommt man auch ohne Debianintel-microcode gut zurecht. Das wird laut dem Golem-Artikel mit Skylake anders, denn erstens kann ich darauf kein reines Debian main mehr betreiben wenn Debian seiner Squeeze-Entscheidung treu bleibt und keine Blobs ausliefert und zweitens muss ich nun mit jedem Update des GPU-Blob-Pakets damit rechnen, dass mir neue Hintertüren untergeschoben werden. Eine einmalige Prüfung der Hardware (mit hoffentlich unveränderlicher Firmware) reicht nicht mehr.

Benutzeravatar
smutbert
Moderator
Beiträge: 8311
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von smutbert » 09.06.2015 11:10:32

Der Artikel bei golem erweckt bei mir den Eindruck, die Grafik würde auch ohne Firmware laufen, nur eben nicht alle Funktionen bieten. Ganz allgemein finde ich auch den letzten Absatz aus dem Artikel recht überzeugend
[…]Der Code übernehme schließlich nur Aufgaben, die ansonsten direkt in der Hardware verfügbar wären, und diese lasse sich auch nicht ändern oder austauschen[…]
Quelle
Das läuft doch darauf hinaus, dass die unfreie Hardware das eigentliche Problem ist.
Denn ob die Firmware fest verdrahtet in der Hardware, in einem ROM gespeichert ist oder erst beim Laden des Treibers aus einer Datei in einen Speicher geladen wird, dürfte ideologisch doch tatsächlich keine Rolle spielen — letzteres ist nur lästig für Entwickler die eine GNU/Linuxdistribution anbieten, die ausschließlich aus freier Software bestehen soll.

An die Möglichkeit von Hintertüren habe ich allerdings weniger gedacht.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von catdog2 » 09.06.2015 11:24:16

Eine einmalige Prüfung der Hardware (mit hoffentlich unveränderlicher Firmware) reicht nicht mehr.
Wie willst du die überhaupt Prüfen? Außerdem haben Intel CPUs durchaus übleres versteckt (z.B. die nichtmal so richtig öffentlich dokumentierte Management Engine).
An die Möglichkeit von Hintertüren habe ich allerdings weniger gedacht.
Dann darf man sie halt nicht updaten, wenn man besondere Angst vor nachträglichen Hintertüren hat (im Gegensatz zu schon vorhandenen). Außerdem ist on chip Firmware ist ja auch oft updatebar.
Unix is user-friendly; it's just picky about who its friends are.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Firmware-Blobs für Intel-Grafik

Beitrag von Lord_Carlos » 09.06.2015 11:40:34

Ich sehe ein das es updates umstaendlicher machen kann.

Aber vor mehr ueberwachung und weniger Freie software habe ich keine Angst. Ist nicht unfreier als vorher, und ich habe jetzt auch null, ueberhaupt kein plan ob mein Intel GPU mich ausspioniert oder nicht.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
hikaru
Moderator
Beiträge: 13557
Registriert: 09.04.2008 12:48:59

Re: Firmware-Blobs für Intel-Grafik

Beitrag von hikaru » 09.06.2015 11:41:39

catdog2 hat geschrieben:Wie willst du die überhaupt Prüfen?
Ich hoffe, dass irgendjemand dort mal einen Black-Box-Test macht und laut rumschreit wenn hinten was raus kommt das er aufgrund dessen was er vorne reingesteckt hat nicht erwartet hätte.
Alles andere als ideal, aber besser als nichts. Einmalig mag sowas gehen, aber nicht für jede neue FW-Revision.
catdog2 hat geschrieben:Außerdem haben Intel CPUs durchaus übleres versteckt (z.B. die nichtmal so richtig öffentlich dokumentierte Management Engine).
Und das macht es für dich ok, da noch mehr proprietären Mist reinzustecken?
Ich mag das Argumentationsschema nicht. Wenn du das konsequent zu Ende führst ist Freie Software und im Grunde jede Art von Freiheit für die Katz, denn du wirst überall korrumpierte Elemente finden.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Firmware-Blobs für Intel-Grafik

Beitrag von Lord_Carlos » 09.06.2015 11:58:58

hikaru hat geschrieben:
catdog2 hat geschrieben:Außerdem haben Intel CPUs durchaus übleres versteckt (z.B. die nichtmal so richtig öffentlich dokumentierte Management Engine).
Und das macht es für dich ok, da noch mehr proprietären Mist reinzustecken?
Auf deinen Rechner ist doch nacher genau so viel Proprietaeren mist wie vorher auch.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von catdog2 » 09.06.2015 11:59:42

Ich hoffe, dass irgendjemand dort mal einen Black-Box-Test macht und laut rumschreit wenn hinten was raus kommt das er aufgrund dessen was er vorne reingesteckt hat nicht erwartet hätte.
Naja, wenn da Software läuft die sich je nach stand des Mondes umentscheidet hilft das auch nur bedingt.
Und das macht es für dich ok, da noch mehr proprietären Mist reinzustecken?
Nein. Aber ich finde dieses aus dem Augen aus dem Sinn was in teilen der Freien Software Szene vorherrscht befremdlich. Solange man die Blobs nicht sieht weil sie irgendwo auf einem aufgelöteten Flash liegen ist es voll okay aber sobald man sie auf der Platte hat wird der Weltuntergang heraufbeschworen. Dann wird möglicherweise auch noch eine Alternative gewählt, die noch fragwürdigeres im Petto hat aber man siehts ja nicht.
Ich mag das Argumentationsschema nicht. Wenn du das konsequent zu Ende führst ist Freie Software und im Grunde jede Art von Freiheit für die Katz, denn du wirst überall korrumpierte Elemente finden.
Deswegen sagte ich ja, dass wir Open Hardware brauchen. Außerdem gibt es schon Unterschiede dabei was die korrumpierten Elemente an bestimmten Stellen im Stande sind zu tun und wie weit nachvollziehbar das ist, ganz so schwarz/weiss ist die Welt da auch nicht.
Zuletzt geändert von catdog2 am 09.06.2015 12:01:18, insgesamt 1-mal geändert.
Unix is user-friendly; it's just picky about who its friends are.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von NAB » 09.06.2015 12:01:17

Vielleicht kann man auch erst mal abwarten, bis die Hardware überhaupt offiziell existiert, bevor man Panik macht.

Und auch wenn das Reverse Engineering verboten ist ... vielleicht wird ja einem Open Source Verfechter die Funktion der Hardware-Register im Traum offenbart, und er schreibt dann einen quelloffenen Ersatz. Ich hingegen frage mich eher, warum man als Hersteller nicht auf fest-installierte Firmware setzt. Vermutlich doch nur, weil man seinen Ingenieuren nicht so recht zutraut, eine "fertige" Firmware abzuliefern, und sich eine Hintertür für spätere Korrekturen offenhalten möchte. Das passt zu Intels aktuellem Schleuderkurs, und da würde ich so oder so erst mal gaaaaanz entspannt abwarten, was dabei herauskommt.

Derweil könnte man sich darüber aufregen, dass die Firmware für Mainboards, Festplatten, SSDs, optische Laufwerke, Controller, USB-Sticks u.s.w. auch nicht quelloffen ist. Und etliche Mainboards wurden ja schon ab Werk mit einer Hintertür ausgeliefert ... da hat die "einmalige Prüfung" auch nicht geholfen ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13557
Registriert: 09.04.2008 12:48:59

Re: Firmware-Blobs für Intel-Grafik

Beitrag von hikaru » 09.06.2015 12:32:54

Lord_Carlos hat geschrieben:Auf deinen Rechner ist doch nacher genau so viel Proprietaeren mist wie vorher auch.
Aber der neue Mist verändert sich auch noch alle Nase lang. Und offenbar ist es mehr als vorher, denn bisher war der ja offenbar so überschaubar, dass Intel ihn ruhigen Gewissens als "fertig" eingebrannt hat.
catdog2 hat geschrieben:Naja, wenn da Software läuft die sich je nach stand des Mondes umentscheidet hilft das auch nur bedingt.
Aber wenigstens ist es immer der selbe Mond. Wenn da alle paar Wochen ein neues Blob drauf liegt muss ich jedes mal mit der Prüfung wieder von vorne anfangen. Heute Ganymed, morgen Titan.
catdog2 hat geschrieben:Deswegen sagte ich ja, dass wir Open Hardware brauchen.
Die haben wir aber in dem Bereich leider nicht. Und wir können nur mit dem Arbeiten was wir haben. Und proprietäre Firmware-Blobs finde ich eben tendenziell einen Rückschritt. Vielleicht ist es gar nicht schlimmer als vorher, weil jetzt nur das austauschbar implementiert wird was früher fest verdrahtet war. Aber die schönere Lösung wäre doch eindeutig, wenn Intel die Firmware offenlegen würde.
Insofern ist auch die Haltung der FSF diesbezüglich verständlich, auch wenn sie in der Praxis teils kontraproduktiv sein mag: Wenn ein Hersteller schon veränderliche Firmwares veröffentlicht, dann bitte mit Code.
catdog2 hat geschrieben:Außerdem gibt es schon Unterschiede dabei was die korrumpierten Elemente an bestimmten Stellen im Stande sind zu tun und wie weit nachvollziehbar das ist
Das kannst du doch gar nicht beurteilen, wenn du nicht reingucken kannst.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von catdog2 » 09.06.2015 12:46:41

Aber wenigstens ist es immer der selbe Mond. Wenn da alle paar Wochen ein neues Blob drauf liegt muss ich jedes mal mit der Prüfung wieder von vorne anfangen. Heute Ganymed, morgen Titan.
Oder beliebig anderers, wasweissich z.B. Zeit. Dann kannst du 2015 toll rumtesten, wenn sich das verhalten erst 2016 ändert. Oder sehr speziell hingebastelte Netzwerkpakete (evtl zusätzlich durch bestimmte timings zwischen mehreren speziellen usw.) wo die Wahrscheinlichkeit dass das beim fuzzing auffällt gegen 0 geht.
Insofern ist auch die Haltung der FSF diesbezüglich verständlich, auch wenn sie in der Praxis teils kontraproduktiv sein mag: Wenn ein Hersteller schon veränderliche Firmwares veröffentlicht, dann bitte mit Code.
Wie gesagt ich hab den Eindruck, dass die mit zweierlei maß messen was irgendwie auch niemandem hilft.
Und auch wenn das Reverse Engineering verboten ist
Was es in einigen Rechtsräumen meines Wissens nicht ist, egal was da steht.
Ich hingegen frage mich eher, warum man als Hersteller nicht auf fest-installierte Firmware setzt.
Man spart sich den Festspeicher?
Vermutlich doch nur, weil man seinen Ingenieuren nicht so recht zutraut, eine "fertige" Firmware abzuliefern, und sich eine Hintertür für spätere Korrekturen offenhalten möchte.
Naja ist halt so auch Debian wird nicht perfekt ausgeliefert. Außerdem bietet es eine gewisse zusätzliche flexibilität, wenn der Treiber die Firmware lädt, denn dann kann genau die zum Treiber passende Version der Firmware geladen werden ohne sich Gedanken um die auf und Abwärtskompatibilität zwischen den Beiden zu machen.
Derweil könnte man sich darüber aufregen, dass die Firmware für Mainboards, Festplatten, SSDs, optische Laufwerke, Controller, USB-Sticks u.s.w. auch nicht quelloffen ist. Und etliche Mainboards wurden ja schon ab Werk mit einer Hintertür ausgeliefert ... da hat die "einmalige Prüfung" auch nicht geholfen ...
Eben, das sind im Zweifel Wichtigere Dinge (teilweise wie bei Platten/SSDs auch obszön komplexes Zeug) als Code der ein bisschen modeswitching in der GPU macht. Solange ganz frei nicht in Scihtweite ist muss man denk ich durchaus Prioritäten setzen.
Unix is user-friendly; it's just picky about who its friends are.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Firmware-Blobs für Intel-Grafik

Beitrag von Lord_Carlos » 09.06.2015 12:52:51

hikaru hat geschrieben:
Lord_Carlos hat geschrieben:Auf deinen Rechner ist doch nacher genau so viel Proprietaeren mist wie vorher auch.
Aber der neue Mist verändert sich auch noch alle Nase lang. Und offenbar ist es mehr als vorher, denn bisher war der ja offenbar so überschaubar, dass Intel ihn ruhigen Gewissens als "fertig" eingebrannt hat.
Ich sehe das Problem mit den veraendern nicht.
Ja, Software und Hardware wird complexer.

Vorher wurde es von einem Firmware blob gesteuert, und es wird auch in Zukunft von einem gesteuert.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von NAB » 09.06.2015 13:52:29

hikaru hat geschrieben:Wenn ein Hersteller schon veränderliche Firmwares veröffentlicht, dann bitte mit Code.
Denk daran, dass wir es hier mit einer Hardware zu tun haben, die vermutlich nie zuvor existiert hat. Den "Code" hast du ... in Form der Firmware-Datei. Es ist nicht bekannt, ob zu dieser unbekannten neuen Hardware-Architektur überhaupt eine Notation existiert, die sich mit Assembler oder gar C vergleichen lässt, und selbst wenn, würde sie dir ohne Compiler oder genaue Dokumentation der Hardware nichts bringen. Genau so gut könnte Intel den Quellcode auf Meroitisch veröffentlichen.

Es läuft also mal wieder auf Open-Hardware hinaus ... aber selbst in seinen gut dokumentierten CPUs könnte Intel irgendein Osterei versteckt haben, das z.B. nur durch eine bestimmte völlig sinnlose Abfolge von Befehlen freigeschaltet wird. Und vielleicht weiß "Herr Intel" davon nicht einmal ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13557
Registriert: 09.04.2008 12:48:59

Re: Firmware-Blobs für Intel-Grafik

Beitrag von hikaru » 09.06.2015 14:35:08

catdog2 hat geschrieben:
Aber wenigstens ist es immer der selbe Mond. Wenn da alle paar Wochen ein neues Blob drauf liegt muss ich jedes mal mit der Prüfung wieder von vorne anfangen. Heute Ganymed, morgen Titan.
Oder beliebig anderers, wasweissich z.B. Zeit. Dann kannst du 2015 toll rumtesten, wenn sich das verhalten erst 2016 ändert. Oder sehr speziell hingebastelte Netzwerkpakete (evtl zusätzlich durch bestimmte timings zwischen mehreren speziellen usw.) wo die Wahrscheinlichkeit dass das beim fuzzing auffällt gegen 0 geht.
Das geht auch bei veränderlicher FW. Auf der anderen Seite kriegt fest verbratene Firmware keine Updates um z.B. neue Aufgaben zu übernehmen oder Zieladressen zu ändern.
Du kannst es drehen wie du willst, das Missbrauchspotenzial bei veränderlicher FW ist immer höher als bei statischer.
catdog2 hat geschrieben:
Insofern ist auch die Haltung der FSF diesbezüglich verständlich, auch wenn sie in der Praxis teils kontraproduktiv sein mag: Wenn ein Hersteller schon veränderliche Firmwares veröffentlicht, dann bitte mit Code.
Wie gesagt ich hab den Eindruck, dass die mit zweierlei maß messen was irgendwie auch niemandem hilft.
Sie sind die Free Software Foundation. Die Unterscheidung zwischen SW und HW mag 30 Jahre nach der Gründung angesichts von FW etwas ulkig wirken, aber sie haben sich nun mal explizit für SW entschieden, und irgendwo müssen sie da die Grenze ziehen. Die wird immer beliebig, weil prinzipiell unscharf sein.
Lord_Carlos hat geschrieben:Ich sehe das Problem mit den veraendern nicht.
Ja, Software und Hardware wird complexer.

Vorher wurde es von einem Firmware blob gesteuert, und es wird auch in Zukunft von einem gesteuert.
Auch hier wieder: Das Missbrauchspotenzial veränderlicher FW ist höher, weil ihr nachträglich neue Aufgaben gegeben werden können.
NAB hat geschrieben:Denk daran, dass wir es hier mit einer Hardware zu tun haben, die vermutlich nie zuvor existiert hat. Den "Code" hast du ... in Form der Firmware-Datei. Es ist nicht bekannt, ob zu dieser unbekannten neuen Hardware-Architektur überhaupt eine Notation existiert, die sich mit Assembler oder gar C vergleichen lässt, und selbst wenn, würde sie dir ohne Compiler oder genaue Dokumentation der Hardware nichts bringen. Genau so gut könnte Intel den Quellcode auf Meroitisch veröffentlichen.
Was Assembler angeht, bin ich funktionaler Analphabet. Aber das bedeutet doch nicht, dass ich den Code generell für unnütz halte. Vielleicht kann ein anderer was damit anfangen.
Wenn hier einer einen Support-Thread aufmacht und du um Logs bittest, dann akzeptierst du doch auch nicht dass er das verweigert, nur weil ER sie nicht versteht.
NAB hat geschrieben:Es läuft also mal wieder auf Open-Hardware hinaus ... aber selbst in seinen gut dokumentierten CPUs könnte Intel irgendein Osterei versteckt haben, das z.B. nur durch eine bestimmte völlig sinnlose Abfolge von Befehlen freigeschaltet wird. Und vielleicht weiß "Herr Intel" davon nicht einmal ...
Natürlich ist das möglich, aber das ist doch keine Argumentation gegen die Offenlegung veränderlicher Firmwares.

Nehmt es mir bitte nicht übel, aber ihr alle drei legt ein Argumentationsmuster an den Tag, das in meinem Kopf folgendes Bild erzeugt:
Wir vier stehen (barfuß und mit kurzen Hosen) bis zu den Knien in der proprietären Scheiße - noch dazu freiwillig, denn woanders stünden wir bis zum Hals drin. Da kommt Intel und will noch eine Schippe drauflegen. Ich will das nicht, da sagt ihr mir ich soll mich nicht so haben, denn wir sind ja eh schon dreckig.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Firmware-Blobs für Intel-Grafik

Beitrag von Lord_Carlos » 09.06.2015 14:42:06

Intel tauscht die Schaufel aus, steckst immernoch genau so Tief drinne.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von NAB » 09.06.2015 15:37:26

hikaru hat geschrieben:
NAB hat geschrieben:Denk daran, dass wir es hier mit einer Hardware zu tun haben, die vermutlich nie zuvor existiert hat. Den "Code" hast du ... in Form der Firmware-Datei. Es ist nicht bekannt, ob zu dieser unbekannten neuen Hardware-Architektur überhaupt eine Notation existiert, die sich mit Assembler oder gar C vergleichen lässt, und selbst wenn, würde sie dir ohne Compiler oder genaue Dokumentation der Hardware nichts bringen. Genau so gut könnte Intel den Quellcode auf Meroitisch veröffentlichen.
Was Assembler angeht, bin ich funktionaler Analphabet. Aber das bedeutet doch nicht, dass ich den Code generell für unnütz halte. Vielleicht kann ein anderer was damit anfangen.
Wenn hier einer einen Support-Thread aufmacht und du um Logs bittest, dann akzeptierst du doch auch nicht dass er das verweigert, nur weil ER sie nicht versteht.
Dementsprechend müsste ich auch das Systemd-Binärformat akzeptieren ... was ich auch tun würde. Ich müsste dann gucken, ob ich daraus schlauer werde als "ER".

Genau das hast du aber schon. In Form der Firmware.

Ich will darauf hinaus, dass das übliche "Open-Source"-Gerede davon ausgeht, dass die Funktionsweise der ausführenden Maschine bekannt ist. Dies ist hier aber nicht der Fall (vermute ich). Der "Quellcode" würde also nichts bringen. Eventuell existiert er nicht mal.

Um so wünschenswerter wäre die Offenlegung der Funktionsweise der zugrundeliegenden Hardware ... und die Abschaffung von "Reverse-Engineering"-Verboten und Software-Modifikations-Verboten ... und dann bist du mitten drin in der aktuellen politischen Diskussion und der Frage, welcher Lobbyverband uns regiert ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Firmware-Blobs für Intel-Grafik

Beitrag von rendegast » 09.06.2015 17:26:33

Wir haben iasl, davon ein dekompiliertes ACPI, und es werden beim Rekompilieren entsprechende Fehler gelistet.
Diese Fehler sind aber höchstens hinsichtlich ihres Syntax versuchsweise "fixbar",
ohne daß die Funktion des Codes eigentlich klar ist.
(Und eventuell sollen/müssen diese Fehler ja genau so sein.)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

dufty2
Beiträge: 1706
Registriert: 22.12.2013 16:41:16

Re: Firmware-Blobs für Intel-Grafik

Beitrag von dufty2 » 09.06.2015 19:26:02

Wer tiefer in das Thema "Open Hardware" einsteigen möchte, dem sei hier Krste Asanović (http://www.eecs.berkeley.edu/~krste/) und seine RISC-V ISA (instruction set architecture) ans Herz gelegt.
Mit lowRISC (pun intended ;) ) soll evtl. 2016 ein developer board samt debian port verfügbar sein.
Mal schauen.

Antworten