DE112020007303T5

DE112020007303T5 - Sicheres hochfahren von rechenvorrichtungen

Info

Publication number: DE112020007303T5
Application number: DE112020007303.3T
Authority: DE
Inventors: Kang-Ning FENG; Tsue-yi Huang; Chin-Hung Chao
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2020-06-08
Filing date: 2020-06-08
Publication date: 2023-05-04
Also published as: US20230334156A1; CN115668157A; WO2021251950A1; TW202147157A; TWI779515B

Abstract

Techniken für ein sicheres Hochfahren von Unified Extensible Firmware Interface (UEFI)-konformen Vorrichtungen werden beschrieben. Bei einem Beispiel kann eine Ausführung eines Treibers, der einer Hardwarekomponente einer Rechenvorrichtung zugeordnet ist, während des Hochfahrens der Rechenvorrichtung erfasst werden. Basierend auf der Erfassung kann ein erster Treiberhash einer Systemtabelle der UEFI berechnet werden, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und UEFI-Dienste speichert. Danach kann ein zweiter Treiberhash der Systemtabelle basierend auf der Erfassung eines Abschlusses der Ausführung des Treibers hin berechnet werden. Der erste Treiberhash und der zweite Treiberhash können dann verglichen werden, um eine Manipulation der Systemtabelle der UEFI zu bestimmen.

Description

HINTERGRUND
Rechenvorrichtungen umfassen mehrere Hardwarekomponenten, die vor dem Betrieb eine Konfiguration erfordern. Moderne Systemfirmware, wie zum Beispiel Unified Extensible Firmware Interface (UEFI), ermöglicht eine Ausführung von Treibern, die solchen Hardwarekomponenten zugeordnet sind, während des Hochfahrens einer Rechenvorrichtung. Eine solche Ausführung von Treibern ermöglicht es, dass die Hardwarekomponenten während des Hochfahrens der Rechenvorrichtung konfiguriert und initialisiert werden.
Figurenliste
Die detaillierte Beschreibung erfolgt mit Bezugnahme auf die beiliegenden Figuren b, wobei:

1 eine Rechenvorrichtung zum Bestimmen einer Manipulation der Unified Extensible Firmware Interface (UEFI) gemäß einem Beispiel des vorliegenden Gegenstands darstellt;
2 eine Rechenvorrichtung zum Bestimmen einer Manipulation der UEFI gemäß einem weiteren Beispiel des vorliegenden Gegenstands darstellt;
3 ein Verfahren zum Bestimmen der Manipulation der UEFI gemäß einem Beispiel des vorliegenden Gegenstands darstellt;
4 ein Verfahren zum sicheren Hochfahren der UEFI-konformen Rechenvorrichtung gemäß einem Beispiel des vorliegenden Gegenstands darstellt; und
5 eine Systemumgebung, die ein nichtflüchtiges computerlesbares Medium zum Bestimmen einer Manipulation der UEFI in der Rechenvorrichtung implementiert, gemäß einem Beispiel des vorliegenden Gegenstands darstellt.

