Diskussion:Unified Extensible Firmware Interface

aus Wikipedia, der freien Enzyklopädie

Marktdurchdringung veraltet

Der Abschnitt Marktdurchdringung scheint mir veraltet, und es scheint mir dringend angeraten, ihn auf den aktuellen Stand (2015) zu bringen.

Hier nur ein Beispielsatz, der das verdeutlicht: „Inzwischen hat mit dem Mainboard-Hersteller MSI der erste Anbieter ‚normaler‘ x86-Systeme damit begonnen, seine Produkte auf EFI umzustellen.“

--My2Cents (Diskussion) 21:01, 4. Dez. 2014 (CET)

uefi anfällig für Rootkit

http://www.heise.de/newsticker/meldung/BIOS-Rootkit-LightEater-In-den-dunklen-Ecken-abseits-des-Betriebssystems-2582782.html

'Ein Rootkit, das unabhängig vom Betriebssystem operiert, sämtlichen Speicher auslesen kann und durch den Tausch der Festplatte im System nicht gestoppt wird – was klingt wie eine IT-Gruselgeschichte haben zwei Forscher nun öffentlich präsentiert. Zwei Sicherheitsforscher haben äußerst perfiden Schadcode geschrieben, der das BIOS des Rechners infiziert und unabhängig vom gebooteten Betriebssystem alle Fäden in der Hand hält. Damit lässt sich sogar eine komplett im RAM laufendes Live-Linux ausspähen. Zwar benötigt der Angreifer Admin-Rechte, um die Firmware mit den Schadcode zu flashen, dafür gehört ihm dann aber das System so grundlegend, dass selbst der Austausch der Festplatte nicht hilft.'

sollte man mit einarbeiten (nicht signierter Beitrag von 90.153.103.9 (Diskussion) 18:16, 23. Mär. 2015 (CET))

Defekter Weblink

GiftBot (Diskussion) 20:15, 2. Dez. 2015 (CET)

Hinweis entfernen: Es sind genug Belege für Hardwareschaden angeführt

"Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet."

Es sind genug Belege für Hardwareschäden angeführt. Bitte Hinweis löschen 37.5.16.73 22:00, 1. Jan. 2016 (CET)

UEFI-32/64 -> OS-32/64 ?

Artikel:

"Im Allgemeinen kann eine 32-Bit-EFI-Firmware nur ein 32-Bit-Betriebssystem starten und eine 64-Bit-EFI-Firmware nur ein 64-Bit-Betriebssystem. Der einfache Grund dafür ist, dass ein 64-Bit-Kernel im Normalfall nur 64-Bit-Treiber, inklusive (U)EFI-Treiber, verwenden kann. In gleicher Weise benötigt ein 32-Bit-Kernel Treiber, die ebenfalls in 32-Bit vorliegen."

Afaik ist das einfach falsch. Ein 64-Bit-OS kann auch von einem 32-Bit-UEFI gestartet werden, und ein 64-Bit-UEFI kann ein 32-Bit-OS starten. Das bedarf ggf. entsprechend geeigneter Bootloader, die nicht jeder OS-Hersteller bereitstellt. Anschaulich: Wenn Microsoft keine Lust hat, so einen "Cross-Bootlader" zu programmieren, geht's mit Windoof eben nicht. Das bedeutet aber noch lange nicht, dass es prinzipiell unmöglich wäre!

--arilou (Diskussion) 12:35, 27. Mär. 2018 (CEST)

