Diskussion:Unified Extensible Firmware Interface/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Unified Extensible Firmware Interface/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Unified_Extensible_Firmware_Interface/Archiv/1#Thema_1

EFI und Windows Vista

Die Behauptung, dass Windows Vista und EFI nicht zusammenarbeiten werden ist wohl nicht richtig.
"Windows Vista soll ebenfalls mit EFI kooperieren" [1]
"Bisher hieß es bei Microsoft, dass sich Unterstützung dafür in der nächsten Windows-Version namens Vista fände." [2]

Ich bitte darum dies zu überprüfen und den Artikel anzupassen.

[1]Christof Windeck: "Wohngemeinschaft" Ct'Magazin, Heft6; S. 146 Abschnitt "Weiche Parallelen" ganz hinten
[2]http://www.heise.de/newsticker/meldung/70670

P.s. Ich hoffe der Kommentar ist in Ordnung, wenn nicht entschuldigt bitte. Ich habe mich mit dem Wikipedia-System bisher nicht befasst.

Dein zweiter Link belegt doch, dass Vista nicht EFI unterstützen wird. Die Server- und die x64-Version werden es irgendwann mal tun. Das kann man vll aufnehmen. Aber die normalen Endanwenderversionen werden es definitiv nicht, zumindest nicht in absehbarer Zeit. Es war mal geplant, aber MS hat es sich im Frühjahr anders überlegt. --Halbm0nd 23:30, 3. Jul 2006 (CEST)

Heise liegt auch oft genug falsch. Ich hab mal auf die neueste Vista Beta geschaut und dort findet sich neben bootmgr auch ein bootmgr.efi. Und ein efi-Verzeichnis mit ein paar Dateien...

Also auf meinem Apple MacBook (hat kein BIOS mehr, sondern nur noch EFI), konnte ich Windows Vista Business nativ also ohne BootCamp, welches für Windows XP ein BIOS simuliert, installieren. Außerdem ist auf der Install-DVD ein Ordner namens EFI. Es ist also FAKT, dass Vista EFI unterstützt!

Vista wird (U)EFI erst mit dem Service Pack 1 unterstützen.--EaPoe 18:09, 17. Jan. 2008 (CET)

Und warum konnte er Vista Business RTM ohne SP1 auf dem MacBook installieren? es gibt zu EFI-Unterstützung in Vista RTM keine echten Quellen, sondern nur irgendwelche Journalistenmutmaßungen, die alle auf eine Pressemitteilung von microsoft zurückführen, nur sagt diese Pressemitteilung vielleicht weniger aus, als allgemein angenommen wird. Wenn deine Analyse von der Empirie widerlegt wird, muss deine Analyse irgendwo falsch sein - egal wie logisch sie ist. Irgendwelche Blogger (ich will die jetzt nicht als Quelle aufführen und auch jetzt nicht den Artikel verändern) hatten auch mal als Neuerung mit SP1 aufgeführt, dass Vista jetzt EFI "auch über Netzwerk booten kann" - woraus man folgern könnte, dass laut deren Meinung Vista auch vorher schon auf EFI, aber nur lokal, booten konnte. Wer weiß, vielleicht hat Microsoft damals nur behauptet, die Möglichkeit von EFI zu starten gestrichen zu haben, damit die Boardhersteller den Wechsel auf UEFI 2.0 forcieren und ihn nicht auf die proprietäre Spezifikation EFI 1.x (die Vista Entwicklungsversionen auch offiziell unterstützten) machen und dort stehen bleiben. Es könnte auch in Microsofts Interesse liegen oder gelegen haben, UEFI gegen EFI durchzusetzen, da Microsoft ja im UEFI-Forum mitsprechen darf. --SvenEric 21:03, 2. Aug. 2008 (CEST)

"C als Programmiersprache (bei BIOS: Assembler)"

Das ist doch Quatsch!? Dem BIOS ist es doch völlig egal, ob es in Assembler oder in C geschrieben wird, im EPROM steckt doch sowieso das Kompilat! Was hindert einen daran, ein BIOS in C oder C++ zu schreiben? Ob BIOS oder EFI, in welcher Sprache man das schreibt sollte doch herzlich wurscht sein? --Afrank99 15:59, 15. Sep 2006 (CEST)

Das denke ich auch. Ob Software nun Kompiliert wird(wie z. B. C, Pascal, Basic), oder gelinkt(wie Assembler). Als Resultat erhält man immer den Maschinen Code. Die Verwendete Programmiersprache ist dem System völlig egal. Habe den Stickpunkt entfernt. 213.39.216.143 00:46, 11. Jun. 2007 (CEST)

