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.