Welche Neuzeitlaptops haben noch kein UEFI BIOS?

[tuxpad]

Es tut mir leid, auch wenn es zum Teil OT ist, kann ich die Aussagen von b025 nicht unkommentiert lassen.

1. Sind es sogar bei Uralt-Systemen wie einem X60 mit SSD mehr als 3 Sekunden, die Du an Bootzeit gegenüber einem aktuellen UEFI-System gewinnst.
2. Du sagst selbst, wenn im UEFI keine Backdoor steckt, dann eben woanders. Den anderen Teil bekommst Du relativ gut in Griff, in dem Du eine Distribution mit Linux-Libre-Kernel nutzt. Keine Blobs enthalten.
3. Es gibt tatsächlich auch aktuelle Systeme, die mit Libreboot ausgeliefert werden, schau mal bei Librem nach.
4. Neuer ist nicht immer besser. In schlechten UEFI-Implementierungen gibt es ausnutzbare Sicherheitslücken, z.B. auch bei Lenovo vorgekommen. Diese Problematik hast Du mit einem BIOS nicht. Klar hast Du ältere Hardware aber auch weniger Angriffsvektoren. Und wie bereits ausgeführt, auch ältere Hardware kann je nach Einsatzszenario noch mehr als ausreichend sein.
5. Die Erkenntnis, "dass das Internet keine Sicherheitskammer ist" teilen wir. Die Frage ist doch, was leitest Du aus dieser Erkenntnis ab? Wenn ich so argumentiere wie Du, wäre jeder Schutzversuch ja sinnlos, beinah schon eine Ressourcenverschwendung. Ich kann mir nicht vorstellen, dass Du mit ungeschützten Systemen ins Internet gehen wirst. Auch Du wirst zumindest nur mit einem gepatchten und vom Hersteller unterstützen System ins Internet gehen. Andere treiben diese Schutzmaßnahmen eben weiter.

Viele Grüße

tuxpad

 

[cuco]

Also alle UEFI-Implementierungen, die ich hier so habe und hatte, booten schneller als alle BIOS-Implementierungen, die ich so habe und hatte...

Ich kann aber durchaus zustimmen, UEFI ist nicht immer toll. Beim Crossflashen und Updaten von LSI-Controllerkarten für SAS/SATA (übergangsweise Avago, jetzt Broadcom) hat man viel Ärger, wenn der Rechner ein UEFI besitzt. Selbst wenn man alle UEFI-Funktionen abschaltet, funktioniert zwar das Löschen der alten Firmware auf diesen Controllern, nicht aber das Einspielen der neuen Firmware. Abhilfe schafft dann nur, den Flashvorgang mit einem Mainboard zu machen, welches kein UEFI besitzt. Alternativ kann man viele der Flash-Funktionen auch in einer UEFI-Shell machen, die ist aber nerviger zu bedienen als die Software für den DOS-Bootstick (der eben wie gesagt vollständig nur mit echtem BIOS läuft) und gerade für die Crossflash-Vorgänge gibt es auch nicht alle Software für die UEFI-Shell.

Ich habe daher auch noch einen Rechner ganz ohne UEFI für solche Spielereien.

 

[enrico65]

@all:

Die ganze Diskussion um drei Sekunden mehr oder weniger Bootdauer finde ich etwas abseitig. Fakt ist doch, dass das niemanden interessiert - es sei denn, es handelt sich um einen Benchmark-Fetischisten. Auch die Entwicklung bei Coreboot und Libreboot widmet sich ganz anderen Schwerpunkten. Und was die Sicherheit angeht: Da spielt das BIOS als ein Player unter vielen mit. Wer die Zeit und das Geld hat, kann sich halt einen Librem13 auf den Tisch stellen und dann alles vom Browser über Javascript bis hin zur WWAN-Karte manuell härten. Oder man versucht eben, Zeit und Geld in Relation zum individuell erwünschten Nutzen zu setzen.

Gruß
enrico65

P.S.: Wir nehmen uns des Themas Libreboot/Coreboot, Purism et al. in einer der nächsten Ausgaben des LinuxUser an.

 

[tuxpad]

@all:
Die ganze Diskussion um drei Sekunden mehr oder weniger Bootdauer finde ich etwas abseitig. Fakt ist doch, dass das niemanden interessiert - es sei denn, es handelt sich um einen Benchmark-Fetischisten. Auch die Entwicklung bei Coreboot und Libreboot widmet sich ganz anderen Schwerpunkten. Und was die Sicherheit angeht: Da spielt das BIOS als ein Player unter vielen mit.

Das Thema Bootdauer kam eigentlich nur auf um zu belegen, dass es bereits jetzt bessere Firmware-Implementierungen gibt als UEFI. Und es ist begeisternd, was (ur-)alte
Hardware noch zu leisten vermag. Das das nur ein positiver Nebeneffekt einer anderen - noch wichtigeren - Entwicklung ist, ist klar. Mich persönlich begeistert Libreboot, weil es ein wichtiger Baustein hin zu einem im Sinne der FSF wirklich freien System ist.

