Ausführungsumgebung vor dem Bootvorgang

In der Informatik ist die Preboot Execution Environment (PXE; oft ausgesprochen als /ˈpɪksiː / Pixie ) , kurz PXE - Boot ( Pixie - Boot ) , eine Spezifikation, die eine standardisierte Client-Server-Umgebung beschreibt. Diese startet eine Software - Assembly , die aus dem Netzwerk abgerufen wird, auf PXE-fähigen Clients. Clientseitig wird lediglich eine PXE-fähige Netzwerkkarte (NIC) benötigt. Zudem werden einige wenige branchenübliche Netzwerkprotokolle wie DHCP ( Dynamic Host Configuration Protocol ) und TFTP ( Trivial File Transfer Protocol ) verwendet.

Das PXE-Konzept entstand in den Anfängen von Protokollen wie BOOTP /DHCP/TFTP und ist seit 2015 Bestandteil des UEFI-Standards ( Unified Extensible Firmware Interface ). In modernen Rechenzentren ist PXE die am häufigsten gewählte Methode ^{[ 1 ]} zum Starten, Installieren und Bereitstellen von Betriebssystemen.

Seit den Anfängen von Computernetzwerken besteht ein ständiger Bedarf an Clientsystemen , die geeignete Software-Images mit den entsprechenden Konfigurationsparametern starten können. Diese werden beim Systemstart von einem oder mehreren Netzwerkservern abgerufen . Hierfür muss der Client eine Reihe von Pre-Boot-Diensten nutzen, die auf branchenüblichen Netzwerkprotokollen basieren. Zusätzlich muss das Network Bootstrap Program (NBP), das initial heruntergeladen und ausgeführt wird, mithilfe einer Client -Firmware- Schicht (auf dem per PXE zu startenden Gerät) erstellt werden. Diese Schicht bietet eine hardwareunabhängige, standardisierte Möglichkeit zur Interaktion mit der umgebenden Netzwerk-Bootumgebung. Die Verfügbarkeit und Einhaltung von Standards sind in diesem Fall entscheidende Faktoren für die Gewährleistung der Systeminteroperabilität des Netzwerk-Bootvorgangs.

Einer der ersten Versuche in diesem Bereich war das Bootstrap-Laden mithilfe des TFTP-Standards RFC 906 (veröffentlicht 1984). Dieser legte den 1981 veröffentlichten TFTP-Standard ( Trivial File Transfer Protocol ) RFC 783 als Standard-Dateiübertragungsprotokoll für das Bootstrap-Laden fest. Kurz darauf folgte der Bootstrap-Protokollstandard RFC 951 (BOOTP) (veröffentlicht 1985), der es einem disklessen Client-Rechner ermöglichte , seine eigene IP-Adresse, die Adresse eines TFTP-Servers und den Namen eines NBP (Non-Based Provisioning) zu ermitteln, der in den Speicher geladen und ausgeführt werden sollte. Schwierigkeiten bei der Implementierung von BOOTP führten unter anderem schließlich zur Entwicklung des Dynamic Host Configuration Protocol (DHCP)-Standards RFC 2131 (veröffentlicht 1997). Der wegweisende TFTP/BOOTP/DHCP-Ansatz erwies sich als unzureichend, da er damals die erforderliche standardisierte Client-Seite der Bereitstellungsumgebung nicht definierte.

