Ein UEFI-Loader für FreeBSD

Yamagi

Possessed With Psi Powers
Teammitglied
Hallo,
wie vielen von euch sicher schon bekannt ist, arbeitet Ed Maste bereits seit längerer Zeit mittels Finanzierung durch die FreeBSD Foundation daran, den im Rahmen mehrerer GSoC-Projekte entwickelten UEFI-Loader für FreeBSD fertigzustellen. Es bedeutet sehr viel Arbeit und ist einem reinen Freizeitprojekt kaum zu schaffen, da ein UEFI-Loader diverse Änderungen im ganzen System benötigt. Es beginnt bei der Übergabe von Ressourcen von der Firmware an den Kernel, geht über die Systemkonsole und endet beim Compiler, welche Microsoft Calling Conventions unterstützen muss. Nach einer Unmenge vorbereitender Änderungen hat Ed Maste heute Nacht den UEFI-Loader selbst committed. Er ist bereits funktionsfähig, hat allerdings noch einige Einschränkungen:
- Derzeit wird nur FreeBSD/amd64 unterstützt. FreeBSD/i386 folgt später.
- Es ist nicht explizit erwähnt, aber Secure Boot wird anscheinend noch nicht unterstützt. Unterstützung ist für die Zukunft geplant, das voraussichtliche Vorgehen findet sich unter https://wiki.freebsd.org/SecureBoot
- Die Dokumentation fehlt noch vollständig.

Code:
Author: emaste
Date: Fri Apr  4 00:16:46 2014
New Revision: 264095
URL: http://svnweb.freebsd.org/changeset/base/264095

Log:
  Support UEFI booting on amd64 via loader.efi
  This is largely the work from the projects/uefi branch, with some
  additional refinements.  This is derived from (and replaces) the
  original i386 efi implementation; i386 support will be restored later.
  Specific revisions of note from projects/uefi:
  r247380:
    Adjust our load device when we boot from CD under UEFI.
    The process for booting from a CD under UEFI involves adding a FAT
    filesystem containing your loader code as an El Torito boot image.
    When UEFI detects this, it provides a block IO instance that points at
    the FAT filesystem as a child of the device that represents the CD
    itself. The problem being that the CD device is flagged as a "raw
    device" while the boot image is flagged as a "logical partition". The
    existing EFI partition code only looks for logical partitions and so
    the CD filesystem was rendered invisible.
    To fix this, check the type of each block IO device. If it's found to
    be a CD, and thus an El Torito boot image, look up its parent device
    and add that instead so that the loader will then load the kernel from
    the CD filesystem.  This is done by using the handle for the boot
    filesystem as an alias.
    Something similar to this will be required for booting from other
    media as well as the loader will live in the EFI system partition, not
    on the partition containing the kernel.
  r246231:
    Add necessary code to hand off from loader to an amd64 kernel.
  r246335:
    Grab the EFI memory map and store it as module metadata on the kernel.
    This is the same approach used to provide the BIOS SMAP to the kernel.
  r246336:
    Pass the ACPI table metadata via hints so the kernel ACPI code can
    find them.
  r246608:
    Rework copy routines to ensure we always use memory allocated via EFI.
    The previous code assumed it could copy wherever it liked. This is not
    the case. The approach taken by this code is pretty ham-fisted in that
    it simply allocates a large (32MB) buffer area and stages into that,
    then copies the whole area into place when it's time to execute. A more
    elegant solution could be used but this works for now.
  r247214:
    Fix a number of problems preventing proper handover to the kernel.
    There were two issues at play here. Firstly, there was nothing
    preventing UEFI from placing the loader code above 1GB in RAM. This
    meant that when we switched in the page tables the kernel expects to
    be running on, we are suddenly unmapped and things no longer work. We
    solve this by making our trampoline code not dependent on being at any
    given position and simply copying it to a "safe" location before
    calling it.
    Secondly, UEFI could allocate our stack wherever it wants. As it
    happened on my PC, that was right where I was copying the kernel to.
    This did not cause happiness. The solution to this was to also switch
    to a temporary stack in a safe location before performing the final
    copy of the loaded kernel.
  r246231:
    Add necessary code to hand off from loader to an amd64 kernel.
  r246335:
    Grab the EFI memory map and store it as module metadata on the kernel.
    This is the same approach used to provide the BIOS SMAP to the kernel.
  r246336:
    Pass the ACPI table metadata via hints so the kernel ACPI code can
    find them.
  r246608:
    Rework copy routines to ensure we always use memory allocated via EFI.
    The previous code assumed it could copy wherever it liked. This is not
    the case. The approach taken by this code is pretty ham-fisted in that
    it simply allocates a large (32MB) buffer area and stages into that,
    then copies the whole area into place when it's time to execute. A more
    elegant solution could be used but this works for now.
  r247214:
    Fix a number of problems preventing proper handover to the kernel.
    There were two issues at play here. Firstly, there was nothing
    preventing UEFI from placing the loader code above 1GB in RAM. This
    meant that when we switched in the page tables the kernel expects to
    be running on, we are suddenly unmapped and things no longer work. We
    solve this by making our trampoline code not dependent on being at any
    given position and simply copying it to a "safe" location before
    calling it.
    Secondly, UEFI could allocate our stack wherever it wants. As it
    happened on my PC, that was right where I was copying the kernel to.
    This did not cause happiness. The solution to this was to also switch
    to a temporary stack in a safe location before performing the final
    copy of the loaded kernel.
  r247216:
    Use the UEFI Graphics Output Protocol to get the parameters of the
    framebuffer.
  Sponsored by:    The FreeBSD Foundation
 