Laut den Aussagen der Entwickler (Buch: "Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework", Intel Press) ist C als Sprache vorgesehen, da es die nötigen Anforderungen für systemnahe Programmierung erfüllt. Zudem ist UEFI als Source auf Plattformunabhängigkeit ausgelegt (die APs natürlich nicht, aber auch diese werden in C implementiert), dies wäre in Assembler wohl kaum möglich ... Also: Nein! Es ist nicht egal und auch kein Quatsch! Bitte nicht mit Halbwissen um sich werfen. Es ist ja in Ordnung zu hinterfragen, ob etwas stimmt, aber einfach ohne Plan zu löschen finde ich persönlich dreist. Quelle: "Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework describes a set of robust architectural interfaces, implemented in ->C<-" ( http://www.intel.com/intelpress/sum_efi.htm ) Diesen Nachweis zu finden hat circa 1 Minute gedauert .. aber erstmal löschen, ne? Ansonsten noch: http://www.uefi.org/learning_center/

Nuja, dass Intels unter GPL freigegebene Standard-Implementierung in C ist und Intels Systementwickler C empfehlen, bedeutet trotzdem nicht, dass eine andere Firma nicht sonsteine Sprache verwenden könnte. Dass C recht hardware-nah ist, ist 'ne Binsenweisheit, es wurde ja zur OS-Programmierung erfunden. Und dass einige Basisroutinen wohl praktisch immer in Assembler sein müssen, jaaaa. --arilou 11:56, 20. Jan. 2011 (CET)

Kritik

Evtl. sollte noch auf Kritik an EFI eingegangen werden. Siehe z.B. [1] --84.138.198.72 10:32, 18. Apr. 2007 (CEST)

Gibt es denn wirklich etwas zu kritisieren? Eigentlich nur, dass EFI immmernoch nicht etabliert ist, was vorrangig an den Hardware- und BIOS-Herstellern zu liegen scheint, und daran, dass Microsoft bisher keinen Anreiz gab. Die IT-Industrie unterliegt ja leider einer Diktatur. :-/

Da stimme ich zu. Im Gegensatz zu einem abwiegenden Vorteil/Nachteil hat eine (meist subjektive) hingemotzte Kritik nichts in einem Nachschlagewerk zu suchen... (Schreibt doch jemand mal hin "Intel ist sch***e", nicht gerade hilfreich, oder? ^^) --Carminox 21:48, 20. Sep. 2007 (CEST)

Erster Beitrag: 100% ACK. Bleibt abzuwarten, wie MS seinen Einfluß nützt. Man stelle sich vor: Linux könnte mit vom EFI geladenen Treibern nicht nur die gängigste, sondern _jede_ HW unterstützen, traumhaft! Für mich ein Hauptgrund, Linux von Zeit zu Zeit zu probieren, dann aber wg. nicht vorhandener Treiber entnevt wieder fallen zu lassen (selbst USB kann u.U. Probleme machen -> was soll das?).

meine 2 cent, bis dann

Es ist aber auch zu befürchten, dass einige Unternehmen ihre Monopolstellung durch UEFI ausbauen würden/könnten/werden. Siehe: http://www.freesoftwaremagazine.com/columns/uefi_and_windows_8_bad_news_gnu_linux -- 178.7.2.126 21:54, 31. Okt. 2011 (CET)

EFI ist doch auch open source! der letzte Satz aus der Kritik ist so nicht 100% korrekt! 95.208.111.159 19:56, 2. Feb. 2012 (CET)

Der Standard ist offen. Die Implementierungen durch die HW-Hersteller etc. allerdings nicht zwangsläufig.--Mlorer 14:25, 5. Feb. 2012 (CET)

Nachteile des BIOS (2)

Am meisten irritiert mich das Heruntermachen des (IBM-)BIOS, sowohl in der Wiki, als auch in der Presse. Es fehlen Begründungen, warum das BIOS nicht mehr herhält und warum es nicht erweiterbar ist. Es in einem Artikel einfach so zu behaupten, ohne einen winzigen Satz über die Begründung loszulassen, ist alles andere als informativ... :/ Carminox 21:43, 20. Sep. 2007 (CEST)

Das BIOS kann bspw. nicht übers Netzwerk gestartet werden, was zwar Heimnutzer wenig interessiert, aber in der Industrie durchaus wichtig sein kann. Für den Heimnutzer ist interessant, dass das BIOS nur mit Hilfe eines proprietären Installers, der auf einem vom Mainboardhersteller ausgewählten Betriebssystem (DOS oder Windows) gestartet werden muss, installiert werden kann. So braucht ein Linuxnutzer eine DOS-Bootdiskette um sein BIOS aktualisieren oder fehlerbereinigen zu können. EFI sieht eine eigenständige Update-Möglichkeit vor, die den Nutzer des EFI-Computers unabhängig von bestimmten Betriebssystemen macht. Dazu kommt dann noch, dass das BIOS Betriebssystemstarter nur von MBR-Datenträgern starten kann, was in nicht mehr so ferner Zukunft ein Problem sein wird, weil der MBR maximal 2 GiB große Datenträger (Datenträger, nicht Partitionen) verwalten kann. EFI kann Betriebssysteme auch von GUID Patition Table Datenträgern starten, die wesentlich größer sein können. --88.73.43.218 12:02, 7. Sep. 2008 (CEST)

"Dass das BIOS Betriebssystemstarter nur von MBR-Datenträgern starten kann" ist Quatsch! Das BIOS lädt einen Bootsektor (der AFAIK nicht einmal im ersten physischen Sektor sein muss) und führt ihn aus. Das Partitionsformat ist dem BIOS dabei egal - ganz im Gegensatz zu UEFI, das auf einzelne Partitionen zugreift und weit komplexere Dinge auf der Platte machen möchte. Viele der anderen Punkte unter "Techniken und Möglichkeiten" im Artikel sind ebenfalls nicht UEFI-eigen, sondern genauso mit dem klassischen BIOS möglich. Das ist eine Liste der Eigenschaften von UEFI und keine Liste von Vorteilen gegenüber dem klassischen BIOS! -- 84.178.126.63 11:13, 10. Jul. 2013 (CEST)

EFI vs UEFI

Also jetzt will ich mal wissen was dafür und was dagegen spricht den Artikel UEFI zu benennen.--EaPoe 18:36, 17. Jan. 2008 (CET)

Also da es EFI ja nicht mehr gibt und es jetzt UEFI heisst und auch so verbreitet wird schlage ich vor den Artikel zu verlegen. Da ich aber nicht die Wahrheit für mich gepachtet habe und jeder mal Fehler macht bitte ich euch um eure Meinung (und es ist ja nicht der Fall das hier nichts passiert), anderenfalls werd ich den Artikel verschieben.--EaPoe 23:07, 20. Jan. 2008 (CET)

Naja, Apple Incorporated nutzt in seinen Computern nach wie vor die (veraltete) proprietäre EFI 1.x Spezifikation von Intel, nicht den jüngeren UEFI-Standard. Vielleicht wird Apple irgendwann auf UEFI umstellen, vielleicht aber auch nicht, damit auch UEFI-PC-Hardware ein wenig inkompatibel zu OS X bleibt. Solange Apple Inc. EFI und nicht UEFI verwendet, kann EFI meiner Meinung ruhig der Titel bleiben. --SvenEric 21:06, 2. Aug. 2008 (CEST)

Trusted Computing

Warum liest man weder im Artikel noch hier bei den Diskussionen, dass es fuer dieses Bios seitens der Industrie moeglicherweise eine ganz andere Motivation geben koennte und die beworbenen Vorteile es den Leuten nur schmackhaft machen und ueber andere Ziele hinwegtaeuschen sollen?

EFI wird als Grundlage fuer TC benoetigt. Solange TC kein "owner override" bietet, muss man an den vorgegeben Zielen stark zweifeln. Es stimmt auch nicht, dass DRM nur ein Nebenprodukt ist, wirbt die TCG im Business-Umfeld genau damit. Es kann jedenfalls nicht sein, dass die Industrie die Kontrolle ueber meine Systeme uebernimmt!

Mehr zum geforderten "Owner Override": http://www.eff.org/wp/trusted-computing-promise-and-risk

Ein Kurz-Film, der das grundlegende von TC erklaert: http://www.lafkon.net/tc/

--Tichy 12:35, 20. Jan. 2008 (CET)

Hast du da irgendwelche brauchbaren Quellen? In dem Text steht zu EFI jedenfalls nix. --TheK? 12:41, 20. Jan. 2008 (CET)

Boot Camp (Software)

„Die Beta-Version von Boot Camp, die auch auf Mac OS X 10.4 lief, ist inzwischen nicht mehr lauffähig.“ – Sicher dass das stimmt? Bei mir läuft die Beta-Version nämlich noch einwandfrei. Sie ist zwar nicht mehr kostenlos auf der Apple-Website verfügbar (da kein BETA-Status mehr besteht), aber sie funktioniert immer noch. –Ph. Immel 15:20, 31. Jan. 2008 (CET)

Stimmt wohl. Ich selbst habe zwar leider keinen Intel-Mac mit Tiger drauf, aber ich kenne jemanden, der das hat(te) und bei demjenigen die Beta-Version von Boot Camp auch weiterhin funktionierte. ‣Andreas•⚖ 09:21, 28. Sep. 2016 (CEST)

Kritik #2

Da ohne Diskussion und ohne für mich ersichtlichen Beleg jetzt ein neuer Kritikabsatz in den Artikel gewandert ist, stelle ich mal hier die Frage, ob es für die dortigen Behauptungen wie bspw.: "da etwa mit dem implementierten Netzwerkstacks die theoretische Möglichkeit besteht das etwa Daten unbemerkt vom Betriebssystem an eine beliebige Adresse versendet werden können." irgendeinen Beleg gibt. Ein Link unter dem man nachprüfen könnte, ob das mehr ist als ein Gerücht, wäre schon schön. ;-) --SvenEric 19:36, 12.09.2008 (UTC)

P.S. Insbesondere würde mich interessieren, warum die Herren von LinuxBIOS bzw. Coreboot bei ihrer Kritik an EFI nie die gleichen Kritikpunkte an Open Firmware richten, obwohl das auch einen Network Stack haben kann. Und während jetzt laut diesem neuen Kritikabsatz Banken angeblich Probleme mit EFI-PC haben sollen, weil der Network Stack nicht vom Betriebssystem überwacht wird und deshalb Daten versenden kann, ohne dass das OS das merkt (mal Klartext: ein OS kann auch Daten versenden, ohne dass eine Bankanwendung etwas davon bemerkt), habe ich noch nie gehört, dass Banken Macs, die über zehn Jahre auf OFW liefen und seit einiger Zeit auf EFI laufen, aus diesem Grund ausschließen würden. --SvenEric 19:52, 12.09.2008 (UTC)