Die Preboot Execution Environment (PXE) wurde von Intel im Rahmen des Wired for Management- Frameworks ^{[ 2 ]} eingeführt und ist in der von Intel und SystemSoft veröffentlichten Spezifikation beschrieben. PXE Version 2.0 erschien im Dezember 1998, das Update 2.1 im September 1999 ^{[ 3 ].} Die PXE-Umgebung nutzt verschiedene Standard-Client-Server-Protokolle, darunter DHCP und TFTP (definiert durch RFC 1350 von 1992). Innerhalb des PXE-Schemas ist die Client-Seite der Bereitstellung integraler Bestandteil des PXE-Standards und wird entweder als BIOS- Erweiterung der Netzwerkkarte (NIC) oder in UEFI- Code für aktuelle Geräte implementiert. Diese spezielle Firmware-Schicht stellt dem Client die Funktionen einer grundlegenden universellen Netzwerkschnittstelle (UNDI), eines minimalistischen UDP / IP- Stacks, eines Preboot-Clientmoduls (DHCP) und eines TFTP-Clientmoduls zur Verfügung. Zusammen bilden sie die PXE- Programmierschnittstellen (APIs), die vom NBP für die Interaktion mit den Diensten des Server-Pendants der PXE-Umgebung verwendet werden. Der geringe Durchsatz von TFTP , insbesondere bei Verbindungen mit hoher Latenz , wurde zunächst durch die TFTP-Blockgrößenoption (RFC 2348, Mai 1998) und später durch die TFTP-Fenstergrößenoption (RFC 7440, Januar 2015) verbessert. Dadurch können potenziell größere Nutzdaten übertragen und der Durchsatz gesteigert werden.

PXE basiert auf einer Kombination aus branchenüblichen Internetprotokollen, nämlich UDP/IP, DHCP und TFTP. Diese Protokolle wurden ausgewählt, da sie sich leicht in die Firmware der Netzwerkkarte (NIC) des Clients implementieren lassen, was zu standardisierten, ressourcenschonenden PXE -ROMs führt. Standardisierung, geringe Größe der PXE-Firmware-Images und deren niedriger Ressourcenverbrauch zählen zu den wichtigsten Designzielen. Dadurch kann die Clientseite des PXE-Standards auf einer Vielzahl von Systemen identisch implementiert werden – von leistungsstarken Client-Computern bis hin zu ressourcenbeschränkten Einplatinencomputern (SBC) und System-on-a-Chip (SoC).

DHCP dient dazu, dem Client die passenden Netzwerkparameter und insbesondere die IP-Adresse des TFTP-Servers bereitzustellen, auf dem das initiale Bootstrap-Programm (NBP) und zugehörige Dateien zum Download bereitstehen. Um eine PXE-Bootstrap-Sitzung zu starten, sendet die DHCP-Komponente der PXE-Firmware des Clients ein DHCPDISCOVER-Paket mit PXE-spezifischen Optionen an Port 67/UDP (DHCP-Server-Port). Darin werden die erforderlichen Netzwerkkonfigurations- und Netzwerkstartparameter abgefragt. Die PXE-spezifischen Optionen kennzeichnen die initiierte DHCP-Transaktion als PXE-Transaktion. Standardmäßige DHCP-Server (ohne PXE-Unterstützung) können mit einem regulären DHCPOFFER-Paket antworten, das Netzwerkinformationen (z. B. die IP-Adresse) enthält, jedoch nicht die PXE-spezifischen Parameter. Ein PXE-Client kann nicht starten, wenn er nur eine Antwort von einem DHCP-Server ohne PXE-Unterstützung erhält.

Nach dem Parsen des DHCPOFFER eines PXE-fähigen DHCP-Servers kann der Client seine eigene Netzwerk-IP-Adresse, IP-Maske usw. festlegen und anhand der empfangenen TFTP-Server-IP-Adresse und des Namens des NBP auf die im Netzwerk befindlichen Bootressourcen verweisen. Anschließend überträgt der Client den NBP per TFTP in seinen Arbeitsspeicher (RAM), verifiziert ihn gegebenenfalls (z. B. über UEFI Secure Boot ) und bootet schließlich davon. NBPs sind lediglich das erste Glied in der Bootkette und fordern in der Regel per TFTP einige wenige ergänzende Dateien an, um ein minimales Betriebssystem (z. B. Windows PE oder einen einfachen Linux-Kernel mit initrd ) zu starten. Dieses minimale Betriebssystem lädt seine eigenen Netzwerktreiber und den TCP/IP-Stack. Die restlichen Anweisungen zum Booten oder Installieren eines vollständigen Betriebssystems werden nun nicht mehr über TFTP, sondern über ein robustes Übertragungsprotokoll (wie HTTP , CIFS oder NFS ) bereitgestellt.