Wer die Zeit und das Geld hat, kann sich halt einen Librem13 auf den Tisch stellen und dann alles vom Browser über Javascript bis hin zur WWAN-Karte manuell härten. Oder man versucht eben, Zeit und Geld in Relation zum individuell erwünschten Nutzen zu setzen.

Den letzten Satz verstehe ich jetzt nicht ganz. Würde das nicht auch ein Librem-Käufer tun?

P.S.: Wir nehmen uns des Themas Libreboot/Coreboot, Purism et al. in einer der nächsten Ausgaben des LinuxUser an.

Es wäre nett, wenn Du Bescheid geben könntest, wenn es soweit ist, die Ausgabe würde ich mir gern kaufen. Vielen Dank!

Viele Grüße

tuxpad

 

[enrico65]

@tuxpad:

Das war auch schon immer meine Ansicht aufgrund vieler ständiger Praxistests im Labor, dass die Gleichung "Alt = Langsam" so nicht zutrifft. Fakt ist doch, dass es deutlich spürbare Leistungsschübe nur alle paar Prozessorgenerationen gibt - und die auch dann meist mit Innovationen in anderen Bereichen verknüpft. Bei den CPU-Generationen bedeutet das, dass deutliche Leistungssteigerungen nur spürbar waren (ich meine keine Benchmark-Tests!) beim Wechsel von

a) Coppermine auf Tualatin
b) Northwood auf Prescott (Desktop-Bereich)
c) Dothan auf Yonah
d) Penryn auf Arrandale.