Naja, EFI ist nicht so schön offen, wie es aussieht, es ist proprietär. Und da kann man halt alles reinpacken.

Das Unified EFI ist erstmal im wesentlichen eine Implementation eines offenen Standards vom UEFI-Forum. Die BIOS aller Mainboardhersteller sind dagegen durch und durch proprietär, da kann man dann eben auch alles reinpacken. In diesem Punkt gibt es also faktisch keinen Nachteil durch EFI gegenüber BIOS. Was es gibt, ist ein Unterschied der technischen Möglichkeiten - die aber alle auch bei Open Firmware existieren. Ich kann sehr wohl bspw. ein DRM-System für OFW schreiben und das von OFW laden lassen, bevor irgendwas anderes geladen wird. Deswegen würde mich halt mal interessieren, was die Coreboot-Geeks da nun als großen wichtigen Unterschied sehen, den sie ja sehen müssen, da sie es gutheißen, Coreboot dazu zu verwenden, Open Firmware zu starten (wozu man dabei auch immer Coreboot nötig haben sollte) --SvenEric 12:33, 31. Jan. 2009 (CET)

Ganz einfach das eine ist quelloffen und deshalb überprüfbar das andere nicht weil nur mit Mühe reassembliebar. das ist der unterschied liebe UEFI-, Content und Microsoft-Geeks. 37.5.16.73 22:08, 1. Jan. 2016 (CET)

Übrigens jeder darf quelloffene Software implementieren sie GNU-Lizenz. 37.5.16.73 22:09, 1. Jan. 2016 (CET)

Eierlegende Wollmilchsau EFI

Je mehr man sich die neueste Spezifikation UEFI 2.2 durchliest, desto weniger wirkt EFI wie ein einfacher BIOS-Ersatz. Einerseits versucht sie "nur eine Umgebung für den Pre-Boot" zu harmonisieren, andererseits sind ganze Netzwerkstacks bis zu OSI Layer 4 (von ARP über VLAN bis hin zu FTP) und neuerdings auch iSCSI-, PCI-, USB- und Benutzeridentifizierungs-Schnittstellen vorgesehen. So ein Environment entspricht dem Funktionsumfang einer vollwertigen Laufzeitumgebung ähnlich Java oder .NET Framework. Letztenendes könnte man EFI mit einem Root-Kit vergleichen. "Apokalyptische" Sicherheitslücken, Überwachungsskandale und massive Virenbefälle sind vorprogrammiert, spätestens wenn EFI das alte BIOS vollständig vom PC-Markt verdrängt hat, da bin ich mir sicher. --Carminox 03:58, 10. Feb. 2009 (CET)

Fühle mich gelangweilt von deiner Wiederholung der seit Jahren selben "Bedenken". Ob es in älteren Spezifikationen schon drin stand, weiß ich nicht, aber dass das EFI auch aus dem EFI heraus aktualisiert werden können soll, wird seit ettlichen Jahren beworben und Preisfrage: Wie überträgt man wohl die Aktualisierungsdateien? Hmm - doch nicht etwa mit einem FTP? Und warum es verkehrt sein soll, dass EFI Datenträger über USB, SCSI, PCI usw. direkt ansprechen kann, damit ich es aktualisieren kann, ohne für das Aktualisierungsprogramm ein extra Betriebssystem einrichten und booten zu müssen, würde mich auch mal interessieren. Das BIOS, dieses alte ach so sichere Ding, kann von jedem Betriebssystem aus überschrieben (geflasht) werden, wenn für das jeweilige proprietäre BIOS der BIOS-Hersteller das BIOS-Update-Programm für das jeweilige Betriebssystem zur Verfügung stellt - in der Regel gibts sowas im PC-Markt nur für Windows und DOS, wobei DOS-BIOS-Updates von Diskette bei den meisten ausgestorben sind, weil kaum noch jemand Bock hat, extra dafür ein Floppy-Laufwerk anzuschaffen, sodass heutzutage das BIOS in der Regel von Windows aus aktualisiert, also überschrieben, wird. BIOS-Viren, die vom Betriebsystem aufgerufen das BIOS überschrieben, hats schon früher gegeben - EFI ändert daran nichts. Deswegen langweilt mich diese Panikmache. (mit Absicht ohne Signatur - ich bitte darum, dass es so bleibt - weder Datum noch Person oder IP-Adresse haben in diesem Diskussionszweig Bedeutung) P.S. ich hatte gesagt mit Absicht ohne Signatur, die Richtlinnie ist zwar eine Richtline, aber eben keine feste Regel und wenn die Wikipedia die Signatur befehlen will, dann soll sie 1. als feste regel und nicht nur Richlinie definieren und 2. sie gefälligst automatisieren - danke für das Verständnis, falls es welches geben sollte.(nicht signierter Beitrag von SvenEric (Diskussion | Beiträge) 03:04, 2. Mai 2009 (CEST))

Bla, bla, bla... Besser sich vorher informieren, bevor man Argumente im PC-Zeitschriften-Niveau ins Board klatscht. Der kleine Satz in diesem Artikel, nämlich "EFI gilt [...] in sicherheitskritischen Einsatzumgebungen wie etwa in Banken als ein mögliches Sicherheitsrisiko, da etwa mit dem implementierten Netzwerkstacks die theoretische Möglichkeit besteht, Daten unbemerkt vom Betriebssystem an eine beliebige Adresse zu senden." ist nämlich so real, dass man bei der Recherche dauernd auf Aussagen stößt, dass Banken und große Anwaltskanzleien nicht auf Systeme mit EFI umrüsten und teilweise sogar coreboot benutzen. Das Argument DOS-BIOS-Update ist insofern unwichtig, da man seit geraumer Zeit das BIOS per USB-Stick direkt über das BIOS-Menü updaten kann. Und dazu braucht man kein BIOS. Die Frage ist, ob du überhaupt weißt, wie ein BIOS überhaupt funktioniert, um solche Aussagen zu machen. -- 02:03, 18. Jun. 2009 (CEST) (ohne Benutzername signierter Beitrag von Carminox (Diskussion | Beiträge) )

"Bla, bla, bla" Belege? Achso "recherschiere mal", schon klar... tut mir leid, aber solange hier kein beweis dafür steht - und zwar etwas anderes als die Aussage eines coreboot-Entwicklers, bleibt das für mich massivstes FUD gegen UEFI. Aber ganz bestimmt nutzen die coreboot - auf was für Rechnern denn bitte auf dem Toaster oder fernseher für dessen embedded-Board coreboot schon Betastatus angemeldet hat? Das ist so realistisch, wie ein Einsatz von GNU Hurd in Banken. --SvenEric 20:22, 18. Sep. 2009 (CEST)

Meine Begründung habe ich bereits im ersten Post dargelegt. Einen Beleg zu verlangen, dass komplex konzipierte Systeme nicht fehleranfällig wären, ist doch etwas grenzwertig. Ein Indiz dafür, dass EFI unter Umständen mehr Probleme macht als welche löst, könnte man an den Intel Boards selbst sehen: Das Firmwareimage ist 16 MB groß, fast jeden Monat gibt's ein Update und bei einigen Modellen lässt sich Windows 7 nachwievor nicht im EFI-Modus installieren, trotz offizieller UEFI-Unterstützung (bei mir das Board DP43TF mit aktuellster Firmware). Ein weiteres Indiz wäre, dass die gesamte Spezifikation umfangreicher ist als die vollständige für x86 und x86_64 zusammen. Das wirkt so, als ob die Bootumgebung komplexer ist als eine ganze Prozessorarchitektur. Außerdem, Kritik ist kein FUD. Und wer nicht das Werbegeschwafel hinterfragt und darüberhinaus jegliche Kritik versucht zu annullieren, geht vom Verhalten her leicht als Fanboy durch. --Carminox 23:10, 27. Jun. 2010 (CEST)