Die PXE-Client/Server-Umgebung wurde so konzipiert, dass sie sich nahtlos in eine bestehende DHCP- und TFTP-Serverinfrastruktur integrieren lässt. Dieses Designziel stellte eine Herausforderung im Umgang mit dem klassischen DHCP-Protokoll dar. Unternehmens-DHCP-Server unterliegen üblicherweise strengen Richtlinien, die das einfache Hinzufügen der für eine PXE-Umgebung erforderlichen zusätzlichen Parameter und Regeln erschweren. Aus diesem Grund wurde im PXE-Standard das Konzept der DHCP-Umleitung oder „ProxyDHCP“ entwickelt. Die Idee hinter ProxyDHCP besteht darin, die PXE-DHCP-Anforderungen auf zwei unabhängig voneinander betriebene und verwaltete Servereinheiten aufzuteilen:

1. Der klassische DHCP-Server stellt allen beim Systemstart auftretenden DHCP-Clients IP-Adresse, IP-Maske usw. zur Verfügung .
2. Der Proxy-DHCP-Server stellt die TFTP-Server-IP-Adresse und den Namen des NBP nur den per PXE identifizierten Boot-Clients bereit .

In einer DHCP-plus-ProxyDHCP-Serverumgebung ^{[ 3 ] :18} sendet der PXE-Client zunächst ein einzelnes PXE-DHCPDISCOVER-Paket und empfängt zwei komplementäre DHCPOFFER-Pakete: eines vom regulären, nicht PXE-fähigen DHCP-Server und ein zweites vom ProxyDHCP-Server. Beide Antworten zusammen liefern die erforderlichen Informationen, damit der PXE-Client seinen Bootvorgang fortsetzen kann. Dieser nicht-invasive Ansatz ermöglicht die Einrichtung einer PXE-Umgebung, ohne die Konfiguration eines bereits funktionierenden DHCP-Servers zu verändern. Der ProxyDHCP-Dienst kann auch auf demselben Host wie der Standard-DHCP-Dienst ausgeführt werden; selbst in diesem Fall handelt es sich jedoch um zwei unabhängig voneinander ausgeführte und verwaltete Anwendungen. Da zwei Dienste nicht denselben Port 67/UDP auf demselben Host verwenden können, läuft der ProxyDHCP-Dienst auf Port 4011/UDP. Der ProxyDHCP-Ansatz hat sich in einer Vielzahl von PXE-Szenarien, von Unternehmens- bis hin zu Heimnetzwerken, als äußerst nützlich erwiesen.

PXE wurde unter Berücksichtigung verschiedener Systemarchitekturen konzipiert. Die Spezifikation Version 2.1 definierte Architekturkennungen für sechs Systemtypen, darunter IA-64 und DEC Alpha . Allerdings deckte PXE v2.1 nur IA-32 vollständig ab . Trotz dieser scheinbaren Unvollständigkeit hat Intel kürzlich beschlossen, PXE in der neuen UEFI- Spezifikation umfassend zu unterstützen und die PXE-Funktionalität auf alle EFI/UEFI-Umgebungen auszuweiten. Die aktuelle Spezifikation 2.4A der Unified Extensible Firmware Interface (UEFI), Abschnitt 21 „Netzwerkprotokolle – SNP, PXE und BIS“, definiert die Protokolle, die den Zugriff auf Netzwerkgeräte während der Ausführung in der UEFI-Bootumgebung ermöglichen. Zu diesen Protokollen gehören das Simple Network Protocol (SNP), das PXE Base Code Protocol (PXE) und das Boot Integrity Services Protocol (BIS). ^{[ 4 ] [ 5 ]} Heutzutage basiert die Client-Architekturerkennung in einer PXE-Umgebung selten auf den ursprünglich in der PXE-v2.1-Spezifikation enthaltenen Kennungen. Stattdessen sollte auf jedem Computer, der vom Netzwerk booten soll, die DHCP-Option 93 so eingestellt sein, dass die Architektur des Clients angegeben wird. Dadurch kann ein PXE-Server (beim Bootvorgang) die genaue Architektur des Clients anhand des ersten Netzwerk-Bootpakets ermitteln. ^{[ 6 ]}

