Man kann ja alles was geschlossen ist, pauschal ablehnen. Das ist legitim aber halt auch ein bisschen verbohrt.
Betrachtet man die Sache mal nüchtern. Gibt es (zumindest meiner Ansicht nach) zwei pragmatische Betrachtungsweisen.
1. Die Firmware ist im Gegensatz zum Treiber vom Betriebssystem unabhängig, dafür aber zu 100% von der Hardware abhängig. Man kann die Firmware also als ausgelagerten Teil der Hardware betrachten. Es ist im Grunde egal, die Funktionalität in proprietären Schaltkreisen steckt oder in einem Firmware-Blob. Im ersten Fall regt sich kein Open Source Gerechtigkeitskämpfer auf, im zweiten schon.
2. Wenn man schon Funktionalität der Hardware auf Software auslagert, dann wäre es natürlich von Vorteil, wenn diese auch offen wäre. Denn damit schafft man die Möglichkeit, dass dritte Fehler finden oder zu Verbesserungen Beitragen.
Natürlich ist bei den Unternehmen immer die Angst da, dass jemand was abkupfert. Oder es gibt auch Verträge, die zur Verschwiegenheit verpflichten. Trotzdem, (wahrschienlich) die meisten uns (oder zumindest ich) glauben daran, dass Offenheit bei Software mehr Vorteile bietet als Nachteile. Voraussetzung ist natürlich, dass man am Markt mit einem guten, fairen und soliden Geschäftsmodell auftritt. Das beste Beispiel dafür ist Redhat. Ihr Haupt-Produkt wurde von der Community kopiert und kostenlos angeboten. Dann hat sich die viel größere Firma Oracle das Produkt kopiert und vertreibt es unter eigener Flagge. Und wo steht Redhat heute? Hat es der Firma geschadet? - Offensichtlich nicht. Sie wächst und gedeiht wie bisher.
Es ist keineswegs egal. Ich erinnere mich an einen Beitrag eines coreboot-Entwicklers, der beschrieb, wie einfach man diversen Schabernack in der Firmware unterbringen kann.
Kosten hindern sie z.B. dran, auch die Möglichkeit das schnelle zu entfernen. Bei der Firmware kannst du dich dumm stellen, war halt mal kurz ein "Fehler" oder ein Mitarbeiter etc.
Gerade bei Netzwerkchips ist so eine Firmware sicherheitstechnisch schon problematisch, aber die NSA dankt!
Technisch gesehen nichts, aber wenn die Schwachstelle direkt ab Werk in die Hardware integriert ist steigt vermutlich die Gefahr dass dies "unerwünschte Dritte" entdecken/veröffentlichen/benutzen.
Von kamome umidori am Mi, 10. Juni 2015 um 12:24 #
Bei den heutigen Strukturgrößen einer CPU dürfte es ein Software-Blob wesentlich leichter machen, das zu disassemblieren - dass das nicht erlaubt ist, stört ja nicht auf technischer Ebene.
Und was wenn es zwei unterschiedliche Firmwareblobs gibt? Einen der regulär an Endkunden verteilt wird (sauber) und einen (unsauber) der gezielt einem entsprechend interessanten Ziel, auf welche Weise auch immer, unterjubelt wird.
Wie schon der Vorposter schreibt, es ist sehr wohl ein Unterschied, ob Funktionalität in Hardware gegossen ist oder in einen Binärblob. Den letzeren kann man per Software-Update austauschen und mit Spionage-Funktionalität versehen - u.U. auch nur bei einem kleinen Kreis interessierender Ziele, damit es weniger auffällt (so wie die NSA-Abteilung "tailored operations" das bereits praktiziert).
Die Flexibilität für den Missbrauch ist bei einer Software natürlich wesentlich größer und Open Source Software ist potentiell immer vertrauenswürdiger. Da stimme ich euch zu und gebe auch zu diesen Aspekt außer acht gelassen zu haben.
Egal ist es lediglich im Sinne der Freiheiten des "Anwenders" (Open Source Entwicklers), ob eine Funktion in der Hardware oder in einem Firmware Blob steckt.
Ober Hard- oder Firmare ist im Sinne der Freiheit des Anwenders leider nicht egal:
Wie soll ich als einfacher User einen binären Blob in einem Windowstreiber auf eine anderes System übertragen? Das geht mit einer Firmware quasi "automatisch".
Ober Hard- oder Firmare ist im Sinne der Freiheit des Anwenders leider nicht egal:
Wie soll ich als einfacher User einen binären Blob in einem Windowstreiber auf eine anderes System übertragen? Das geht mit einer Firmware quasi "automatisch".
Den letzeren kann man per Software-Update austauschen und mit Spionage-Funktionalität versehen
Wenn jemand beliebige Software Updates unterjubeln kann, ist das schon ein unwichtiges Detail. Da ist dann sowieso jede Sicherheitsschranke gefallen. Ob dann das Backdoor in der Firmware, im Treiber oder in einer Applikation steckt macht dann keinen Unterschied mehr.
Ob die Backdoor in der Firmware, im Treiber oder in einer Applikation steckt macht dann keinen Unterschied mehr.
In einer Anwendung oder einem Treiber dürfte sie leichter zu entdecken sein als in einer Firmware, die für ein ganz anderes System geschrieben ist (z.B. den embedded Prozessor auf einer Netzwerkkarte).
1. Die Hardware erledigt ihre Aufgabe durch Festverdrahtung oder die Firmware befindet sich im ROM -› keine Modifikation und damit keine Veränderung auf die Schnelle möglich.
2. Hardware besitzt Firmware im Flash. Diese muss nicht nachgeladen werden, kann aber upgegraded werden -> sehr einfach in sehr kurzer Zeit modifizierbar.
3. Hardware benötigt Firmware im RAM, diese muss zur Laufzeit nachgeladen werden -> sehr einfach und schnell modifizierbar.
Aus Sicherheitsgesichtspunkten ist 1 vorzuziehen, da dies einige Angriffsmöglichkeiten wie z.B. über fingierte "Sprengstofftests" beim Notebook am Flughafen wirksam unterbindet.
Der Unterschied zwischen 2 und 3 ist hingegen nicht hoch. Möglicherweise ist 3 sogar etwas sicherer, da die Firmware auf der Festplatte auf Modifikation geprüft werden kann. Wobei wohl zumeist eine Kombination aus 2 und 3 zum Einsatz kommt (2 wird oft benötigt wegen des Bootloaders für 3) und dann nicht mehr gewährleistet ist, dass überhaupt die hochgeladene Firmware zum Einsatz kommt.
Unter freie Software fällt hingegen nicht mal 1, sobald dort Firmware zum Einsatz kommt, was in den allermeisten Fällen zutreffen wird. Rein durch Hardwareverschaltung funktionierende Komponenten gibt es heute kaum noch, da Hardware dafür viel zu komplex geworden ist.
Die Frage aus Sicht freier Software ist zumeist nur noch, bekommt man es mit dass unfreie Software zum Einsatz kommt, weil man sie selbst hochladen muss oder bekommt man es nicht mit, weil sie sich bereits in der Hardware befindet.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 10. Jun 2015 um 00:14.
Firmware-Dateien hin oder her: Andere Geräte laden sich ihre Firmware aus einem integrierten ROM. Wieder andere Geräte nutzen Controller, die durch ihre Bauart bedingt die Steueraufgaben übernehmen, die auch mit Hilfe von Firmware und einer kleinen CPU umgesetzt werden könnten.
Der Inhalt von verlöteten ROMs ist genauso wenig Open Source, wie der Bauplan eines Controllers. Wo ist hier der Unterschied zur Firmware auf dem Rechner, außer dass hier kein Dateisystem für herhalten muss?
Wer Wert darauf legt, nur offene Firmwares zu nutzen, müsste somit genau genommen auf einen klassischen PC verzichten.
GNU empfiehlt ausschließlich Distributionen, die keine solchen binären Firmware-Dateien enthalten. In der Praxis bedeutet das für die Benutzer, dass bestimmte Hardware nicht oder nur eingeschränkt nutzbar ist, so dass man schon beim Kauf darauf achten muss, solche Hardware möglichst zu meiden.
Es zeige mir jemand einen halbwegs aktuellen Computer geschweige denn Laptop wo man keine binäre Firmwareblobs braucht, nicht mal Purism hat das ganz hinbekommen.
Davon gibt es viele. Was GNU da empfiehlt, ist Hardware, die ohne Kernel-Blobs auskommt. Das ging bisher mit Intel-GPUs, bestimmten WLAN/Bluetooth-Modulen und bestimmten Peripheriegeräten ohne Einschränkung der Funktionalität.
Was Purism noch nicht geschafft hat und bislang nur die Gluglug/Libreboot Laptops schaffen ist ein komplett freies BIOS. Aber das ist ja nicht Teil der Distribution.
Ob die Firmware jetzt vom BIOS/UEFI/coreboot geladen wird oder vom Betriebssystem ist meiner Meinung nach nun wirklich nicht mehr relevant. Und so gesehen dürfte es vermutlich wirklich keinen Rechner mehr geben wo es keine Firmwareblobs braucht.
Im Artikel jedenfalls geht es darum, dass die neuen Intel-GPUs jetzt auch im Kernel unfreie Blobs brauchen und man diese somit nicht uneingeschränkt mit einer 100% freien Distribution nutzen können wird.
Die "gammligen X60- und X200-Geräte" laufen komplett ohne unfreie Blobs (mit libreboot). Distributionen ohne Blobs im Kernel (Debian standardmäßig, Trisquel, Parabola, Freedora) laufen auf vielen Geräten ohne Einschränkungen.
Aktuelle Intelsystem booten nicht ohne CPU Microcode Updates.
Einige ältere Systeme haben real existierende Fehler, die man wirklich beheben will, zB hängt sich Via Nano auf, wenn man ohne Update Powerstates wechselt. Einige Intel und AMD Chips haben Fehler, mit denen ein lokaler Angreifer vermutlich Kernelrechte erhalten könnte, für die es Updates gibt.
Ohne die richtigen Bits an der richtigen Stelle im Flash? Ja. Und das schließt neben der Firmware der Management Engine mittlerweile nun mal auch Microcode Updates ein - was anscheinend daran liegt, dass deren Format aufgebohrt wurde, um diverse andere Firmware mitzuschleppen.
Auf aktuellen Plattformen gibt es dafür die FIT (Firmware Interface Table), die auf das µcode-Update zeigt. Das wird dann installiert, bevor die CPU ihre erste x86 Instruktion ausführt und das wird nun wohl auch durchgesetzt.
Von daher: sie liefern keine "nicht-bootfähigen CPUs" aus, jedenfalls nicht mehr als vor ein paar Jahren. Sie haben nur die Anzahl der signierten Binaries erhöht die vorliegen müssen, damit die CPU sich entscheidet, auch arbeiten zu wollen - und dazu gehört mittlerweile halt das µcode Update...
Natütlich ist das so. Ist der Microcode für die CPU nicht im BIOS/UEFI enthalten, startet der Rechner auch nicht. Deshalb kannst du auch nicht jede CPU auf jedes Board stecken - auch wenn der Sockel passt.
Von Marcus Moeller am Mi, 10. Juni 2015 um 08:15 #
Wenn es dir um Coreboot geht, so gibt es eine Vielzahl von Geräten (auch viele aktuelle) die damit laufen. Libreboot ist halt noch etwas mehr (oder eigentlich etwas weniger, nämlich Blobs). Natürlich wird auch innerhalb des Libreboot Projektes permanent an der Unterstützung weiterer Geräte gearbeitet. So läuft aktuell beispielsweise auch schon das T400/T500 und das R500. Mit neuen Releases werden in der Regel auch neue Geräte unterstützt.
Wenn es dir nur darum geht, ein Gerät zu haben, dass ohne Blobs betrieben werden kann, aber ein proprietäres BIOS hat, ist die Auswahl deutlich grösser. Wir bieten im Rahmen unseres Vereins solche (und auch Libreboot fähige) Geräte an:https://freie.computer
Chromebooks der Veyron-Reihe (RK3288 chipsatz). Die gibts leider (noch?) nicht in Deutschland.
Die einzige Binaerkomponente, die man da nicht ohne Aufwand los wird, ist der Grafikkartentreiber - und es ist immerhin moeglich, da es keine Signaturpruefung gibt (http://limadriver.org/ probiert sich daran, auch wenn ARM das laut http://libv.livejournal.com/27461.html zu verhindern versucht).
Von Sie haben vergessen, Ihren Nam am Mi, 17. Juni 2015 um 17:18 #
Immer das Theater mit der Spionage.
Bedenklich ist das Thema aus einem ganz anderen Grund: Je einfacher die nachträgliche Änderung der Funktion ist (Silizium -- ROM -- Flash -- Datei), desto weniger Drang hat der Hersteller, von Anfang an ein stabiles Produkt zu veröffentlichen. Bei der stets steigenden Komplexität zwar verständlich, aber leider für den Kunden nicht sehr angenehm.
Man kann ja alles was geschlossen ist, pauschal ablehnen. Das ist legitim aber halt auch ein bisschen verbohrt.
Betrachtet man die Sache mal nüchtern. Gibt es (zumindest meiner Ansicht nach) zwei pragmatische Betrachtungsweisen.
1. Die Firmware ist im Gegensatz zum Treiber vom Betriebssystem unabhängig, dafür aber zu 100% von der Hardware abhängig. Man kann die Firmware also als ausgelagerten Teil der Hardware betrachten. Es ist im Grunde egal, die Funktionalität in proprietären Schaltkreisen steckt oder in einem Firmware-Blob. Im ersten Fall regt sich kein Open Source Gerechtigkeitskämpfer auf, im zweiten schon.
2. Wenn man schon Funktionalität der Hardware auf Software auslagert, dann wäre es natürlich von Vorteil, wenn diese auch offen wäre. Denn damit schafft man die Möglichkeit, dass dritte Fehler finden oder zu Verbesserungen Beitragen.
Natürlich ist bei den Unternehmen immer die Angst da, dass jemand was abkupfert. Oder es gibt auch Verträge, die zur Verschwiegenheit verpflichten. Trotzdem, (wahrschienlich) die meisten uns (oder zumindest ich) glauben daran, dass Offenheit bei Software mehr Vorteile bietet als Nachteile. Voraussetzung ist natürlich, dass man am Markt mit einem guten, fairen und soliden Geschäftsmodell auftritt. Das beste Beispiel dafür ist Redhat. Ihr Haupt-Produkt wurde von der Community kopiert und kostenlos angeboten. Dann hat sich die viel größere Firma Oracle das Produkt kopiert und vertreibt es unter eigener Flagge. Und wo steht Redhat heute? Hat es der Firma geschadet? - Offensichtlich nicht. Sie wächst und gedeiht wie bisher.
Es ist keineswegs egal. Ich erinnere mich an einen Beitrag eines coreboot-Entwicklers, der beschrieb, wie einfach man diversen Schabernack in der Firmware unterbringen kann.
Und wer hindert die Hersteller daran den "Schabernack" direkt ins Silizium zu packen?
Leider wohl niemand. Trotzdem kann man es denen ja möglichst schwer machen.
Das wäre dann aber auch nicht mehr als Sicherheitstheater...
Kosten hindern sie z.B. dran, auch die Möglichkeit das schnelle zu entfernen.
Bei der Firmware kannst du dich dumm stellen, war halt mal kurz ein "Fehler" oder ein Mitarbeiter etc.
Gerade bei Netzwerkchips ist so eine Firmware sicherheitstechnisch schon problematisch, aber die NSA dankt!
Technisch gesehen nichts, aber wenn die Schwachstelle direkt ab Werk in die Hardware integriert ist steigt vermutlich die Gefahr dass dies "unerwünschte Dritte" entdecken/veröffentlichen/benutzen.
Bei den heutigen Strukturgrößen einer CPU dürfte es ein Software-Blob wesentlich leichter machen, das zu disassemblieren - dass das nicht erlaubt ist, stört ja nicht auf technischer Ebene.
Und was wenn es zwei unterschiedliche Firmwareblobs gibt? Einen der regulär an Endkunden verteilt wird (sauber) und einen (unsauber) der gezielt einem entsprechend interessanten Ziel, auf welche Weise auch immer, unterjubelt wird.
Wie schon der Vorposter schreibt, es ist sehr wohl ein Unterschied, ob Funktionalität in Hardware gegossen ist oder in einen Binärblob. Den letzeren kann man per Software-Update austauschen und mit Spionage-Funktionalität versehen - u.U. auch nur bei einem kleinen Kreis interessierender Ziele, damit es weniger auffällt (so wie die NSA-Abteilung "tailored operations" das bereits praktiziert).
Die Flexibilität für den Missbrauch ist bei einer Software natürlich wesentlich größer und Open Source Software ist potentiell immer vertrauenswürdiger. Da stimme ich euch zu und gebe auch zu diesen Aspekt außer acht gelassen zu haben.
Egal ist es lediglich im Sinne der Freiheiten des "Anwenders" (Open Source Entwicklers), ob eine Funktion in der Hardware oder in einem Firmware Blob steckt.
Ober Hard- oder Firmare ist im Sinne der Freiheit des Anwenders leider nicht egal:
Wie soll ich als einfacher User einen binären Blob in einem Windowstreiber auf eine anderes System übertragen?
Das geht mit einer Firmware quasi "automatisch".
Ober Hard- oder Firmare ist im Sinne der Freiheit des Anwenders leider nicht egal:
Wie soll ich als einfacher User einen binären Blob in einem Windowstreiber auf eine anderes System übertragen?
Das geht mit einer Firmware quasi "automatisch".
Wenn jemand beliebige Software Updates unterjubeln kann, ist das schon ein unwichtiges Detail. Da ist dann sowieso jede Sicherheitsschranke gefallen. Ob dann das Backdoor in der Firmware, im Treiber oder in einer Applikation steckt macht dann keinen Unterschied mehr.
Ob die Backdoor in der Firmware, im Treiber oder in einer Applikation steckt macht dann keinen Unterschied mehr.
In einer Anwendung oder einem Treiber dürfte sie leichter zu entdecken sein als in einer Firmware, die für ein ganz anderes System geschrieben ist (z.B. den embedded Prozessor auf einer Netzwerkkarte).
Man muss drei Situationen unterscheiden:
1. Die Hardware erledigt ihre Aufgabe durch Festverdrahtung oder die Firmware befindet sich im ROM -› keine Modifikation und damit keine Veränderung auf die Schnelle möglich.
2. Hardware besitzt Firmware im Flash. Diese muss nicht nachgeladen werden, kann aber upgegraded werden -> sehr einfach in sehr kurzer Zeit modifizierbar.
3. Hardware benötigt Firmware im RAM, diese muss zur Laufzeit nachgeladen werden -> sehr einfach und schnell modifizierbar.
Aus Sicherheitsgesichtspunkten ist 1 vorzuziehen, da dies einige Angriffsmöglichkeiten wie z.B. über fingierte "Sprengstofftests" beim Notebook am Flughafen wirksam unterbindet.
Der Unterschied zwischen 2 und 3 ist hingegen nicht hoch. Möglicherweise ist 3 sogar etwas sicherer, da die Firmware auf der Festplatte auf Modifikation geprüft werden kann. Wobei wohl zumeist eine Kombination aus 2 und 3 zum Einsatz kommt (2 wird oft benötigt wegen des Bootloaders für 3) und dann nicht mehr gewährleistet ist, dass überhaupt die hochgeladene Firmware zum Einsatz kommt.
Unter freie Software fällt hingegen nicht mal 1, sobald dort Firmware zum Einsatz kommt, was in den allermeisten Fällen zutreffen wird. Rein durch Hardwareverschaltung funktionierende Komponenten gibt es heute kaum noch, da Hardware dafür viel zu komplex geworden ist.
Die Frage aus Sicht freier Software ist zumeist nur noch, bekommt man es mit dass unfreie Software zum Einsatz kommt, weil man sie selbst hochladen muss oder bekommt man es nicht mit, weil sie sich bereits in der Hardware befindet.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 10. Jun 2015 um 00:14.Firmware-Dateien hin oder her: Andere Geräte laden sich ihre Firmware aus einem integrierten ROM. Wieder andere Geräte nutzen Controller, die durch ihre Bauart bedingt die Steueraufgaben übernehmen, die auch mit Hilfe von Firmware und einer kleinen CPU umgesetzt werden könnten.
Der Inhalt von verlöteten ROMs ist genauso wenig Open Source, wie der Bauplan eines Controllers. Wo ist hier der Unterschied zur Firmware auf dem Rechner, außer dass hier kein Dateisystem für herhalten muss?
Wer Wert darauf legt, nur offene Firmwares zu nutzen, müsste somit genau genommen auf einen klassischen PC verzichten.
Keine Zeit zum kommentieren - ich muß da grad was disassemblen!
Davon gibt es viele. Was GNU da empfiehlt, ist Hardware, die ohne Kernel-Blobs auskommt. Das ging bisher mit Intel-GPUs, bestimmten WLAN/Bluetooth-Modulen und bestimmten Peripheriegeräten ohne Einschränkung der Funktionalität.
Was Purism noch nicht geschafft hat und bislang nur die Gluglug/Libreboot Laptops schaffen ist ein komplett freies BIOS. Aber das ist ja nicht Teil der Distribution.
Ob die Firmware jetzt vom BIOS/UEFI/coreboot geladen wird oder vom Betriebssystem ist meiner Meinung nach nun wirklich nicht mehr relevant. Und so gesehen dürfte es vermutlich wirklich keinen Rechner mehr geben wo es keine Firmwareblobs braucht.
Im Artikel jedenfalls geht es darum, dass die neuen Intel-GPUs jetzt auch im Kernel unfreie Blobs brauchen und man diese somit nicht uneingeschränkt mit einer 100% freien Distribution nutzen können wird.
Mit empfehlen meinst du doch nicht die gammligen X60 Geräte.
Die "gammligen X60- und X200-Geräte" laufen komplett ohne unfreie Blobs (mit libreboot).
Distributionen ohne Blobs im Kernel (Debian standardmäßig, Trisquel, Parabola, Freedora) laufen auf vielen Geräten ohne Einschränkungen.
Libreboot Geräte laufen sogar ohne CPU Microcode Updates.
Ich bin mit meinem X60 übrigens sehr zufrieden und finde es alles andere als gammelig. Aber das kommt wahrscheinlich auch ein wenig auf die Pflege an.
Aktuelle Intelsystem booten nicht ohne CPU Microcode Updates.
Einige ältere Systeme haben real existierende Fehler, die man wirklich beheben will, zB hängt sich Via Nano auf, wenn man ohne Update Powerstates wechselt. Einige Intel und AMD Chips haben Fehler, mit denen ein lokaler Angreifer vermutlich Kernelrechte erhalten könnte, für die es Updates gibt.
Ohne die richtigen Bits an der richtigen Stelle im Flash? Ja. Und das schließt neben der Firmware der Management Engine mittlerweile nun mal auch Microcode Updates ein - was anscheinend daran liegt, dass deren Format aufgebohrt wurde, um diverse andere Firmware mitzuschleppen.
Auf aktuellen Plattformen gibt es dafür die FIT (Firmware Interface Table), die auf das µcode-Update zeigt. Das wird dann installiert, bevor die CPU ihre erste x86 Instruktion ausführt und das wird nun wohl auch durchgesetzt.
Von daher: sie liefern keine "nicht-bootfähigen CPUs" aus, jedenfalls nicht mehr als vor ein paar Jahren. Sie haben nur die Anzahl der signierten Binaries erhöht die vorliegen müssen, damit die CPU sich entscheidet, auch arbeiten zu wollen - und dazu gehört mittlerweile halt das µcode Update...
Natütlich ist das so.
Ist der Microcode für die CPU nicht im BIOS/UEFI enthalten, startet der Rechner auch nicht.
Deshalb kannst du auch nicht jede CPU auf jedes Board stecken - auch wenn der Sockel passt.
Nimm es mir nicht krumm, aber die Dinger sind gammelig. Das X60 ist im Jahr 2006 auf den Markt gekommen, das X200 2009.
Da hilft es auch nicht diese schön zu reden, nur weil sie von der FSF empfohlen werden und mit CoreBoot funktionieren.
Wenn es dir um Coreboot geht, so gibt es eine Vielzahl von Geräten (auch viele aktuelle) die damit laufen. Libreboot ist halt noch etwas mehr (oder eigentlich etwas weniger, nämlich Blobs). Natürlich wird auch innerhalb des Libreboot Projektes permanent an der Unterstützung weiterer Geräte gearbeitet. So läuft aktuell beispielsweise auch schon das T400/T500 und das R500. Mit neuen Releases werden in der Regel auch neue Geräte unterstützt.
Wenn es dir nur darum geht, ein Gerät zu haben, dass ohne Blobs betrieben werden kann, aber ein proprietäres BIOS hat, ist die Auswahl deutlich grösser. Wir bieten im Rahmen unseres Vereins solche (und auch Libreboot fähige) Geräte an:https://freie.computer
Chromebooks der Veyron-Reihe (RK3288 chipsatz). Die gibts leider (noch?) nicht in Deutschland.
Die einzige Binaerkomponente, die man da nicht ohne Aufwand los wird, ist der Grafikkartentreiber - und es ist immerhin moeglich, da es keine Signaturpruefung gibt (http://limadriver.org/ probiert sich daran, auch wenn ARM das laut http://libv.livejournal.com/27461.html zu verhindern versucht).
Immer das Theater mit der Spionage.
Bedenklich ist das Thema aus einem ganz anderen Grund: Je einfacher die nachträgliche Änderung der Funktion ist (Silizium -- ROM -- Flash -- Datei), desto weniger Drang hat der Hersteller, von Anfang an ein stabiles Produkt zu veröffentlichen. Bei der stets steigenden Komplexität zwar verständlich, aber leider für den Kunden nicht sehr angenehm.