---

Kann das "GRAPHICS OUTPUT PROTOCOL" von (U)EFI auch noch nach dem Booten verwendet werden, so wie das VBE-BIOS der Grafikkarten?

Gibt es eine Unterstützung für secondary display devices, damit auch der zweite Monitor den Inhalt des zweiten Framebuffers zur Anzeige bringt und läßt es sich steuern ob dabei der clone-mode, multi-mode, span oder extended mode verwendet wird?

Können auch refreshrate controlled Videomodi mit einer CRTC-Parameter-Tabelle verwendet werden, oder muss man sich bei hohen Aulösungen mit 60hz refreshrate begnügen?

Sind die Modenummern für die Videomodi bei (U)EFI einheitlich genormt, oder wird immer nur die Modenummern-Tabelle aus dem Bios der jeweiligen Grafikkarte entnommen, deren Nummern und Auflösungen sich von BIOS zu Bios unterscheiden können?

..

Und die wichtigste Frage: Wann können endlich quanterverschränkte Wollmilch-Eier über die firmware genutzt werden, um darüber ein Bios-Update zu machen? (nicht signierter Beitrag von 85.177.172.81 (Diskussion) 11:48, 26. Feb. 2014 (CET))

Marktdurchdringung

Mir fehlt da der Punkt, dass seitens der Mainboard-Käufer die GUID Partition Table gefordert wird, damit man von >2TB -Platten booten kann. Afaik kann das nur (U)EFI. Oder gibt's "normale BIOSse", die GPT unterstützen? --arilou 12:09, 20. Jan. 2011 (CET)

Stand 7.Feb.2011:

• ASUS - keinerlei Erwähnung von UEFI
• MSI - haben 7 Boards, alle für Sockel 1155 / Sandy Bidge
• ASROCK - nur Fatal1ty P67 (Sandy Bridge)
• BIOSTAR - keinerlei Erwähnung von UEFI
• FOXCONN - keinerlei Erwähnung von UEFI
• GIGABYTE - keinerlei Erwähnung von UEFI
• SAPPHIRE - keinerlei Erwähnung von UEFI
• TYAN - keinerlei Erwähnung von UEFI
• ZOTAC - keinerlei Erwähnung von UEFI