Stimmt, das heißt dann Cross-Bit-Depth-Bootloader. Es gibt aber immer noch ein Problem, das ein Teil des EFI von einem nicht mit der gleichen Bittigkeit laufenden Kernel genutzt werden kann. Siehe auch 32 versus 64 bit and measuring UEFI Secure Boot (englisch, von 2013). Natürlich funktioniert es in der Richtung 32-Bit-EFI und 64-Bit-Betriebssystem, allerdings nicht unbedingt in die andere Richtung, nämlich 64-Bit-EFI und 32-Bit-Kernel. Das liegt offenbar an den UEFI Runtime Services: der Kernel kann UEFI verwenden, allerdings verschluckt sich ein 32-Bit-Kernel an einem 64-Bit-EFI. (Siehe etwa hier für ein praktisches Beispiel.) Umgekehrt geht es, wenn man einen 32-Bit-Bootloader verwendet, der dann einen 64-Bit-Kernel starten kann. Was allerdings nicht geht, ist, einen 64-Bit-Kernel direkt zu starten, was bei 64-Bit-EFI und 64-Bit-Kernel sehrwohl geht.
Und deshalb hatte ich damals "im allgemeinen" geschrieben...
Andreas 00:57, 6. Jan. 2020 (CET)
Nachtrag: Der Kernel muss, weil er die EFI-Firmware ja im EFI-Bootmode abfragen können muss, einen "mixed mode", also einen cross-bit-depth-Modus, unterstützen. Bei Linux ist dies seit 3.15 von 2014 der Fall, siehe Linux 3.15 Kernel Gains EFI Mixed Mode Support. Wenn also ein Bootloader, sagen wir mal GRUB2, ein 32-Bit-EFI-Modul bietet und damit ein 64-Bit-Betriebssystem starten kann, so ist das nur die halbe Miete, denn auch der Kernel fragt ja die Firmware ab. (EFI Runtime und EFI Environment etc. -) Wenn das der Kernel nicht kann, dann geht es auch mit einem entsprechenden Bootloader nicht! Das ist ein entscheidender Unterschied zum BIOS, das im 16-Bit-Real-Mode ist, und bei dem die Betriebssysteme ohne Probleme 16-, 32- und 64-Bit sein können. Bei EFI ist das eben nicht mehr so einfach.
Andreas 01:20, 6. Jan. 2020 (CET)

Ebene logisch unterhalb der Firmware?!?

UEFI ist der Nachfolger von Legacy-BIOS, dem vorherigen inoffiziellen Standard für das Starten eines Kernels, bzw. Betriebssystems. Streng genommen ist UEFI als Firmware-Schnittstelle kein Nachfolger für die gesamte BIOS-Firmware, denn jene sitzt logisch gesehen unterhalb von UEFI (siehe Abbildung). Dennoch spricht man bei UEFI-kompatibler Firmware oft verkürzt von UEFI, weshalb es oft als "Nachfolger von BIOS" bezeichnet wird.

Ist mir mit dieser Änderung, die gut ist, aufgefallen.

Aber stimmt das denn? Soweit mir bekannt, ist UEFI der BIOS-Nachfolger. Beides ist eine Firmware. Von der Ebene her ist diese Firmware das erste, was nach dem Einschalten eines Computers ausgeführt wird.

Die Grafik ist meines Wissens nach zwar richtig, beschreibt aber die Interaktion, nicht den Level, auf dem die Firmware operiert. Denn jedes Gerät hat ja wieder eigene Firmware. Auch das BIOS lädt die Grafikkarten-Firmware, im Fachjargon auch "Grafik-BIOS" bezeichnet (siehe Video BIOS, englisch). Das macht UEFI in gleicher Weise. Und wenn ein Zugriff auf z.B. eine Festplatte oder eine NVMe-SSD stattfindet, so stützt sich dieser auf die Firmware in diesem Datenspeicher. Auch ein CD-ROM-Laufwerk besitzt eine integrierte Firmware, die logischerweise von einer Computer-Firmware, wie das BIOS oder UEFI, genutzt wird (werden muss, weil es gar nicht anders geht)....

Damit befindet sich jedoch das BIOS und UEFI auf derselben Ebene. Das ist auch bei den Alternativen so, etwa bei Open Firmware.

Außerdem ist das Legacy-BIOS das BIOS. Als Legacy-BIOS wird es erst seit EFI/UEFI bezeichnet, da letzteres ersteres nicht nur ersetzt, sondern mit dem CSM (Compatibility Support Module) soger eine Emulation der ersetzten Legacy-Firmware bietet. Daher vermutlich auch die nicht sehr schöne Bezeichnung "Legacy-BIOS".

Wenn sich hier jemand mehr auskennt, bitte jetzt einklinken. Ansonsten ändere ich das dementsprechend nach einer Woche oder so...

Andreas 00:19, 6. Jan. 2020 (CET)