DETAILLIERTE BESCHREIBUNG
Allgemein gewährleistet die Unified Extensible Firmware Interface (UEFI) ein sicheres Hochfahren der Rechenvorrichtung durch Verifizieren der Treiber, die den verschiedenen Hardwarekomponenten zugeordnet sind, vor der Ausführung. Die Verifizierung eines Treibers wird durch Validieren einer digitalen Signatur durchgeführt, die dem Treiber zugeordnet ist, wobei die digitale Signatur während der Entwicklung des Treibers mit demselben verbunden wird und die Echtheit des Treibers anzeigt.
Der Treiber, der einer Hardwarekomponente zugeordnet ist, ist im Allgemeinen im Binärformat ohne zugeordneten Quellcode verfügbar, wobei das Binärformat des Treibers durch die digitale Signatur verifizierbar ist, die den Treiber begleitet. Falls somit der Quellcode des Treibers manipuliert wird, beispielsweise durch einen bösartigen Code während einer Entwicklung des Treibers und danach digital signiert wird, kann die Integrität des Treibers nicht sichergestellt werden. Entsprechend kann der bösartige Code des Treibers die Sicherheit der UEFI zusammen mit Nutzerdaten, die auf der Rechenvorrichtung gespeichert sind, gefährden.
Gemäß beispielhaften Implementierungen des vorliegenden Gegenstands werden Techniken für das sichere Hochfahren einer UEFI-konformen Rechenvorrichtung beschrieben.
Beim Betrieb wird während des Hochfahrens einer Rechenvorrichtung eine Ausführung eines Treibers für eine Konfiguration einer Hardwarekomponente der Rechenvorrichtung erfasst. Basierend auf der Erfassung wird ein erster Hash einer Systemtabelle der UEFI berechnet, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und verschiedene UEFI-Dienste speichert. Der Treiber darf für eine Konfiguration der Hardwarekomponente für den Betrieb ausgeführt werden. Sobald die Konfiguration der Hardwarekomponente abgeschlossen ist, wird ein zweiter Hash der Systemtabelle berechnet und mit dem ersten Hash verglichen. Es wird dann bestimmt, ob der erste Hash und der zweite Hash gleich sind.
Falls der erste Hash und der zweite Hash ungleich sind, kann bestimmt werden, dass die Systemtabelle manipuliert wurde. Entsprechend kann eine Benachrichtigung ausgegeben werden, die eine Manipulation der Systemtabelle anzeigt. In einer solchen Situation können Modifikationen, die an der Systemtabelle durchgeführt wurden, rückgängig gemacht werden und der Treiber kann für jede weitere Ausführung blockiert werden. Entsprechend kann während eines nachfolgenden Hochfahrens der Rechenvorrichtung die Ausführung des Treibers blockiert werden und die Rechenvorrichtung kann hochfahren, ohne die Hardwarekomponente zu initialisieren, die dem Treiber zugeordnet ist.
Falls andererseits herausgefunden wird, dass der erste Hash und der zweite Hash gleich sind, kann bestimmt werden, dass an der Systemtabelle keine Modifikationen durchgeführt wurden. In solch einer Situation kann die Rechenvorrichtung ein normales Hochfahren fortsetzen.
Die oben erwähnten Techniken gewährleisten somit die Integrität der Inhalte der Systemtabelle der UEFI durch Erfassen aller Modifikationen, die an derselben durchgeführt wurden, durch einen Treiber, der einer Hardwarekomponente der Rechenvorrichtung zugeordnet ist. Außerdem vermeidet das Blockieren einer weiteren Ausführung des Treibers eine Ausführung des bösartigen Codes während eines nachfolgenden Hochfahrens der Rechenvorrichtung, wodurch ein sicheres Hochfahren der Rechenvorrichtung gewährleistet wird.
Die obigen Techniken werden mit Bezugnahme auf 1 bis 5 näher beschrieben. Es sollte angemerkt werden, dass die Beschreibung und die Figuren lediglich die Prinzipien des vorliegenden Gegenstands zusammen mit hierin beschriebenen Beispielen darstellen und nicht als eine Beschränkung des vorliegenden Gegenstands angesehen werden sollten. Es ist somit klar, dass verschiedene Anordnungen entwickelt werden können, die die Prinzipien des vorliegenden Gegenstands umfassen, obwohl sie hierin nicht explizit beschrieben oder gezeigt sind. Darüber hinaus sollen alle Angaben, die Prinzipien, Aspekte und Implementierungen des vorliegenden Gegenstands beschreiben, sowie spezifische Beispiele derselben, Äquivalente derselben umfassen.
1 stellt eine Rechenvorrichtung 100 zum Bestimmen einer Manipulation einer Unified Extensible Firmware Interface (UEFI) gemäß einem Beispiel des vorliegenden Gegenstands dar. Beispiele der Rechenvorrichtung 100 können Laptops, Desktops, Tablets und Smartphones umfassen, sind aber nicht darauf beschränkt.
Die Rechenvorrichtung 100 kann mehrere Hardwarekomponenten umfassen, die während einer Vor-Betriebssystem-Initialisierung der Rechenvorrichtung 100 initialisiert werden können. Ferner kann jede der mehreren Komponenten entsprechend einen zugeordneten Treiber aufweisen, wobei jeder der Treiber mehreren Rückruffunktionen entsprechen kann.
Bei einem darstellenden Beispiel kann ein erster Treiber, der einer ersten Hardwarekomponente der Rechenvorrichtung 100 zugeordnet ist, verwendet werden, um Daten in einer Advanced Configuration and Power Interface(ACPI)-Tabelle zu veröffentlichen, wobei die ACPI-Tabelle bei einem Beispiel Hardwarekonfigurationsinformationen und Leistungsverwaltungsinformationen der Rechenvorrichtung 100 speichern kann. Bei dem Beispiel können die Daten, die in der ACPI-Tabelle zu veröffentlichen sind, nach der Ausführung einem zweiten Treiber zur Verfügung gestellt werden, der einer zweiten Hardwarekomponente der Rechenvorrichtung 100 zugeordnet ist. In einer solchen Situation kann der erste Treiber eine Rückruffunktion registrieren, um die Verfügbarkeit der Daten zu überwachen. Da die Verfügbarkeit der Daten als wahr bestimmt werden kann, kann ein Ereignis ausgelöst werden, um die Rückruffunktion des ersten Treibers aufzurufen. Entsprechend kann die Rückruffunktion des ersten Treibers ausgeführt werden und die Daten können in der ACPI-Tabelle veröffentlicht werden.
Die Rechenvorrichtung 100 kann eine Erfassungsmaschine 102 umfassen, um die Ausführung einer Rückruffunktion eines Treibers zu bestimmen, der einer Hardwarekomponente der Rechenvorrichtung 100 zugeordnet ist. Die Ausführung der Rückruffunktion kann in einer Treiberausführungsumgebungsphase (DXE-Phase, DXE = Driver Execution Environment) während der Vor-Betriebssystem-Initialisierung der Rechenvorrichtung 100 erfasst werden.
Basierend auf der Erfassung der Ausführung der Rückruffunktion kann eine Hashmaschine 104 der Rechenvorrichtung 100 einen ersten Rückruffunktion-Hash einer Systemtabelle der UEFI berechnen, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und verschiedene UEFI-Dienste speichert.
Die Hashmaschine 104 kann nachfolgend den Abschluss der Ausführung der Rückruffunktion erfassen. Basierend auf der Erfassung kann die Hashmaschine 104 einen zweiten Rückruffunktion-Hash des Treibers berechnen.
Eine Bestimmungsmaschine 106 der Rechenvorrichtung 100 kann dann den ersten Rückruffunktion-Hash mit dem zweiten Rückruffunktion-Hash vergleichen, um zu bestimmen, ob die Systemtabelle manipuliert wurde. Somit können alle Modifikationen an der Systemtabelle, die anhand der Ausführung der Rückruffunktion durchgeführt wurden, identifiziert werden, wodurch eine Integrität des Inhalts, der in der Systemtabelle gespeichert ist, gewährleistet wird.
2 stellt die Rechenvorrichtung 100 zum Bestimmen einer Manipulation der UEFI gemäß einem weiteren Beispiel des vorliegenden Gegenstands dar. Wie oben beschrieben können Beispiele der Rechenvorrichtung 100 Desktops, Laptops, Smartphones und Tablets umfassen, sind aber nicht darauf beschränkt.
Die Rechenvorrichtung 100 kann einen Prozessor 202 und einen Speicher 204 umfassen, der mit dem Prozessor 202 gekoppelt ist. Die Funktionen der verschiedenen Elemente, die in den Figuren gezeigt sind, einschließlich aller Funktionsblöcke, die als „Prozessor(en)“ bezeichnet sind, können durch die Nutzung zweckgebundener Hardware sowie von Hardware bereitgestellt werden, die Anweisungen ausführen kann. Wenn dieselben durch einen Prozessor bereitgestellt werden, können die Funktionen durch einen einzelnen zweckgebundenen Prozessor, durch einen einzelnen gemeinschaftlich verwendeten Prozessor oder durch eine Mehrzahl von einzelnen Prozessoren bereitgestellt werden, von denen einige gemeinschaftlich verwendet werden können. Darüber hinaus wird die explizite Nutzung des Begriffs „Prozessor“ nicht so gesehen, dass dieselbe sich ausschließlich auf Hardware bezieht, die Anweisungen ausführen kann und kann implizit ohne Beschränkung eine Digitalsignalprozessor (DSP)-Hardware, einen Netzwerkprozessor, eine anwendungsspezifisch integrierte Schaltung (ASIC), ein feldprogrammierbares Gatterarray (FPGA) umfassen. Auch andere Hardware, die standard- und/oder kundenspezifisch ist, kann mit dem Prozessor 202 gekoppelt sein.
Der Speicher 204 kann jedes computerlesbare Medium umfassen, das beispielsweise flüchtigen Speicher (z. B. Direktzugriffspeicher (RAM)) und/oder nichtflüchtigen Speicher (z.B. ROM, EPROM, Flashspeicher, usw.) umfasst.
Ferner kann die Rechenvorrichtung 100 auch eine Maschine/Maschinen 206 umfassen, die die Erfassungsmaschine 102, die Hashmaschine 104, die Bestimmungsmaschine 106 und eine Modifikationsmaschine 208 umfassen kann/können.
Bei einem Beispiel kann/können die Maschine(n) 206 als Hardware, Firmware und eine Kombination davon implementiert sein. Bei hierin beschriebenen Beispielen können solche Kombinationen von Hardware und Firmware auf verschiedene Weisen implementiert werden. Beispielsweise kann die Firmware der Maschine aus prozessorausführbaren Anweisungen bestehen, die in einem nichtflüchtigen maschinenlesbaren Speichermedium gespeichert sind, und die Hardware für die Maschine kann eine Verarbeitungsressource umfassen (die beispielsweise entweder als ein einzelner Prozessor oder eine Kombination mehrerer Prozessoren implementiert ist), um solche Anweisungen auszuführen.
Gemäß Implementierungen des vorliegenden Gegenstands kann das maschinenlesbare Speichermedium Anweisungen speichern, die die Funktionalitäten der Maschine implementieren, wenn dieselben durch die Verarbeitungsressource ausgeführt werden. Bei solchen Implementierungen kann die Rechenvorrichtung 100 das maschinenlesbare Speichermedium zum Speichern der Anweisungen und die Verarbeitungsressource zum Ausführen der Anweisungen umfassen.
Bei einem Beispiel des vorliegenden Gegenstands kann sich das maschinenlesbare Speichermedium in der Rechenvorrichtung 100 befinden. Bei anderen Beispielen kann sich das maschinenlesbare Speichermedium jedoch an einer anderen Stelle befinden, aber für die Rechenvorrichtung 100 und den Prozessor 202 zugreifbar sein.
Die Rechenvorrichtung 100 kann ferner Daten 210 umfassen, die unter anderem dazu dienen als ein Depot zum Speichern von Daten, die durch die Maschine(n) 206 abgerufen, verarbeitet, empfangen oder erzeugt werden können. Die Daten 210 können Hashdaten 212, Bestimmungsdaten 214 und andere Daten 216 umfassen. Bei einem Beispiel können die Daten 210 in dem Speicher 204 gespeichert sein.
Bei einer beispielhaften Implementierung des vorliegenden Gegenstands wird die Vor-Betriebssystem-Initialisierung der Rechenvorrichtung mit der UEFI unterteilt in mehrere Phasen, nämlich Sicherheits(SEC)-Phase, Vor-EFI-(PEI)-Phase, Treiberausführungsumgebung(DXE)-Phase, Hochfahrvorrichtungsauswahl(BDS)-Phase und Transiente-Systemlast (TSL)-Phase. Die Vor-Betriebssystem-Initialisierung kann mit der SEC-Phase beginnen, wo anfängliche Operationen durchgeführt werden können, um die Integrität der Firmware s für eine Initialisierung des Prozessors, Chipsatzes und der Hauptplatine zu gewährleisten, nachdem die Rechenvorrichtung 100 eingeschaltet oder neu gestartet wird. Die Vor-Betriebssystem-Initialisierung kann dann zu der PEI-Phase fortschreiten, wo die PEI-Phase ein standardisiertes Verfahren zum Laden und Aufrufen spezifischer Anfangskonfigurationsroutinen für den Prozessor, Chipsatz und die Hauptplatine der Rechenvorrichtung 100 bereitstellt. Der Hauptzweck der PEI-Phase ist das Bestimmen des Hochfahrwegs der Rechenvorrichtung 100 und das Initialisieren und Zuordnen einer minimalen Menge an RAM und Permanentspeicher, die die DXE-Grundlage und Architekturprotokolle enthalten, um eine Instanziierung der DXE-Phase zu ermöglichen.
In der DXE-Phase wird die Initialisierung verschiedener Hardwarekomponenten der Rechenvorrichtung 100 durchgeführt. Die Initialisierung der verschiedenen Hardwarekomponenten kann durch die Ausführung unterschiedlicher Treiber ermöglicht werden, die jeder der verschiedenen Hardwarekomponenten zugeordnet sind. Bei einem Beispiel wird die Entdeckung und Ausführung der unterschiedlichen Treiber durch einen DXE-Dispatcher ermöglicht.
Bei einem Beispiel des vorliegenden Gegenstands kann der DXE-Dispatcher mit der Erfassungsmaschine 102 gekoppelt sein, wobei die Erfassungsmaschine 102 die Ausführung eines Treibers, der einer Hardwarekomponente der Rechenvorrichtung 100 zugeordnet ist, in der DXE-Phase erfasst. Der Treiber kann einer eines DXE-Treibers und eines UEFI-Treibers sein.
Basierend auf der Erfassung der Ausführung des Treibers durch die Erfassungsmaschine 102 kann die Hashmaschine 104 eine Systemverwaltungsunterbrechung (SMI; SMI = System Management Interrupt) erzeugen, wobei die Erzeugung der SMI ein Auslösen eines Systemverwaltungsmodus (SMM; SMM = System Management Mode) in der DXE-Phase verursacht. Das Auslösen des SMM kann einen Zustand des Prozessors 202 in einer Region des RAM bewahren, die als System Management RAM (SMRAM) bezeichnet wird.
Ferner kann die Hashmaschine 104 basierend auf der Erfassung der Ausführung des Treibers einen ersten Treiberhash der Systemtabelle der UEFI berechnen, und kann den ersten Treiberhash in den Hashdaten 214 speichern. Wie oben erläutert, ist die Systemtabelle eine Datenstruktur, die Konfigurationseinzelheiten der Rechenvorrichtung und verschiedene UEFI-Dienste speichert.
Die verschiedenen UEFI-Dienste können UEFI-Hochfahrdienste, UEFI-Laufzeitdienste und Protokolldienste umfassen. Auf die UEFI-Hochfahrdienste und die UEFI-Laufzeitdienste kann jeweils über die UEFI-Hochfahrdienstetabelle und die UEFI-Laufzeitdienstetabelle zugegriffen werden, die in der Systemtabelle enthalten sind. Ferner sind die Protokolldienste eine Gruppe verwandter Funktionen und Datenfelder, die verwendet werden können, um Softwareabstraktionen für Vorrichtungen wie zum Beispiel Konsolen, Festplatten und Netzwerke bereitzustellen.
Auf die Ausführung des Treibers hin kann ein Zeiger zu der Systemtabelle an den Treiber weitergeleitet werden. Das Weiterleiten des Zeigers zu dem Treiber ermöglicht es dem Treiber, auf die Konfigurationsinformationen der Rechenvorrichtung zuzugreifen, zusammen mit den verschiedenen UEFI-Diensten, um die zugeordnete Hardwarekomponente zu initialisieren.
Es sollte angemerkt werden, dass der SMM beendet werden kann und der Treiber ausgeführt wird, sobald der Treiberhash der Systemtabelle berechnet ist und in den Hashdaten 214 gespeichert ist.
Sobald die Ausführung des Treibers abgeschlossen ist, kann die Hashmaschine 104 die SMI regenerieren und dadurch den SMM innerhalb der DXE-Phase neu auslösen. Nachfolgend kann die Hashmaschine 104 einen zweiten Treiberhash der Systemtabelle berechnen und kann dieselben in den Hashdaten 214 speichern. Beispielsweise können die Hashdaten 214 in dem SMRAM gespeichert werden, um einen Zugriff des ersten Treiberhash und des zweiten Treiberhash außerhalb des SMM zu verhindern.
Die Hashmaschine 104 kann ferner mit der Bestimmungsmaschine 106 gekoppelt sein, wobei die Bestimmungsmaschine 106 den ersten Treiberhash und den zweiten Treiberhash der Systemtabelle vergleichen kann und ein Ergebnis des Vergleichs in den Bestimmungsdaten 214 speichern kann. Bei einem Beispiel können die Bestimmungsdaten 214 auch in dem SMRAM gespeichert werden.
Der erste Treiberhash und der zweite Treiberhash können verglichen werden, um zu identifizieren, ob während der Ausführung des Treibers irgendwelche Modifikationen an der Systemtabelle durchgeführt wurden.
Falls die Bestimmungsmaschine 106 bestimmt, dass der erste Treiberhash und der zweite Treiberhash gleich sind, kann die Bestimmungsmaschine 106 sicherstellen, dass an der Systemtabelle keine Modifikationen durchgeführt wurden. Nachfolgend kann bestimmt werden, ob der DXE-Dispatcher irgendwelche weiteren Treiber zum Laden und Ausführen aufweist. Falls keine anderen Treiber für die Ausführung identifiziert werden, kann die DXE-Phase abgeschlossen werden und die Steuerung kann an die nachfolgenden Phasen zum Laden des Betriebssystems weitergegeben werden.
Falls andererseits die Bestimmungsmaschine 106 bestimmt, dass der erste Treiberhash und der zweite Treiberhash ungleich sind, kann die Bestimmungsmaschine 106 bestimmen, dass die Ausführung des Treibers die Systemtabelle der UEFI manipuliert hat. In solch einer Situation kann der Treiber blockiert werden. Ferner kann bei einem Beispiel die Ausführung des Treibers während nachfolgender Hochfahrvorgänge der Rechenvorrichtung 100 blockiert werden.
Nachfolgend kann die Modifikationsmaschine 208 alle Modifikationen, die an der Systemtabelle während der Ausführung des Treibers durchgeführt wurden, rückgängig machen.
Sobald die Ausführung des Treibers abgeschlossen ist, kann der DXE-Dispatcher ferner identifizieren, ob irgendein weiterer Treiber, der einer anderen Komponente der Rechenvorrichtung zugeordnet ist, eine Ausführung erfordern.
Bei einem Beispiel kann es sein, dass der DXE-Dispatcher keinen anderen Treiber, der einer anderen Hardwarekomponente zugeordnet ist, für eine Ausführung identifiziert. In solch einer Situation kann eine Videoausgabevorrichtung, die mit der Rechenvorrichtung gekoppelt ist, identifiziert werden. Nachfolgend können eine Benachrichtigung, die die Manipulation der Systemtabelle zusammen mit den Einzelheiten des Treibers angibt, angezeigt werden, gefolgt von einem Neustart der Rechenvorrichtung.
Bei einem weiteren Beispiel kann der DXE-Dispatcher eine Rückruffunktion eines anderen Treibers, der einer anderen Hardwarekomponente der Rechenvorrichtung 100 zugeordnet ist, entdecken und ausführen. Bei diesem Beispiel kann die Erfassungsmaschine 102, die mit dem DXE-Dispatcher gekoppelt ist, die Ausführung der Rückruffunktion erfassen.
Basierend auf der Erfassung kann die Hashmaschine 104 das Auslösen des SMM bewirken. Die Hashmaschine 104 kann dann einen ersten Rückruffunktion-Hash der Systemtabelle berechnen und denselben in Hashdaten 214 speichern. Nachfolgend kann der SMM beendet werden und die Ausführung der Rückruffunktion kann abgeschlossen werden.
Sobald die Ausführung der Rückruffunktion abgeschlossen ist, kann die Hashmaschine 104 den SMM erneut auslösen und kann einen zweiten Rückruffunktion-Hash der Systemtabelle berechnen. Danach kann der zweite Rückruffunktion-Hash in den Hashdaten 214 gespeichert werden.
Die Bestimmungsmaschine 106 kann den ersten Rückruffunktion-Hash und den zweiten Rückruffunktion-Hash vergleichen, um sicherzustellen, ob die Ausführung der Rückruffunktion die Systemtabelle der UEFI manipuliert hat.
Falls die Bestimmungsmaschine 106 bestimmt, dass der erste Rückruffunktion-Hash und der zweite Rückruffunktion-Hash gleich sind, kann die Bestimmungsmaschine 106 bestimmen, dass an der Systemtabelle der UEFI keine Modifikationen durchgeführt werden.
Falls andererseits die Bestimmungsmaschine 106 bestimmt, dass der erste Rückruffunktion-Hash und der zweite Rückruffunktion-Hash ungleich sind, kann die Bestimmungsmaschine 106 bestimmen, dass die Ausführung der Rückruffunktion die Systemtabelle manipuliert hat. Entsprechend kann der andere Treiber blockiert werden. Nachfolgend kann die Modifikationsmaschine 208 die Modifikationen, die während der Ausführung der Rückruffunktion an der Systemtabelle durchgeführt wurden, rückgängig machen.
Der DXE-Dispatcher kann erneut identifizieren, ob ein weiterer Treiber, der einer anderen Hardwarekomponente zugeordnet ist, für die Ausführung übrigbleibt. Bei einem Beispiel kann es sein, dass der DXE-Dispatcher keinen anderen Treiber, der einer anderen Hardwarekomponente zugeordnet ist, für die Ausführung identifiziert. In solch einer Situation kann bestimmt werden, ob eine Videoausgabevorrichtung mit der Rechenvorrichtung 100 gekoppelt ist. Falls keine Videoausgabevorrichtung gefunden wird, die mit der Rechenvorrichtung 100 gekoppelt ist, kann eine Benachrichtigung, die einen Angriff auf die UEFI angibt, durch Blinken einer lichtemittierenden Diode (LED) angezeigt werden, die an der Rechenvorrichtung 100 installiert ist, gefolgt von einem Neustart der Rechenvorrichtung 100.
3 stellt ein Verfahren 300 zum Bestimmen einer Manipulation der UEFI in einer Rechenvorrichtung gemäß einem Beispiel des vorliegenden Gegenstands dar. Obwohl das Verfahren 300 in einer Vielzahl von Systemen implementiert werden kann, wird die Beschreibung des Verfahrens 300 in Bezug auf die oben beschriebene Rechenvorrichtung 100 bereitgestellt, um die Erläuterung zu erleichtern. Die Reihenfolge, in der das Verfahren 300 beschrieben wird, soll nicht als Beschränkung angesehen werden, und jede Anzahl der beschriebenen Verfahrensblöcke kann in jeder Reihenfolge kombiniert werden, um das Verfahren 300 oder ein alternatives Verfahren zu implementieren.
Es ist klar, dass Blöcke des Verfahrens 300 in der Rechenvorrichtung 100 durchgeführt werden können. Die Blöcke der Verfahren 300 können basierend auf Anweisungen ausgeführt werden, die in einem nichtflüchtigen computerlesbaren Medium gespeichert sind, wie es ohne weiteres klar ist. Das nichtflüchtige computerlesbare Medium kann beispielsweise digitale Speicher, Magnetspeichermedien wie zum Beispiel Magnetplatten und Magnetbänder, Festplatten oder optisch lesbare digitale Datenspeichermedien umfassen.
Bei Block 302 kann die Ausführung eines Treibers, der einer Hardwarekomponente der Rechenvorrichtung zugeordnet ist, während des Hochfahrens einer Rechenvorrichtung mit Unified Extensible Firmware Interface (UEFI) erfasst werden. Der Treiber kann einer eines Treiberausführungsumgebung(DXE)-Treibers und eines UEFI-Treibers sein. Bei einem Beispiel kann die Ausführung des Treibers durch eine Erfassungsmaschine 102 der Rechenvorrichtung 100 erfasst werden.
Bei Block 304 wird ein erster Treiberhash einer Systemtabelle der UEFI berechnet, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und UEFI-Dienste speichert. Bei einem Beispiel kann eine Hashmaschine 104 der Rechenvorrichtung 100 den ersten Treiberhash der Systemtabelle berechnen.
Bei Block 306 kann der Abschluss der Ausführung des Treibers erfasst werden. Bei einem Beispiel kann die Erfassungsmaschine 102 den Abschluss der Ausführung des Treibers erfassen.
Bei Block 308 kann basierend auf der Erfassung des Abschlusses der Ausführung des Treibers ein zweiter Treiberhash der Systemtabelle berechnet werden. Bei einem Beispiel kann der zweite Treiberhash durch die Hashmaschine 104 berechnet werden.
Bei Block 310 können der erste Treiberhash und der zweite Treiberhash verglichen werden, um eine Manipulation der Systemtabelle der UEFI zu bestimmen. Bei einem Beispiel kann die Bestimmungsmaschine 106 die Manipulation der Systemtabelle der UEFI bestimmen. Falls bestimmt wird, dass die Systemtabelle der UEFI manipuliert wurde, kann eine Videoausgabevorrichtung, die mit der Rechenvorrichtung 100 gekoppelt ist, identifiziert werden und eine Benachrichtigung, die die Einzelheiten des Treibers bereitstellt, kann auf der Videoausgabevorrichtung angezeigt werden. Andernfalls kann das Verfahren mit dem Laden eines Betriebssystems auf die Rechenvorrichtung fortgesetzt werden.
4 stellt ein Verfahren 400 für sicheres Hochfahren einer UEFI-konformen Rechenvorrichtung gemäß einem Beispiel des vorliegenden Gegenstands dar. Obwohl das Verfahren 400 in einer Vielzahl von Systemen implementiert werden kann, wird die Beschreibung des Verfahrens 400 in Bezugnahme auf die oben beschriebene Rechenvorrichtung 100 bereitgestellt, um die Erläuterung zu erleichtern. Die Reihenfolge, in der das Verfahren 400 beschrieben wird, soll nicht als eine Beschränkung angesehen werden, und jede Anzahl der beschriebenen Verfahrensblöcke kann in jeder Reihenfolge kombiniert werden, um das Verfahren 400 oder ein alternatives Verfahren zu implementieren.
Es ist klar, dass die Blöcke des Verfahrens 400 in der Rechenvorrichtung 100 durchgeführt werden können. Die Blöcke des Verfahrens 400 können basierend auf Anweisungen ausgeführt werden, die in einem nichtflüchtigen computerlesbaren Medium gespeichert sind, wie es offensichtlich ist. Das nichtflüchtige computerlesbare Medium kann beispielsweise digitale Speicher, Magnetspeichermedien wie zum Beispiel Magnetplatten und Magnetbänder, Festplatten oder optisch lesbare digitale Datenspeichermedien umfassen.
Bei Block 402 kann die Ausführung eines Treibers, der einer Hardwarekomponente der Rechenvorrichtung zugeordnet ist, in einer Treiberausführungsphase(DXE) Phase während des Hochfahrens einer Rechenvorrichtung mit Unified Extensible Firmware Interface (UEFI) erfasst werden. Der Treiber kann einer eines Treiberausführungsumgebung(DXE)-Treibers und eines UEFI-Treibers sein. Basierend auf der Erfassung des Treibers, der der Hardware zugeordnet ist, kann eine Systemverwaltungsunterbrechung (SMI) erzeugt werden, wodurch in der DXE-Phase ein Systemverwaltungsmodus (SMM) ausgelöst wird. Das Auslösen des SMM kann einen Zustand des Prozesses der Rechenvorrichtung in einer sicheren Region des RAM, der als ein System Management RAM (SMRM) bezeichnet wird, bewahren. Bei einem Beispiel kann die Ausführung des Treibers durch eine Erfassungsmaschine 102 der Rechenvorrichtung 100 erfasst werden.
Bei Block 404 wird ein erster Treiberhash einer Systemtabelle der UEFI berechnet, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und verschiedene UEFI-Dienste speichert. Die verschiedenen UEFI-Dienste können UEFI-Hochfahrdienste, UEFI-Laufzeitdienste und Protokolldienste umfassen. Der erste Treiberhash kann in der sicheren Region des RAM gespeichert sein. Nachfolgend kann der SMM beendet werden. Bei einem Beispiel kann der erste Treiberhash der Systemtabelle der UEFI durch eine Hashmaschine 104 der Rechenvorrichtung 100 berechnet werden.
Bei Block 406 wird ein Abschluss der Ausführung des zweiten Treiberhash der Systemtabelle erfasst. Basierend auf der Erfassung wird die SMI regeneriert, wodurch der SMM erneut ausgelöst wird. Danach wird ein zweiter Treiberhash der Systemtabelle berechnet und in dem SMRAM gespeichert. Bei einem Beispiel kann der zweite Treiberhash durch die Hashmaschine 104 berechnet werden.
Bei Block 408 können der erste Treiberhash und der zweite Treiberhash der Systemtabelle von dem SMRAM abgerufen werden und miteinander verglichen werden. Ein Ergebnis des Vergleichs kann dann in dem SMRAM gespeichert werden, gefolgt von einer Beendigung des SMM. Bei einem Beispiel können der erste Treiberhash und der zweite Treiberhash durch eine Bestimmungsmaschine 106 der Rechenvorrichtung 100 verglichen werden.
Nachfolgend kann bei Block 410 eine Ausführung einer Rückruffunktion eines anderen Treibers, der einer anderen Hardwarekomponente der Rechenvorrichtung zugeordnet ist, erfasst werden. Bei einem Beispiel kann die Erfassung der Ausführung der Rückruffunktion durch die Erfassungsmaschine 102 erfasst werden.
Bei Block 412 kann der SMM-Modus basierend auf der Erfassung innerhalb der DXE-Phase neu ausgelöst werden. Ein erster Rückruffunktion-Hash der Systemtabelle kann dann berechnet werden und in dem SMRAM gespeichert werden, gefolgt von einer Beendigung des SMM. Die Rückruffunktion kann dann ausgeführt werden.
Bei Block 414 kann der Abschluss der Ausführung der Rückruffunktion erfasst werden. Basierend auf der Erfassung kann der SMM neu oder wieder ausgelöst werden und ein zweiter Rückruffunktion-Hash kann berechnet werden. Die zweite Rückruffunktion kann dann in dem SMRAM gespeichert werden. Bei einem Beispiel kann der zweite Rückruffunktion-Hash durch die Hashmaschine 104 berechnet werden.
Bei Block 416 kann der erste Rückruffunktion-Hash mit dem zweiten Rückruffunktion-Hash verglichen werden. Ein Ergebnis des oben beschriebenen Vergleichs kann dann in dem SMRAM gespeichert werden. Bei einem Beispiel kann die Bestimmungsmaschine 106 den ersten Rückruffunktion-Hash mit dem zweiten Rückruffunktion-Hash vergleichen.
Bei Block 418 kann basierend auf dem Ergebnis des Vergleichs von zumindest einem des ersten und zweiten Treiberhash und dem ersten und zweiten Rückruffunktion-Hash sichergestellt werden, ob die Systemtabelle der UEFI manipuliert wurde. Bei einem Beispiel kann die Bestimmungsmaschine 106 die Manipulation der Systemtabelle der UEFI bestimmen.
Falls herausgefunden wird, dass der erste Treiberhash und der zweite Treiberhash nicht gleich sind, kann bei einem Beispiel bestimmt werden, dass die Ausführung des Treibers zu der Manipulation der Systemtabelle geführt hat. Entsprechend kann der Treiber blockiert werden. Falls herausgefunden wurde, dass der erste Rückruffunktion-Hash und der zweite Rückruffunktion-Hash nicht gleich sind, kann bei dem Beispiel ferner bestimmt werden, dass die Ausführung der Rückruffunktion auch zu der Manipulation der Systemtabelle geführt hat. Entsprechend kann die Rückruffunktion ebenfalls blockiert werden. In solch einer Situation können die Ausführung des Treibers und der Rückruffunktion des anderen Treibers während nachfolgenden Hochfahrvorgängen der Rechenvorrichtung 100 blockiert werden.
5 stellt eine Systemumgebung 500 dar, die ein nichtflüchtiges computerlesbares Medium 502 zum Bestimmen einer Manipulation einer UEFI in einer Rechenvorrichtung gemäß einem Beispiel des vorliegenden Gegenstands implementiert. Bei einer beispielhaften Implementierung kann die Systemumgebung 500 eine Rechenvorrichtung sein, wie zum Beispiel die Rechenvorrichtung 100. Die Systemumgebung 500 umfasst eine Verarbeitungsressource 504, die durch eine Kommunikationsverbindung 506 mit dem nichtflüchtigen computerlesbaren Medium 502 kommunikativ verbunden ist. Bei einem Beispiel ruft die Verarbeitungsressource 504 computerlesbare Befehle von dem nichtflüchtigen computerlesbaren Medium 502 ab und führt dieselben aus.
Das nichtflüchtige computerlesbare Medium 502 kann beispielsweise eine interne Speichervorrichtung oder eine externe Speichervorrichtung sein. Bei einer beispielhaften Implementierung kann die Kommunikationsverbindung 506 eine direkte Kommunikationsverbindung sein, wie zum Beispiel jede Speicherlese/schreibschnittstelle. Bei einer anderen beispielhaften Implementierung kann die Kommunikationsverbindung 506 eine indirekte Kommunikationsverbindung sein, wie zum Beispiel eine Netzwerkschnittstelle. In solch einem Fall kann die Verarbeitungsressource 504 durch ein Netzwerk 508 auf das nichtflüchtige computerlesbare Medium 502 zugreifen. Das Netzwerk 508 kann ein einzelnes Netzwerk oder eine Kombination mehrerer Netzwerke sein und kann eine Vielzahl unterschiedlicher Kommunikationsprotokolle verwenden.
Die Verarbeitungsressource 504 und das nichtflüchtige computerlesbare Medium 502 können auch kommunikativ mit einer oder mehreren Datenquellen 510 gekoppelt sein. Die Datenquelle(n) 510 können verwendet werden, um Daten zu speichern. Bei einer beispielhaften Implementierung umfasst das nichtflüchtige computerlesbare Medium 502 einen Satz von computerlesbaren Anweisungen zum Bestimmen einer Manipulation der UEFI in einer Rechenvorrichtung, wie zum Beispiel der Rechenvorrichtung 100. Die Verarbeitungsressource 504 kann durch die Kommunikationsverbindung 506 auf den Satz von computerlesbaren Anweisungen zugreifen und diese nachfolgend ausführen, um einen Zugriff auf die Rechenvorrichtung 100 zu autorisieren.
Bei einem Beispiel kann das nichtflüchtige computerlesbare Medium 502 Anweisungen zum Implementieren einer Erfassungsmaschine 102 umfassen. Die Anweisungen, die die Erfassungsmaschine 102 implementieren, können bei einem Beispiel ein Code sein, der ausführbar ist, um eine Ausführung von Treibern zu erfassen, die Hardwarekomponenten der Komponentenvorrichtung 100 zugeordnet sind. Der Code kann ferner eine Erfassung eines Abschlusses der Ausführung der Treiber ermöglichen.
Das nichtflüchtige computerlesbare Medium 502 kann ferner einen Satz von Anweisungen umfassen, die eine Hashmaschine 104 implementieren. Die Anweisungen, die die Hashmaschine 104 implementieren, können bei einem Beispiel ein Code sein, der ausführbar ist, um einen Hash einer Systemtabelle der UEFI in verschiedenen Instanzen zu berechnen, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und UEFI-Dienste speichert.
Darüber hinaus kann das nichtflüchtige computerlesbare Medium 502 einen Satz von Anweisungen umfassen, die eine Bestimmungsmaschine 106 implementieren. Die Anweisungen, die die Bestimmungsmaschine 106 implementieren, können bei einem Beispiel ein Code sein, der ausführbar ist, um die Hashs zu vergleichen, die durch die Hashmaschine 104 berechnet werden, um eine Manipulation der Systemtabelle der UEFI zu bestimmen.
Bei einem Beispiel des vorliegenden Gegenstands können die Anweisungen, die die Erfassungsmaschine 102 implementieren, eine Ausführung eines Treibers, der eine Hardwarekomponente der Rechenvorrichtung zugeordnet ist, in einer Treiberausführungsumgebung(DXE)-Phase während der Vor-Betriebssystem-Initialisierung der Rechenvorrichtung erfassen.
Basierend auf der Erfassung der Ausführung des Treibers können die Anweisungen, die die Hashmaschine 104 implementieren, einen ersten Treiberhash der Systemtabelle berechnen.
Die Anweisungen, die die Erfassungsmaschine 102 implementieren, können dann den Abschluss der Ausführung des Treibers erfassen. Basierend auf der Erfassung können die Anweisungen, die die Hashmaschine 104 implementieren, einen zweiten Treiberhash der Systemtabelle berechnen. Danach können die Anweisungen, die die Bestimmungsmaschine 106 implementieren, den ersten Treiberhash und den zweiten Treiberhash vergleichen und können ein Ergebnis des Vergleichs in der/den Datenquelle(n) 510 speichern.
Nachfolgend können die Anweisungen, die die Erfassungsmaschine 102 implementieren, eine Ausführung einer Rückruffunktion eines anderen Treibers erfassen, der einer anderen Komponente der Rechenvorrichtung zugeordnet ist. Basierend auf der Erfassung können die Anweisungen, die die Hashmaschine 104 implementieren, einen ersten Rückruffunktion-Hash der Systemtabelle berechnen.
Die Anweisungen, die die Erfassungsmaschine 102 implementieren, können dann den Abschluss der Ausführung der Rückruffunktion erfassen. Basierend auf der Erfassung können die Anweisungen, die die Hashmaschine 104 implementieren, einen zweiten Rückruffunktion-Hash berechnen. Danach können die Anweisungen, die die Bestimmungsmaschine 106 implementieren, den ersten Rückruffunktion-Hash und den zweiten Rückruffunktion-Hash vergleichen und ein Ergebnis des Vergleichs in der/den Datenquelle(n) 510 speichern.
Basierend auf dem Vergleich von zumindest einem des ersten und zweiten Treiberhash und dem ersten und zweiten Rückruffunktion-Hash können die Anweisungen, die die Bestimmungsmaschine 106 implementieren, eine Manipulation der Systemtabelle der UEFI bestimmen. Falls bestimmt wird, dass entweder der erste oder der zweite Treiberhash nicht übereinstimmen oder der erste und der zweite Rückruffunktion-Hash nicht übereinstimmen, können die Anweisungen, die die Bestimmungsmaschine 106 implementieren, bestimmen, dass die Systemtabelle manipuliert wurde.
In solch einer Situation können die Anweisungen, die die Bestimmungsmaschine 106 implementieren, den zumindest einen des Treibers und der Rückruffunktion des anderen Treibers blockieren.
Blockieren von zumindest einem des Treibers und der Rückruffunktion des anderen Treibers kann die Ausführung des böswilligen Codes während eines nachfolgenden Hochfahrens der Rechenvorrichtung 100 vermeiden, wodurch die Integrität der UEFI der Rechenvorrichtung 100 gewährleistet wird.
Obwohl Beispiele des vorliegenden Gegenstands in einer Sprache beschrieben wurden, die für Verfahren und/oder Strukturmerkmale spezifisch ist, ist klar, dass der vorliegende Gegenstand nicht auf die spezifischen beschriebenen Verfahren oder Merkmale beschränkt ist. Die Verfahren und spezifischen Merkmale sind eher als Beispiele des vorliegenden Gegenstands offenbart und erläutert.