Ob GPT oder MBR ist dem BIOS völlig egal. Dieses lädt einfach den ersten Sektor und führt ihn aus. Wie der Rest der Platte aufgeteilt ist, ob da nun GPT oder was auch immer drauf ist oder wie groß diese ist, ist dabei völlig egal. Das geht auch prima ohne UEFI. Hier boote ich z.B. von einer ST3000DM001-9YN166 (3TB HDD, mit GPT) an einem GA-880GMA-UD2H (Mainboard mit klassichen Award BIOS). Viele der anderen Punkte unter "Techniken und Möglichkeiten" im Artikel sind ebenfalls nicht UEFI-eigen, sondern genauso mit dem klassischen BIOS möglich. Das ist eine Liste der Eigenschaften von UEFI und keine Liste von Vorteilen gegenüber dem klassichen BIOS!! (Einzig Windows mag nicht von einer GPT-Partition via BIOS booten, das ist aber eine Eigenschaft von Windows und nicht dem BIOS geschuldet!) -- 84.178.126.63 10:55, 10. Jul. 2013 (CEST) (11:22, 10. Jul 2013 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Vorteile vom echten BIOS

Also, hier liest man ja so einige Haarsträubende Sachen, also nun mal die Wahrheit.

• Das BIOS läuft (zumindest nach dem Start des Betriebssystems) im Real-Mode, ist somit schneller (Lest euch mal die Intel-Handbücher durch, da sieht man, das bei vielen Befehlen eine "Zeitstrafe" für Protektet Mode dazukommt(weil nämlich immer erst geprüft werden muss, ob Zugriff erlaubt ist).
• Das BIOS ist weniger Störungsanfällig, da es seit 30 Jahren immer weiter Perfektioniert wurde.
• Das BIOS wurde von Menschen geschrieben, das EFI wurde vom C-Kompilierer geschrieben. (Disassembliert mal ein C-Programm, es sträuben sich einen die Nackenhaare, was Kompilierer für einen Stuss fabrizieren)
• Das BIOS ist vor Zerstörung durch Schadprogramme sicher. (ROM kann mann nicht schrieben. Bei Flash-rom geht das nur unter DOS. Klickibunti-Schadprogramme haben also keinen Zugriff).
• Das BIOS ist Kinderleicht zu verwenden, das es im Real-Mode läuft, und Parameter über Register übergeben werden.
• Das BIOS ist UNIX-frei
• Die Schnittstellen zum BIOS sind hervoragend und auch sehr verständlich dokumentiert. Wenn man es Verändert, macht Man Jahrzehnte von Literatur und Bildung unbrauchbar. Milliarden von Menschen wären nicht mehr in der Lage einen Rechner zu benutzen.
• Das BIOS wurde von echten Programmierern geschrieben und Dokumentiert, die Ahnung von dem Haben was sie tun, und wird auch von solchen verwendet.
• Das EFI ist was für Schwuchteln, die Objekt-Orientierte oder Dekriptive Programmiersprachen benutzen, abstrakte Ausdrücke benutzen, kleinschreibung verwenden UNIX (windows NT) benutzen, grafische Benutzeroberflächen brauchen und wohl noch nie einen Lötkolben in der Hand hatten.
• Das BIOS hat schon immer funktioniert, und es gibt gar keinen Grund für irgendwelche Veränderungen. Und alle wirklich Sinnvollen Dinge, die man mit einem Rechner tun Kann,(Büro, Wissenschaft, Ingenieurwesen, Programmierung) konnte man auch schon vor 20 Jahren machen, sogar noch viel besser. Heute scheinen Computerspiele, und Videos zum Selbstzweck zu werden. Wofür braucht man das Alles ? Ein Rechner ist ein Arbeitsgerät, und das ging mit DOS/BIOS, einem 386er und einer EGA-Grafikkarte wesentlich besser als heute. Den ganzen scheiß wie Digitalkameras und Hohe Auflösungen bräuchte es doch gar nicht. Dann würden die Kinder auch wieder drausen im grünen Spielen, wie früher und die ganzen Hartz-4-Empfänger würden anstatt dauernd Pornos- und Facebook runterzuladen sich eine Arbeit suchen und das Internet würde wieder für Sinnvolle Dinge, wie das Verbreiten von Wissen verwendet werden, und nicht zur Unterhaltung oder zum Kommerz, und man könnte auch ohne dieses scheiß Windows darauf zugreifen. Diese Wirtschaftsschwuchteln, die im Internet Leute abzocken und Anglizismen wie "E-Commerce", "Briefing" oder "Buismess" benutzen wären doch gar nicht in der Lage ordendliche Rechner zu bedienen ohne Maus und den ganzen Klicki-Bunti-scheiß geschweige denn ihn zu reparieren. Wer wirklich Ahnung von Programmierung hat der Kann mit einem Befehlszeileninterpreter und Assemblierer umgehen und sieht auch das an dem IBM-Rechnern keine Änderung mehr nötig ist, seit Ende der 80er. (Der vorstehende, nicht signierte Beitrag stammt von 93.243.57.104 (Diskussion • Beiträge) 18:39, 4. Jul. 2011)

erinnert mich irgendwie an "Real programmers don't use Pascal" oder noch davor "Real programmers don't user Fortran" :) --Nobby1805 20:03, 5. Jul. 2011 (CEST)

Was für ein ausgemachter Blödsinn, ich weiß garnicht wo ich anfangen soll. Hast du schonmal was von Fortschritt gehört? Gerade wenn man sich mit IT beschäftigt sollte das kein Fremdwort sein. Was du forderst ist ewiger Stillstand. 30 Jahre sind in der IT eine Ewigkeit und kaum ein Teil der Systemarchitektur hat so lange überlebt, zu recht. BIOS ist nicht die total sichere Festung auf dem Mainboard und kann sehr wohl zerstört werden. Schon 1999 gab es Viren die das schafften. Und gerade erst ist ein neuer Virus aufgetaucht der BIOS infiziert. Ich kann ein BIOS Update ohne Probleme aus Windows aufspielen, dann ist das auch für Schadprogramme kein Problem. Was glaubst du eigentlich wieviele PC User auch nur von der Existenz von BIOS wissen? Glaubst du für die wird sich irgendwas verschlechtern? Und wer BIOS bedienen kann der schafft das auch mit EFI, will ja nicht jeder gleich sein eigenes schreiben. Nur weil du von modernen Entwicklungsmethoden keine Ahnung hast brauchst du hier nicht so rumzuflamen. Man kann die riesigen Programmieraufgaben für heutige Programme nicht mehr wie vor 30 Jahren bewältigen. Wenn dir das nicht passt lad DOS auf deinen alten 386er und sei glücklich damit. Ob du damit allerdings hier noch deine "weisheiten" verbreiten kannst bezweifle ich, aber vielleicht wäre das ein Segen für die Wikipedia. --MrEnglish 18:17, 12. Sep. 2011 (CEST)

Wozu willst du ein überladenes EFI, wenn das BIOS seine Sache genauso gut, aber noch schneller als EFI macht? EFI sorgt nur mit der Netzwerkanbindung + DRM für den FORTSCHRITT hinsichtlich Überwachung der Nutzer. Das geht ja leider mit dem guten alten BIOS nicht, oh wie schade! Ergo, EFI ist der totale Rückschritt: langsam, hässlich und Big-Brother-zertifiziert. Und einfacher als das BIOS kann man die Bedienung nicht machen (abgesehen von der zusätzlichen Steuerbarkeit mittels Maus). (nicht signierter Beitrag von 74.115.0.36 (Diskussion) 15:31, 16. Dez. 2011 (CET))

Sorry, aber das ist faktisch schlicht falsch. Durch einen kompletten Umbau des Treibersystems unter UEFI (bzw. überhaupt erst der Neu-Einführung eines Systems) sind wesentlich schnellere Boot-Zeiten im Vergleich zum Legacy BIOS möglich. Und das ist nur einer von vielen Vorteilen, die u.a. auch mit der Umstellung von Assembler auf C mit einhergehen. Außerdem hat EFI im ersten Schritt auch erstmal nichts mit Netzwerkanbindung und vor allem DRM zu tun. Das ist ungefähr so wie wenn du der Programmiersprache C(++) den Vorwurf machst, dass sich damit auch DRM-Systeme programmieren lassen. Nur weil EFI im Vergleich zum bisherigen BIOS einige weitere technische Möglichkeiten anbietet, liegt es immernoch im Ermessen der einzelnen Hersteller welche Features damit umgesetzt werden. Und letztlich hat es dann der Käufer in seinen Händen, welche Systeme er mit seinem Geld kauft.--Mlorer 15:38, 19. Dez. 2011 (CET)

Ich würde dir ja 100% zustimmen, wenn du nicht die Verbesserung der Bootzeit in einen Zusammenhang mit dem Umstieg von Assembler auf C gebracht hättest ... oder habe ich da einen falschen Bezug hergestellt? --Nobby1805 20:18, 20. Dez. 2011 (CET)

Die Verbesserung der Bootzeit hängt indirekt natürlich schon mit dem Umstieg von Assembler auf C zusammen. Ich gebe dir aber natürlich recht, dass man theoretisch in Assembler wesentlich schneller und effizienter ablaufenden Code schreiben kann als in C. Der Geschwindigkeitsvorteil beim Booten liegt aber nicht darin begründet. Die meiste Zeit beim Starten des PCs geht für die POST Tests und die Initialisierung der Hardware drauf. Und das bisherige BIOS ist dabei nicht in der Lage zu wissen welchen Teil der Hardware wann genau benötigt wird. Deshalb wird einfach alles was vorhanden ist initialisiert und getestet (wobei der genaue Ablauf und Umfang der POST Tests wieder Sache der einzelnen Hersteller ist und es dabei durchaus zu einigen Unterschieden in Umfang und Laufzeit kommen kann). Das braucht natürlich jede Menge Zeit. Durch den Wechsel der gesamten Infrastruktur hin zu UEFI (und das ist in diesem Stil auch nur mit einem Umstieg weg von Assembler möglich), "weiß" die Firmware welche Bestandteile sie wann laden muss oder was auch erst später ggf. vom Betriebssystem geladen werden kann (bzw. wenn bestimmte Ressourcen angefordert werden, können die entsprechenden Treiber einfach "nachgeladen" werden).--Mlorer 13:29, 21. Dez. 2011 (CET)

"Und letztlich hat es dann der Käufer in seinen Händen, welche Systeme er mit seinem Geld kauft." Nicht _der_ Käufer, sondern der Durchschnittskäufer. Und wenn nun ~90% der Käufer einen bestimmten Nachteil gerne mit kaufen, weil er ihnen egal erscheint, haben die restlichen 10% der Käufer durchaus mit dem Pech zu kämpfen, dass sich die Industrie zu 100% auf den Nachteil einstellt, weil die 10% ihnen völlig egal sind und es für _jeden_ gewinnbringender ist, sich auf die 90% zu konzentrieren. -- 84.178.126.63 11:22, 10. Jul. 2013 (CEST)

Artikel umbenennen in UEFI (Unified Extensible Firmware Interface) (erl.)

Ich möchte jetzt doch nochmal anregen den Artikel von EFI in UEFI umzubennen und eine Weiterleitung von EFI nach UEFI zu setzen. Außer den alten, noch laufenden Implementierungen, die auf EFI 1.x basierend, gibt es in diesem Bereich keine Weiterentwicklung mehr. Die Weiterentwicklung wird durch das UEFI Forum ausschließlich an der aktuellen Version 2.3.1 der Spezifikation vorangetrieben. Beleg dafür: Chapter 1, Seite 7 aus Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework (Computer System Design); Zimmer, Vincent; Rothman, Michael; Marisetty, Suresh [ISBN 978-0974364902].--Mlorer 09:52, 21. Okt. 2011 (CEST)

Dann aber besser gleich nach „Unified Extensible Firmware Interface“ umbenennen, damit der Artikel wenigstens (wieder) einen aussagekräftigen Namen bekommt (auch wenn dieser nur englisch ist). In diesem allgemeinen Lexikon hier, also in der deutschsprachigen Wikipedia, lesen nämlich nicht nur IT-Spezis. --92.226.62.90 09:09, 29. Okt. 2011 (CEST)

Der Artikel wurde heute (endlich) umbenannt. Danke. --92.224.250.40 22:05, 6. Jan. 2012 (MEZ)

Vielen Dank dafür!--Mlorer 20:46, 8. Jan. 2012 (CET)

logisch / Logik

"Es sitzt logisch gesehen unterhalb des Betriebssystems" mit logik hat - unterhalb - nichts zu tun. unterhalb, oberhalb hat wohl eher etwas mit raum zu tun oder völlig unverständlich mit reihenfolge. (nicht signierter Beitrag von 89.0.149.16 (Diskussion) 16:41, 21. Dez. 2011 (CET))

Erst einmal habe ich den Kommentar in ein eigenes Kapitel verschoben ... das hat mit EFI bzw. UEFI nicjts zu tun

logsiche Schichten oder Blöcke sind in der Informatik allgemein verbreitet http://de.wikipedia.org/wiki/Schichtenarchitektur und was mit oberhalb bzw. unterhalb gemeint ist ist aus der direkt darunter stehende Zeichnung klar ersichtlich --Nobby1805 21:02, 21. Dez. 2011 (CET)

UEFI und LINUX

"EFI wird auch von Linux unterstützt. Der stabile Zweig des Linux-Kernels bietet seit Version 2.6.25 auch für die x86-Architektur Unterstützung für EFI."

Das ist nicht einmal ganz für EFI richtig. Bei UBUNTU 14.10 ist LINUS nach mehrerenplötzlichen Festplattenfehlkonfigurationen jetzt ganz verschwunden.

Auch nach Heike Jurzik: "Debian GNU/LINUX" Bonn 2015 funktioniert besonders UEFI etweder eingeschrängt, aber meistens extrem instabil. Bitte genuer recherieren und berichtigen 37.5.16.73 21:50, 1. Jan. 2016 (CET)

Stand September 2016 funktioniert nahezu jedes PC-Linux mit UEFI. Ubuntu (englisch) (deutsch), openSUSE (englisch) (deutsch), Linux allgemein (englisch) (deutsch), Fedora (englisch) inkl. Secure Boot (englisch)… ‣Andreas•⚖ 09:31, 28. Sep. 2016 (CEST)

BIOS: kein 64-Bit?

„Das ursprüngliche PC-BIOS erschien 1981 mit dem ersten IBM-PC und wird trotz vieler späterer Erweiterungen den Anforderungen moderner Hardware und Betriebssysteme schon seit einiger Zeit nicht mehr gerecht. Insbesondere ist es nicht 64-bit-tauglich, und weitere Provisorien zum Ausgleich dieses Makels erschienen Hardware-Herstellern (wie Intel oder AMD) nicht mehr tragbar.“

Diesen ersten Absatz im Abschnitt Geschichte verstehe ich nicht. Insbesondere die angebliche Nicht-64-Bit-Tauglichkeit. Ist das BIOS nicht per Defacto-Standard immer im Real Mode, also 16-Bit-Modus? Was macht das BIOS denn 32-Bit-tauglich?!? ‣Andreas•⚖ 09:36, 28. Sep. 2016 (CEST)

Du kannst aus dem 32-Bit-Protected-Mode-OS heraus BIOS-Funktionen aufrufen, weil diese im Virtual 8086 Mode ablaufen können. Im 64-Bit-Protected-Mode gibt es diese Möglichkeit nicht mehr. -- Janka (Diskussion) 13:17, 28. Sep. 2016 (CEST)

Das stimmt wohl. Aber welches 32-Bit- oder 64-Bit-Betriebssystem tut sowas? Es gibt eigentlich nur DOS, das auf BIOS-Calls angewiesen ist, und Windows 9x nutzt mit seinem DOS-Unterbau gelegentlich sicher auch das BIOS aus dem 32-Bit-Modus heraus, aber alles neuere – also alles ab Windows NT – tut dies sicher nicht mehr. ‣Andreas•⚖ 13:42, 28. Sep. 2016 (CEST)

Nachtrag: Anders ausgedrückt: da alle modernen Betriebssysteme das BIOS eigentlich nur zum Starten benutzen – also zum Initialisieren der Hardware – aber die BIOS-Aufrufe nicht mehr verwenden, hat sich wohl AMD beim „Erfinden“ des Long Mode aka 64-Bit-Modus gedacht, dass man den Virtual 8086 Mode auch gleich weglassen kann. Und hatten damit absolut Recht. Das BIOS wurde also nicht nur wegen der veralteten und schwer erweiterbaren Struktur erneuert, sondern auch um schneller den Hauptzweck erfüllen zu können: 1. Initialisieren 2. an Betriebssystem übergeben. (U)EFI macht dies hervorragend, Coreboot ebenso allerdings ist letzteres nicht wirklich gut unterstützt. ‣Andreas•⚖ 13:52, 28. Sep. 2016 (CEST)

Nein. Du brauchst z.B. schon allein für das Auslesen der ACPI-Informationen BIOS-Aufrufe. Für die Kontrolle des System-Management-Mode ebenfalls und bei manchen Boards auch für das TPM. -- Janka (Diskussion)

Wenn das stimmt – was ich nicht bezweifle – dann interessiert es mich aber trotzdem, wie z. B. Windows, Linux und (auf EFI) OS X das macht, dass es auf 32-Bit Firmware (16-Bit BIOS und 32-Bit EFI) diese Informationen bekommt, wenn es als 64-Bit-Betriebssystem läuft. ‣Andreas•⚖ 10:11, 29. Sep. 2016 (CEST)

Nachtrag: Zitat aus en:Advanced Configuration and Power Interface#Architecture: „The firmware-level ACPI has three main components: the ACPI tables, the ACPI BIOS, and the ACPI registers. Unlike its predecessors, such as the APM or PnP BIOS, the ACPI implements little of its functionality in the ACPI BIOS code, whose main role is to load the ACPI tables in system memory. Instead, most of the firmware ACPI functionality is provided in ACPI Machine Language (AML) bytecode stored in the ACPI tables. […] As ACPI also replaces PnP BIOS, it also provides a hardware enumerator, mostly implemented in the Differentiated System Description Table (DSDT) ACPI table. The advantage of a bytecode approach is that unlike PnP BIOS code (which was 16-bit), the ACPI bytecode may be used in any operating system, even in 64-bit long mode.“ ‣Andreas•⚖ 10:27, 29. Sep. 2016 (CEST)

Nachtrag 2: Aus dieser englischen Quelle: „[…] 16-bit PC/AT BIOS where you can boot 16, 32 or 64-bit kernels. In 1982, BIOS was 16-bit, as was Microsoft DOS. The I/O subsystem of DOS was the BIOS, so the DOS run time calling into the 16-bit BIOS int-calls worked out well. DOS was single-threaded, BIOS calls are blocking, and everyone was happy. This worked through Windows 3.1 where DOS was still effectively the kernel. The tension in this model appeared with 32-bit OS's where the kernel would 'thunk' or make down-calls into BIOS when necessary, alongside the 32-bit native driver model with VxD's. With NT and beyond, though, the kernel would have native drivers such that the BIOS was only used for booting. Same story for Linux with its pure native drivers.
And on the point of booting, the first stage OS loader would typically stay in 16-bit mode in order to read the kernel from disk or network using 16-bit BIOS calls. Then the kernel would trampoline into 32-bit mode in order to run the native OS kernel. When x64 came on the scene in the mid-2000's, this trampoline process was extended to go from 16-to-32-to-64 bit mode.
The notable point on PC/AT BIOS and OS run times today is that modern OS kernels do not invoke 16-bit services after the initial loader.“ ‣Andreas•⚖ 10:41, 29. Sep. 2016 (CEST)

Das ist im Bezug auf ACPI auch korrekt. Nach dem "initial loader" braucht man für ACPI das BIOS nicht mehr. Allerdings ist dieser "initial loader" bereits Teil des OS. Ansonsten müsste der Bootloader die ACPI-Tabellen laden und in das OS schieben. Das macht der aber nicht. Für den System Management Mode braucht man das BIOS/EFI weiterhin, während des Betriebs. Und, wie gesagt, bei einigen Boards auch für das TPM. -- Janka (Diskussion) 14:44, 29. Sep. 2016 (CEST)

Okay. Interessant. Ich habe einen älteren Core-Generation Pentium D, der 64-Bit-fähig ist und ein BIOS hat. Auf dem habe ich Windows 7 und Windows 10 in jeweils der 64-Bit-Variante laufen. Das funktioniert wunderbar, obwohl das BIOS ja eigentlich nicht 64-Bit-fähig ist?!?!

Leider habe ich keinen einzigen PC mit 32-Bit-only EFI zur Hand. All meine EFI-Rechner sind mit einem 64-Bit-(U)EFI ausgestattet. Dabei macht gerade ein 32-Bit-EFI unter einem 64-Bit-Betriebssystem offenbar weit mehr Probleme als ein 16-Bit-BIOS unter einem 32- oder 64-Bit-Betriebssystem.

Ich weiß zwar nicht wie, aber offenbar sind diese Probleme im Griff. Zumindest funktioniert auf einem BIOS-Rechner ein 64-Bit-Betriebssystem ausgezeichnet, und ohne Einschränkungen (mit Ausnahme von MBR statt GPT im Fall von Windows). Das steht nun aber konträr zu der Information, dass ein BIOS nicht 64-Bit-tauglich wäre. Was ist hier also wirklich los?!?!? ‣Andreas•⚖ 17:17, 29. Sep. 2016 (CEST)

Nachtrag: Der System Management Mode arbeitet anscheinen unabhängig vom Betriebssystem und wird daher nicht vom Betriebssystem benötigt, sondern von der Firmware ausgelöst und abgearbeitet. Bei TPM kenne ich mich nicht aus, aber was die ACPI-Tabelle betrifft, so scheinen diese nicht ausgeführt zu werden, sondern nur geladen (von einer fixen Start-Adresse), vom Betriebssystem(treiber) interpretiert und genutzt – einige Teile laufen per Interpreter (AML) unabhängig von den Bits (32 oder 64). So zumindest lese ich ACPI. Dass das Betriebssystem für ACPI zurück in den Real Mode (was ja nicht geht) bzw. in den Virtual 86 Mode schalten müsste, damit ACPI ablaufen kann, ist mir neu. Das war vielleicht einmal mit APM so, aber seit ACPI gibt es dieses Problem ja wohl nicht mehr. ‣Andreas•⚖ 17:33, 29. Sep. 2016 (CEST)

Bitte schreib mir die Bezeichnung des Boards, damit ich verifizieren kann, dass dieses Board tatsächlich nur ein 16/32-Bit-BIOS besitzt, und nicht etwa ein UEFI, das sich als BIOS tarnt. Das gab es nämlich auch. Was den SMM angeht, hast du da genau dasselbe Problem wie mit dem ACPI, aber eben während des Betriebs, wenn umkonfiguriert werden soll. Einfachstes Beispiel ist im verlinkten Artikel erwähnt: Drückst du in einem unkonfiguierten SMM den Powerbutton, geht der Rechner *sofort* aus. Daher muss das OS dem SMM mitteilen, dass es lediglich einen Event erhalten möchte, wenn der Powerknopf gedrückt wurde. -- Janka (Diskussion) 23:45, 29. Sep. 2016 (CEST)

Aus der Quelle, einen Satz vor dem Beispiel mit dem Power Button: „The firmware developer decides on the division of responsibilities between firmware and the OS. The firmware could store AML code that tells the OS exactly how to handle every single thing that might happen with the system, leaving the firmware with nothing to do and no real reason for SMM to be used. On the other hand, the AML code could simply tell the OS to tell the chipset to signal an SMI whenever anything happens, at which point the firmware will directly handle the event itself.

Da AML nicht vom Modus, in dem sich der Prozessor befindet, abhängt (Real Mode, Virtual 86 Mode, Protected Mode, Long Mode), funktioniert es eben auch bei einem 64-Bit-Betriebssystem auf einem 16-Bit-BIOS.

Zumindest lese ich das so. Andererseits: mein Board hat ein BIOS, kein UEFI. Das Windows ist 64-Bit. Aber das kann man ja auch einfach mit einer VirtualBox ausprobieren: auch da funktioniert ein 64-Bit-Windows auf einem BIOS-System einwandfrei.

So. Und nun zum 64-Bit Windows: ich habe nirgends gelesen, dass Windows x64 ein (U)EFI-System benötigen würde. Nicht einmal auf der offiziellen Seite mit den Mindestanforderungen.

Eines meiner BIOS-Boards ist ein MSI 890FXA-GD70 (2010), auf dem Windows im 64-Bit-Modus ausgezeichnet funktioniert. Ein etwas älteres ist ein ASUS P5LD2 (2005) – mit einem 64-Bit-fähigen Pentium-D bestückt funktioniert damit Windows 7 x64 ausgezeichnet. Ab der letzten Pentium-D-9xx-Generation sogar Windows 8/8.1 und Windows 10 x64.

Bitte prüfe das gerne. Der Beweis ist ja da vor mir (ich brauche nur einzuschalten).

Übrigens: laut dieser Anleitung (englisch) geht es: „So, booting of any (both 32- and 64-bit!!!) Windows version in BIOS-based systems without EFI is supported.“

Du hast mich da übrigens überascht: du fragst quasi, wo das steht, dass Windows x64 auf einem BIOS-Rechner funktioniert. Tatsächlich findet sich hier wenig Information – es war nämlich damals andersrum interessant: alle Artikel dieser Zeit (Windows Vista x64 und neuer) befassten sich mit (U)EFI-Problemen, ohne dabei explizit zu erwähnen, dass es auf einem BIOS-only-Rechner ohnehin funktioniert (mit entsprechender CPU). Das Thema ist bei EFI eigentlich immer, wie man die Festplatte in GPT nutzen kann. Frühe (U)EFI-Implementierungen waren nämlich meist im Legacy-BIOS-Modes „CSM“ unterwegs, was Windows dazu veranlasst hat, immer auf einem MBR installiert werden zu wollen. Denn nur ein 64-Bit-Windows kann im (U)EFI-Modus auf einem GPT installiert werden. Linux hingegen kann mit einem 64-Bit-Kernel immer auf GPT installiert werden – auch auf einem BIOS-Computer, also ganz ohne (U)EFI. ‣Andreas•⚖ 09:06, 30. Sep. 2016 (CEST)

Noch eine Quelle: Microsoft Windows volumes are limited to 2.2 TB on BIOS based systems with MBR partioning - Servers: „Systems based on the x86 or x86_64 architecture with a traditional BIOS can only boot to a disk volume partitioned with the MBR partitioning scheme.“

‣Andreas•⚖ 09:16, 30. Sep. 2016 (CEST)

Zumindest Windows XP x64 benötigte kein UEFI, laut Microsoft. ‣Andreas•⚖ 09:18, 30. Sep. 2016 (CEST)

Und irgendwie seltsam: wenn Windows 7 x64 einen PC mit UEFI benötigen würde, warum schreibt Microsoft in der FAQ das dann nicht hin? Laut der FAQ ist nur ein 64-Bit-fähiger Prozessor von nöten… ‣Andreas•⚖ 09:20, 30. Sep. 2016 (CEST)

UEFI (Unified Extensible Firmware Interface)

Das Teil heißt seit einiger Zeit nichtmehr EFI sondern UEFI (Unified Extensible Firmware Interface). Vielleicht sollte der Titel und Inhalt entsprechend geändert werden. (Nein ICH mach das nicht, ich hab weder Ahnung von der WikiTechnik noch von UEFI)

Hmm, also bei den Weblink-Quellen wird immer noch EFI genannt. --Muvon53 08:26, 7. Dez 2005 (CET)

Auf den alten Seiten schon, aber: http://www.uefi.org/

In der Presse ist überall nur von EFI die Rede 01.02.2006

Nicht ganz: UEFI ist eine Weiterentwicklung von EFI. Windows Vista x64 (bzw. ein Major Update von Windows Vista) wird UEFI unterstützen, ditto Windows Server "Longhorn". EFI wird in Zukunft wohl nicht mehr unterstützt. Evt. ist aber UEFI irgendwie zu EFI kompatibel, d.h. UEFI-Support impliziert EFI-Support. In diesem Fall sollte der Artikel in United Extensible Firmware Interface umbenannt werden. Falls nicht kompatibel, sollte ein neuer United Extensible Firmware Interface-Artikel angelegt werden und alle relevanten Informationen verschoben werden. Die Verwendung von EFI in den Medien ist meist ungenau bzw. fehlerhaft. -- 62.178.136.129 13:29, 3. Sep 2006 (CEST)

Habe mal Informationen zu UEFI eingebaut Oefe 17:39, 4. Feb. 2007 (CET)

Der Artikel enthält unsaubere Informationen. So wurde OpenFirmware z.B. schon Ende der 80er Jahre von Sun (ich glaube in der Sparc Station 1) verbaut. Das bedeutet, dass EFI viel jünger als OpenFirmware ist.

Nach meiner Kenntnis ist UEFI ein EFI-Dialekt von Intel. -- 2010-07-20 12:36 Tgerke

EFI und Bootloader

Das EFI bietet die Anwahl für Betriebssysteme und startet diese, damit sind Boot-Loader überflüssig.

Ich habe den Satz etwas präzisiert, denn die einzelnen Betriebssysteme brauchen schon noch ihre eigenen Bootloader, z.B. Elilo bei Linux oder boot.efi bei Mac OS X. --Prolinesurfer 10:28, 24. Mär. 2007 (CET)

Nicht unbedingt. Ein EFI Bootloader müsst halt die Spezifika zum Booten der jeweiligen Betriebssysteme kennen, oder natürlich die Betriebssysteme halten sich an einen Standard wie zB. MBI. Zum Beispiel kann GRUB alle Unix-Derivate booten, die MBI-compliant sind. GRUB bootet zwar auch Windows-Derivate, aber die eben nur über Chain-Loading, indem der Windows-eigene Bootcode geladen wird. Letzteres könnte ein EFI Loader aber auch tun.

Mich interessiert insbesondere die Unterstützung von multi-boot-Umgebungen. Beispielsweise 3 verschiedene Windows-Installationen auf einer einzelnen Festplatte. Aufgrund einiger Beschränkungen in den Betriebssystemen mussten bisher GRUB, LILO (etc.) verschiedene Tricks anwenden. Dazu gehörten beispielsweise: Verstecken von Partitionen, virtuelles Drive Swap (bei mehreren Festplatten) usw. Wird das von einem EFI-System ebenfalls unterstützt? [FrancoisL] 2008-02-07

Nachteile des BIOS

Abschnitt "Geschichte": "... heutigen Anforderungen der Computergenerationen als nicht mehr gerecht empfunden werden."

wieso? Weil ein BIOS 16Bit ist, im Real Mode läuft, langsam ist?

Abschnitt "Techniken und Möglichkeiten": Es wird von den _Nachteilen_ des BIOS gesprochen. Auch hier wird nicht weiter erwähnt, welche das sind.

Ich schlage vor, daß ein eigener Abschnitt mit den Nachteilen des BIOS angelegt wird, oder diese zumindest in einem Satz konkretisiert werden.

• langsam (Liegt das am Real-Mode? Oder sind die alten Methoden der Hardware-Erkennung nur so lahm?)
• schlecht wartbar
• nicht erweiterbar
• fehleranfällig
• beschränkte Möglichkeiten (wegen Real-Mode und ROM Größe, nehme ich an)
• bietet viele Funktionen, die nicht mehr gebraucht werden
• bietet viele Funktionen nicht, die gebraucht werden könnten
  • zB. Netzwerk-Unterstützung
  • mehr Informationstabellen für das Betriebssystem
• unschön (kein Grafikmodus)

Bitte die Liste erweitern, wenn jemand etwas weiß.

Dies ist nicht der Artikel vom BIOS also sollte (wenn überhaupt) ein Abschnitt mit den Vorteilen des (U)EFI's gegenüber des BIOS gegründet werden.--EaPoe 18:19, 17. Jan. 2008 (CET)

Wo ist das EFI gespeichert?

Wo sind das EFI, die Treiber usw gespeichert? Flashspeicher? Auf der Festplatte?(Der vorstehende, nicht signierte Beitrag stammt von 62.47.132.68 (Diskussion • Beiträge) 12:47, 17. Sep. 2007)

Da wo auch das BIOS gespeichert war, also im ROM.--EaPoe 18:17, 17. Jan. 2008 (CET)

Bildbeschreibung fehlt bei [[Bild:Efi-simple_de.svg|thumb|right|320px|]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:Efi-simple_de.svg|thumb|right|320px|]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 22:21, 1. Mär. 2009 (CET)

Marktdurchdringung 2

Diese Aussage sagt doch irgendwie gar nichts aus. Es muss doch seitens der Hardwarehersteller noch andere Gründe geben ausser "Wir möchten es nicht" oder bezieht sich das auf die Punkte die unter "Kritik" stehen? --Lastwebpage 00:28, 5. Jun. 2011 (CEST)

Kritik #3

Seit dem Bekanntwerden der universellen Überwachungsbestrebungen von NSA & Co durch Edward Snowden bin ich kritischer geworden: Wer oder was könnte Kontrolle über meine Hardware übernehmen. UEFI liefert alles, was sich ein Fremder zur Kontrolle meines PCs wünschen kann:

• agiert nach außen unsichtbar... in einer Art "Stealth Modus"
• hat eigene Ressourcen*: Prozessor und internes RAM/ROM: siehe INTELs QuarkX1000 als SoC (System on a Chip)
• hat Treiber + Vollzugriff* auf meine Peripherie (Video, RAM, USB, PCI, ... und damit auf HD, Video, Micro,..)
• bleibt auch nach dem Boot-Vorgang aktiv

Quelle: 329678_IntelQuarkCore_HWRefMan_002.pdf via Google zu finden

Ich möchte die Kontrolle über meine persönliche Hardware nur ungern einem komplett ausgestatteteten INTEL-Pentium-PC innerhalb meines PCs geben. Booten find ich gut :)... Aber kann jemand die Frage beantworten, was UEFI nach dem Bootprozess macht bzw. potentiell machen könnte? z.B. meinen Hauptprozessor mikrosekundenweise anhalten, um DMA-Zugriffe zu machen?? Solche "potentielle Gefahren" müssen doch auch in die Kritik rein.

Ich möchte

• mit einer LED sehen, ob und wann der UEFI-Pentium-Prozessor aktiv ist
• das UEFI-System nach dem Bootvorgang ausschalten können (Strom weg) ... als Option zur Laufzeit
• die Ethernet-Verbindung des UEFI auf dem Motherboard willentlich und hardwaremäßig unterbrechen können
• eine Alternative zu INTELs QuarkX-Familie haben

Bin ich der einzige, der solche Wünsche ans UEFI System hat?

An die kompetenten Autoren des UEFI-Artikels hätte ich folgende Bitte:

• Kann man eine Rubrik "Potentielle Gefahren von Uefi" einführen?
• Kann man eine Rubrik "Alternative Controller (SoCs) für Uefi" einführen?
• Kann man eine Rubrik "Kontrollmöglichkeiten des Users über Uefi" einführen?

Vertrauen (Trust) ist gut, (User-)Kontrolle ist besser! Danke :) --Matthias.Ebert (Diskussion) 14:27, 28. Aug. 2014 (CEST)

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)

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))