In den Core-Systemen seither ist nur noch optimiert worden im Hinblick auf die Energieeffizienz. Dass ein Arrandale teils langsamer ist als ein Ivy Bridge oder Broadwell liegt meist daran, dass letztere SATA III mit an Bord haben oder dann später sogar NVMe. Aber auch da sind aus Erfahrung die Unterschiede im Sekundenbereich. Mir ist es z.B. auch viel wichtiger, dass ich mit einem 16:10-Display arbeiten kann und nicht auf 16:9 umsteigen muss. Bei der Textarbeit ist man dann nur am Scrollen;-(

Was das manuelle Härten angeht: Wer das System wirklich härten will, muss viel Zeit investieren. Ist mir teils zu viel, weil ich diese Zeit nicht habe. Das meinte ich mit dem Hinweis, Zeit und Geld in Relation zu setzen.

Wenn der Artikel im LinuxUser erscheint, melde ich mich vorab. Der Beitrag ist schon teilweise fertig, in den nächsten Tagen erwarte ich die Notebooks.

Gruß
enrico65

 

[Hans ganz]

Wird das BIOS/UEFI eigentlich in Asembler geschrieben oder in einer Hochsprache?
Nur so am Rande.

 

[deckel]

@enrico65: Danke, darauf freu ich mich schon tierisch

Ich denke was viele sicherheitsbedachte Nutzer an überbordender Firmware stört ist einfach, dass es schwer bis unmöglich ist/wäre (vor allem als nicht Experte) eine mögliche Infektion festzustellen und etwas dagegen zu unternehmen.

 

[tuxpad]

@Hans ganz: Meiner Kenntnis nach ist die Referenz-Implementierung des UEFI von Intel (Tiano) in C geschrieben, die Anwendungen (z.B. UEFI-Shell, Bootloader etc.) sind es auf jeden Fall. Für Coreboot weiss ich es definitiv: Die absoluten Basis-Funktionen, die ca. 1% der Code-Basis ausmachen, sind in Assembler geschrieben, der Rest in C.
Hier noch ein ganz guter Grundlagenartikel zum Thema UEFI.

Viele Grüße

tuxpad

 

[haarp]

Warum gibts eigentlich immer überall diese Menschen, die andere aufgrund ihrer Vorlieben, Sorgen oder Einstellung anzweifeln?

"Will kein UEFI, so ein Depp, Luddit, soll doch Aluhut tragen, ich bin der beste da ich den neusten Shit kaufe, brabbel brabbel"

Den selben Unsinn gabs bei Intel's ME auch. Und wer hier Recht behielt, kam ja letztens raus.

 

[martina]

Ja, es kann "Lücken" im UEFI/Intel ME usw. geben. Was aber in den meisten "Schlagzeilen" nicht erwähnt wird ist, daß die allermeisten dieser "Einbruchsmöglichkeiten" nur aus dem lokalen Netzwerk heraus möglich sind. Die allermeisten Gefahren sind aufgrund der Einfallswege für einen Privatnutzer, der weiß was in seinem Netz angeschlossen ist, in der Praxis nicht wirklich relevant.

 

[haarp]

Sorry, aber da bringen auch Relativierungsversuche nichts. In der Security-Branche gibts kein "ja, aber".

Unsicher ist Mist. Mehr Komplexität und unnötige Komplexität ist Mist. Unauditbarer Code ist Mist. Code der nicht vom Nutzer zu kontrollieren ist, ist Mist. All dies zusammen, was Nutzern auf hinterhältigtste Art und Weise, ohne dessen Wissen, Zustimmung oder Option reingewürgt wird, ist Mist. Intel ME ist Mist. Es ist von Grund auf und architekturell ein Haufen Scheisse, und die einzige würdige Option ist es herauszureißen und abzufackeln. Alles andere ist nur ineffektives Gepose.

Aber dies schweift vom Thema ab.

 

[tuxpad]

Ja, es kann "Lücken" im UEFI/Intel ME usw. geben. Was aber in den meisten "Schlagzeilen" nicht erwähnt wird ist, daß die allermeisten dieser "Einbruchsmöglichkeiten" nur aus dem lokalen Netzwerk heraus möglich sind. Die allermeisten Gefahren sind aufgrund der Einfallswege für einen Privatnutzer, der weiß was in seinem Netz angeschlossen ist, in der Praxis nicht wirklich relevant.

Ein von Dritten bereitgestelltes WLAN (oder LAN-Verbindung im Hotelzimmer), dass Du nutzt, ist per se nun auch schon ein lokales Netz über das Du keine Kontrolle hast. Und im Falle von UEFI hilft es Dir auch nicht, wenn Du ein fremdes (W)LAN nur für eine VPN-Verbindung nutzt. Zum Thema Router-Sicherheit müssen wir uns ja wohl auch nicht mehr ernsthaft unterhalten, oder? Andernfalls mal hier schauen...

Relevant ist das auch für Firmen, die noch keine Netzzugangskontrolle oder nur eine einfache MAC-Authentisierung haben.

Sicher ist zur Ausnutzung von UEFI-Schwachstellen im Moment überdurchschnittliches Know How notwendig. Aber wenn dieses Risiko mit für den Anwender vertetbarem Aufwand umgangen werden kann, ist er gut beraten, dass zu tun. Und da gibt es durchaus Möglichkeiten:

• Rechner mit BIOS nutzen, solange dieser die Anforderungen (mit Aufrüstung) noch erfüllen kann.
• Chromebook kaufen (viele nutzen bereits Coreboot), aufrüsten und dann mit Linux nutzen. Mit TianoCore als Payload könnte man sogar Windows darauf installieren. (Wobei ich zugeben muss, dass ich mich mitdieser Payload noch nicht beschäftigt habe und nicht sicher bin, welche Vorteile das dann gegenüber herkömmlichem UEFI noch bringt.) Im verlinkten Artikel wird auf die BIOS-Emulation Seabios hingewiesen, ggf. zielführender als TianoCore.
• Librem-Gerät kaufen
• Vorhandenes Gerät umflashen, oder bereits geflashtes Gerät von einem Dienstleister wie Vikings kaufen.
• Nur halb ernst gemeint aber technisch interessant: Rapberry PI nutzen, der braucht gar keine Firmware zur Initialisierung.

Schlimm ist in dem Zusammenhang vor allem, dass die vorgenannten Optionen im Firmenumfeld unrealistisch sind, Wirtschaftsspionage auch von "befreundeten Nationen" durchgeführt wird und in diesem Zusammenhang auch das erforderliche Know How keine Hürde mehr darstellt.
Vielleicht wird es ja was mit AMDs Überlegungen, beim Ryzen Coreboot zu unterstützen...

Viele Grüße

tuxpad

 

[visa]

Sorry, aber da bringen auch Relativierungsversuche nichts. In der Security-Branche gibts kein "ja, aber".

Stimme da prinzipiell zu. Man muß sich realistischerweise jedoch die Frage stellen, was es bringt, eine potentielle Hintertür atomsicher abzuriegeln, wenn die Bude vorn offensteht wie ein Scheunentor. Das letzte Risiko ließe sich nur durch Nichtnutzung ausschließen und da ist es dann wie im Leben selbst: No risk no fun.

Auch in den äteren Geräten ist bspw. die Fernwartungstechnik (Intel AMT) bereits enthalten - dort mit Sicherheit ungepatcht. Doch bis wohin soll man dann zurück gehen? Diese TPM-Geschichte mit dem Security Subsystem, die ja auch für rege Auseinandersetzungen gut war, geht bis zum T23 zurück.

Letztlich gibt es weder sichere Hard- noch Software. Ich würde mir freilich auch weitestgehende Transparenz bei Design und Implemetierung solcher Funktionen wünschen, aber mit diesen Vorstellungen sind wir leider eine Minderheit. Für die Mehrheit stehen halt offenbar andere Interessen im Vordergrund und wir können ohne erheblichen Mehraufwand nur mit dem arbeiten was es gibt.

 

[schoerg]

Die ganze Diskussion um drei Sekunden mehr oder weniger Bootdauer finde ich etwas abseitig. Fakt ist doch, dass das niemanden interessiert - es sei denn, es handelt sich um einen Benchmark-Fetischisten.

+
Wer schnell booten will soll Standby (und Ruhezustand bei SSD) verwenden.