Mit dem Aufkommen von IPv6 hat sich DHCP zu DHCPv6 weiterentwickelt ; der Bedarf an Optionen zur Unterstützung von PXE innerhalb des neuen DHCP-Protokolls wurde im Jahr 2010 adressiert. ^{[ 7 ]}

Die ursprüngliche PXE-Client-Firmware-Erweiterung war als Option-ROM für das IA-32- BIOS konzipiert . Ein PC wurde daher ursprünglich PXE-fähig, indem eine Netzwerkkarte (NIC) mit einem solchen PXE-Option-ROM installiert wurde. Heute ist der PXE-Client-Code entweder direkt in die Firmware der Netzwerkkarte oder als Teil der UEFI-Firmware auf dem Mainboard integriert.

Obwohl die ursprüngliche Client-PXE-Firmware von Intel entwickelt und stets kostenlos als verlinkbares IA32- Objektcode- Modul im Product Development Kit (PDK) bereitgestellt wurde, entstanden im Laufe der Jahre in der Open-Source-Welt nicht standardkonforme Projekte wie gPXE / iPXE mit eigenen ROMs. Während Intel-basierte ROMs die Client-Seite des PXE-Standards seit über 20 Jahren implementieren, waren einige Anwender bereit, auf zusätzliche Funktionen zugunsten von Stabilität und PXE-Standardkonformität zu verzichten. ^{[ 8 ]}

Seit Version 2.1 ist PXE weit verbreitet; heutzutage findet man praktisch keine Netzwerkkarte mehr ohne PXE-Firmware. Dank der Verfügbarkeit kostengünstiger Gigabit-Ethernet- Hardware (Netzwerkkarten, Switches , Router usw.) ist PXE im Vergleich zu den klassischen Alternativen wie CD , DVD und USB-Stick die schnellste Methode zur Installation eines Betriebssystems auf einem Client .

Im Laufe der Jahre wurde PXE-Unterstützung in mehrere große Projekte integriert, darunter:

• Alle wichtigen Linux-Distributionen.
• OpenVMS auf HPE Integrity und x86-64 Hardware.
• Microsoft Remote Installation Services (RIS)
• Microsoft Windows-Bereitstellungsdienste (WDS)
• Microsoft Deployment Toolkit (MDT)
• Microsoft System Center Configuration Manager (SCCM)

Im Hinblick auf die NBP-Entwicklung gibt es mehrere Projekte, die Boot-Manager implementieren, welche erweiterte Bootmenü-Funktionen, Skripting-Funktionen usw. bieten können:

• Syslinux PXELINUX
• gPXE / iPXE

Alle oben genannten Projekte, die mehrere Betriebssysteme starten/installieren können, arbeiten nach dem Prinzip „Bootmanager – Bootloader“. Der ursprüngliche NBP ist ein Bootmanager, der seine eigene Konfiguration abrufen und ein Menü mit Startoptionen bereitstellen kann. Der Benutzer wählt eine Startoption aus, woraufhin ein betriebssystemabhängiger Bootloader heruntergeladen und ausgeführt wird, um den gewählten Startvorgang fortzusetzen.

Apple hat ein sehr ähnliches Netzwerk-Bootverfahren unter dem Dach der Boot Server Discovery Protocol (BSDP)-Spezifikation entwickelt . BSDP v0.1 wurde ursprünglich im August 1999 von Apple veröffentlicht ^{[ 9 ]} , die letzte Version v1.0.8 im September 2010 ^{[ 10 ].} Mac OS X Server enthielt ein Systemtool namens NetBoot . Ein NetBoot-Client nutzt BSDP, um dynamisch Ressourcen zu beziehen, die das Starten eines geeigneten Betriebssystems ermöglichen. BSDP baut auf DHCP auf und verwendet herstellerspezifische Informationen, um die zusätzlichen NetBoot-Funktionen bereitzustellen, die im Standard-DHCP nicht vorhanden sind. Das Protokoll ist in der Client-Firmware implementiert. Beim Systemstart bezieht der Client eine IP-Adresse per DHCP und ermittelt anschließend Boot-Server mithilfe von BSDP. Jeder BSDP-Server antwortet mit Boot-Informationen, die Folgendes umfassen:

• Eine Liste bootfähiger Betriebssystemabbilder
• Das Standard-Betriebssystemabbild
• Das aktuell vom Client ausgewählte Betriebssystemabbild (sofern definiert)

Der Client wählt ein Betriebssystem aus der Liste aus und sendet eine entsprechende Nachricht an den Server. Der ausgewählte Boot-Server antwortet mit der Boot-Datei, dem Boot-Image und allen weiteren Informationen, die zum Herunterladen und Ausführen des ausgewählten Betriebssystems benötigt werden.

Microsoft hat mit der Boot Information Negotiation Layer (BINL) eine eigenständige Erweiterung der PXE-Umgebung geschaffen. BINL ist als Serverdienst implementiert und eine Schlüsselkomponente der Remote Installation Services (RIS) und Windows Deployment Services (WDS). Es umfasst bestimmte Vorbereitungsprozesse und ein Netzwerkprotokoll, das gewissermaßen als eine von Microsoft entwickelte DHCP-Erweiterung betrachtet werden kann. BINL ist eine proprietäre Microsoft-Technologie, die auf der PXE-Standard-Client-Firmware basiert. Derzeit ist keine BINL-Spezifikation öffentlich verfügbar.

• KR Sollins (Juni 1981). Das TFTP-Protokoll (Revision 2) . Network Working Group. doi : 10.17487/RFC0783 . RFC 783 .Status unbekannt. Durch RFC  1350 überholt .
• R. Finlayson (Juni 1984). Bootstrap Loading using TFTP . Network Working Group. doi : 10.17487/RFC0906 . RFC 906 .Status unbekannt.
• Bill Croft; John Gilmore (September 1985). BOOTSTRAP PROTOCOL (BOOTP) . Network Working Group. doi : 10.17487/RFC0951 . RFC 951 .Entwurf eines Standards. Aktualisiert durch RFC  1395 , 1497 , 1532 , 1542 und 5494 .
• K. Sollins (Juli 1992). Das TFTP-Protokoll (Revision 2) . Network Working Group. doi : 10.17487/RFC1350 . STD 33. RFC 1350 .Internetstandard 33. Ersetzt RFC  783. Aktualisiert durch RFC  1782 , 1783 , 1784 , 1785 , 2347 , 2348 und 2349 .
• R. Droms (März 1997). Dynamic Host Configuration Protocol . IETF Network Working Group. doi : 10.17487/RFC2131 . RFC 2131 .Entwurf eines Standards. Ersetzt RFC  1541. Aktualisiert durch RFC  3396 , 4361 , 5494 und 6842 .
• G. Malkin; A. Harkin (Mai 1998). TFTP Blocksize Option . Network Working Group. doi : 10.17487/RFC2348 . RFC 2348 .Entwurf eines Standards. Aktualisiert RFC  1350. Ersetzt RFC  1783 .
• M. Johnston (Juni 2006). S. Venaas (Hrsg.). Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) . Network Working Group. doi : 10.17487/RFC4578 . RFC 4578 .Informativ.
• T. Huth; J. Freimann; V. Zimmer; D. Thaler (September 2010). DHCPv6-Optionen für den Netzwerkstart . Internet Engineering Task Force . doi : 10.17487/RFC5970 . ISSN  2070-1721 . RFC 5970 .Vorgeschlagener Standard.
• P. Masotta (Januar 2015). TFTP-Fenstergrößenoption . Internet Engineering Task Force . doi : 10.17487/RFC7440 . ISSN  2070-1721 . RFC 7440 .Vorgeschlagener Standard.

• PXE-Spezifikation  – Die Preboot Execution Environment-Spezifikation v2.1, veröffentlicht von Intel & SystemSoft
• BIS-Spezifikation  – Die von Intel veröffentlichte Boot Integrity Services-Spezifikation v1.0
• Intel Preboot Execution Environment  – ​​Internet-Draft 00 des PXE-Client/Server-Protokolls, enthalten in der PXE-Spezifikation
• PXE-Fehlercodes  – Ein Katalog der PXE-Fehlercodes