Hi

Muss ich mir dann einen kompletten Brunch aus checken und dann selber ein ISO basteln? Ich schiele bei dem Thema auf Generation 2 VM's mit Hyper-V. Braucht zwingend UEFI. DIe VM's mit Ubuntu 14.04 die das können gehen die Tage in Produktion. Läuft sauberer und schneller.
 
Ja, du musst es manuell zusammenfrickeln. Es ist im Moment nur in 11-CURRENT, ohne Integration in das Release-Bau-Script und ohne Installer-Integration. Kurz gesagt noch so frisch von der Schlachtung, dass es noch tropft.
 
Iiiih ich bin keine Freund von Blutwurst. Dann werde ich wohl noch warten ;) Wäre für produktives angedacht.
 
Besteht damit dann auch die Chance, daß GPT auf kaputtem Lenovo-Bios läuft?
Sofern das Laptop einen nativen UEFI-Boot unterstützt, sind die Chancen gut.

Gibt es denn überhaupt i386-Systeme mit UEFI?
Würde mich wundern. In der x86-Welt kommt da eigentlich kaum Hardware in Frage. Alle Systeme, die UEFI einsetzen, sollten 64-Bit CPUs haben. ARMv8 - aber das ist eine ganz andere Baustelle, die weder dieser Loader noch der Kernel insgesamt unterstützen - spricht ebenfalls 64-Bit. Deshalb wunderten wir uns gestern im IRC auch schon, weshalb man sich die nicht triviale Menge Arbeit überhaupt machen möchte. Ich kann es mir eigentlich nur dadurch erklären, dass evtl. noch immer einige Personen ein natives 32-Bit System benötigen und man ihnen keine Probleme bereiten will, wenn klassischer BIOS-Boot irgendwann nicht mehr unterstützt wird.
 
So schön es wäre meine Partitionen per GPT zu benennen so wäre das für mich als User auch schon alles was mir ein EFI Bootloader aufm T420/X220 bringen würde. Auch so lässt sich ZFS only per MBR booten. Der 10.0 ZFS Installer bietet sogar ZFS only + GELI Installationen in idiotensicher auf der betroffenen Hardware.
 
So schön es wäre, wenn man es sich aussuchen könnte: UEFI wird langfristig die einzige Möglichkeit sein auf gängiger x86 Hardware zu booten. Daher ist diese Entwicklung sowieso irgendwann nötig gewesen.
OpenBSD wehrt sich noch dagegen (berichtigt?, wie lange noch?). Mindestens Theo selbst verweigert sich komplett.
 
Berechtigt? Nein, ich denke nicht. Natürlich kann man an UEFI schön rumkritisieren. Aber realistisch gesehen musste nach mehr als 30 Jahren endlich einmal ein Nachfolger für das eklige, alte BIOS her und das man dort eine etwas umfassendere Lösung als nur eine Minimal-Firmware anstrebt ist logisch. Wenn es nicht UEFI geworden wäre, wahrscheinlich ein beliebiges anderes System ähnlicher Komplexität. Zudem ist es sinnlos sich Realitäten zu verweigern, auch wenn sie einem nicht in den Kram passen. UEFI ist auf x86 da und wird nicht wieder verschwinden. Für ARMv8 / AARCH64 ist es ebenfalls empfohlen und wird wohl zumindest auf den größeren Systemen der "Serverklasse" zum Einsatz kommen. Und wie du schon andeutest, wird die BIOS-Kompatibilität in UEFI wahrscheinlich eher früher als später verschwinden. Jetzt wo Windows XP am Dienstag offiziell für Tod erklärt wird, fällt das Hauptargument das BIOS noch mit durchzuschleppen weg.

Völlig zurecht nörgeln kann man allerdings über Secure Boot. Wobei Secure Boot nicht gleich UEFI ist, was ja leider oft so dargestellt wird. Ich muss zugeben, dass ich die Pläne in FreeBSD Secure Boot zu unterstützen nicht gerade gut heiße. Allerdings kann man sich auch dort kaum verweigern. Denn wenn auch im Moment Secure Boot abschaltbar sein muss, besteht dort das Risiko einer späteren Änderung dieser Policy hin zu verpflichtenden Secure Boot, sobald der Geist erstmal aus der Flasche ist...
 
Selbst an Secure Boot würde ich nicht pauschal rummäkeln. Das key management ist fürn Arsch.
 
Was ist eigentlich mit coreboot? Ist das wieder exklusiv Linux? Ich hatte es zumindest mal als UEFI-Alternative auf dem Radar.
 
Zurück
Oben