Claims

Ein Verfahren, das folgende Schritte aufweist: Erfassen, während des Hochfahrens einer Rechenvorrichtung mit Unified Extensible Firmware Interface (UEFI), einer Ausführung eines Treibers, der einer Hardwarekomponente der Rechenvorrichtung zugeordnet ist; Berechnen eines ersten Treiberhash einer Systemtabelle der UEFI, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und UEFI-Dienste speichert; Erfassen eines Abschlusses der Ausführung des Treibers; Berechnen eines zweiten Treiberhash der Systemtabelle auf den Abschluss der Ausführung des Treibers hin; und Vergleichen des ersten Treiberhash und des zweiten Treiberhash, um eine Manipulation der Systemtabelle der UEFI zu bestimmen.
Das Verfahren gemäß Anspruch 1, das ferner basierend auf der Bestimmung einer Manipulation der Systemtabelle der UEFI ein Blockieren des Treibers aufweist.
Das Verfahren gemäß Anspruch 2, das ferner während eines nachfolgenden Hochfahrens der Rechenvorrichtung ein Blockieren der Ausführung des Treibers aufweist.
Das Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Identifizieren einer Videoausgabevorrichtung, die mit der Rechenvorrichtung gekoppelt ist; und Anzeigen einer Benachrichtigung, die Einzelheiten des Treibers bereitstellt, auf der Videoausgabevorrichtung, auf das Bestimmen der Manipulation der Systemtabelle hin.
Das Verfahren gemäß Anspruch 1, das ferner ein Rückgängigmachen von Modifikationen aufweist, die durch den Treiber an der Systemtabelle durchgeführt wurden.
Das Verfahren gemäß Anspruch 1, bei dem die Ausführung des Treibers während des Hochfahrens der Rechenvorrichtung innerhalb einer Treiberausführungsumgebung(DXE)-Phase erfasst wird.
Das Verfahren gemäß Anspruch 6, bei dem der Treiber einer eines DXE-Treibers und eines UEFI-Treibers ist.
Das Verfahren gemäß Anspruch 6, das ferner folgende Schritte aufweist: Auslösen eines Systemverwaltungsmodus (SMM) in der DXE-Phase, wobei das Auslösen des SMM einen Zustand eines Prozessors der Rechenvorrichtung in einer sicheren Region eines Direktzugriffspeichers (RAM) bewahrt, der mit demselben gekoppelt ist; und Speichern des ersten Treiberhash und des zweiten Treiberhash in der sicheren Region des RAM.
Das Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Erfassen einer Ausführung einer Rückruffunktion eines anderen Treibers, der einer anderen Hardwarekomponente der Rechenvorrichtung zugeordnet ist; Berechnen eines ersten Rückruffunktion-Hash der Systemtabelle; Erfassen eines Abschlusses der Ausführung der Rückruffunktion; Berechnen eines zweiten Rückruffunktion-Hash der Systemtabelle auf die Erfassung des Abschlusses der Rückruffunktion hin; Vergleichen des ersten Rückruffunktion-Hash mit dem zweiten Rückruffunktion-Hash; und basierend auf dem Vergleichen, Bestimmen der Manipulation der Systemtabelle der UEFI.
Das Verfahren gemäß Anspruch 9, das ferner ein Blockieren der Ausführung der Rückruffunktion während eines nachfolgenden Hochfahrens der Rechenvorrichtung aufweist.
Ein System, das folgende Merkmale aufweist: eine Erfassungsmaschine zum Erfassen, in einer Treiberausführungsumgebung(DXE)-Phase während einer Vor-Betriebssystem-Initialisierung einer Rechenvorrichtung mit Unified Extensible Firmware Interface (UEFI), einer Ausführung einer Rückruffunktion eines Treibers, der einer Hardwarekomponente der Rechenvorrichtung zugeordnet ist; eine Hashmaschine, die mit der Erfassungsmaschine gekoppelt ist zum: Berechnen eines ersten Rückruffunktion-Hash einer Systemtabelle der UEFI, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und UEFI-Dienste speichert; Berechnen eines zweiten Rückruffunktion-Hash der Systemtabelle auf das Erfassen eines Abschlusses der Ausführung der Rückruffunktion hin; und eine Bestimmungsmaschine, die mit der Hashmaschine gekoppelt ist zum: Sicherstellen, ob sich der erste Rückruffunktion-Hash von dem zweiten Rückruffunktion-Hash unterscheidet, um eine Manipulation der Systemtabelle der UEFI zu bestimmen.
Das System gemäß Anspruch 11, bei dem die Erfassungsmaschine mit einem DXE-Dispatcher gekoppelt ist, wobei der DXE-Dispatcher eine Mehrzahl von Treibern, die einer Mehrzahl von Hardwarekomponenten der Rechenvorrichtung zugeordnet sind, während der Vor-Betriebssystem-Initialisierung der Rechenvorrichtung entdeckt und ausführt.
Das System gemäß Anspruch 11, das ferner eine Modifikationsmaschine aufweist, um Modifikationen, die an der Systemtabelle durchgeführt wurden, basierend auf der Bestimmung der Manipulation der Systemtabelle der UEFI rückgängig zu machen.
Ein nichtflüchtiges computerlesbares Medium, das Anweisungen aufweist, die durch eine Verarbeitungsressource ausführbar sind zum: Erfassen einer Ausführung eines Treibers, der einer Hardwarekomponente einer Rechenvorrichtung mit Unified Extensible Firmware Interface (UEFI) zugeordnet ist, in einer Treiberausführungsumgebung(DXE)-Phase während einer Vor-Betriebssystem-Initialisierung der Rechenvorrichtung; Berechnen eines ersten Treiberhash einer Systemtabelle der UEFI, wobei die Systemtabelle eine Datenstruktur ist, die Konfigurationseinzelheiten der Rechenvorrichtung und UEFI-Dienste speichert; Erfassen eines Abschlusses der Ausführung des Treibers; Berechnen eines zweiten Treiberhash der Systemtabelle auf den Abschluss der Ausführung des Treibers hin; Vergleichen des ersten Treiberhash mit dem zweiten Treiberhash; Erfassen einer Ausführung einer Rückruffunktion eines anderen Treibers, der einer anderen Hardwarekomponente der Rechenvorrichtung zugeordnet ist, in der DXE-Phase während der Vor-Betriebssystem-Initialisierung der Rechenvorrichtung; Berechnen eines ersten Rückruffunktion-Hash der Systemtabelle; Erfassen eines Abschlusses der Ausführung der Rückruffunktion; Berechnen eines zweiten Rückruffunktion-Hash der Systemtabelle auf den Abschluss der Ausführung der Rückruffunktion hin; Vergleichen des ersten Rückruffunktion-Hash mit dem zweiten Rückruffunktion-Hash; und basierend auf dem Vergleich von zumindest einem des ersten und zweiten Treiberhash und dem ersten und zweiten Rückruffunktion-Hash, Bestimmen einer Manipulation der Systemtabelle der UEFI.
Das nichtflüchtige computerlesbare Medium gemäß Anspruch 14, das ferner Anweisungen aufweist, die Ausführung von zumindest einem des Treibers und der Rückruffunktion des anderen Treibers während eines nachfolgenden Hochfahrens der Rechenvorrichtung zu blockieren.