16-05-17 – Driver Verifier

Software-Testing

16-05-17 – Driver Verifier

16 Mai 2017 - 15:25
OMS

Kennen Sie den Driver Verifier? Gerade bei der jüngeren Generation an Informatikern ist dieses nützliche Tool teilweise bereits etwas in Vergessenheit geraten. Als wir vor kurzem in einem Hyper-V PoC die neuesten Netzwerkkarten-Treiber installiert haben, verursachte dieser einen Bluescreen des Systems. Mit Hilfe des Microsoft Driver Verifier konnte das Problem in kurzer Zeit analysiert und gelöst werden. Aus diesem Grund habe ich mich entschieden, diesen Blogpost dem tollen Hilfsmittel zu widmen.

Der Driver Verifier ist fast so alt wie die «modernen» Windows-Betreibssysteme. Das Tool ist seit Windows 2000 fixer Bestandteil des Windows-Betriebssystems und kommt seit Windows XP mit einem grafischen Userinterface daher. Microsoft stellt unter https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/driver-verifier eine umfassende Dokumentation des Tools zur Verfügung.

Nun muss zuerst geklärt werden, um was es sich bei einem Blue Screen genau handelt. Ein Blue Screen ist ein Schutzmechanismus des Betriebssystems. Er wird nach bestimmten terminierenden Fehlern (sogenannten stop errors) aufgerufen, welche meist durch fehlerhafte, im Kernel laufende Treiber oder durch defekte Hardware ausgelöst werden. Ein klassisches Bespiel ist das Windows 98, welches sich am 20. April 1998 an der COMDEX vor einem Plug-and-Play Treiber eines Scanners schützte:

Zu den häufigsten Gründen für einen Blue Screen zählen sogenannte Memory Access Violations. Diese treten auf, wenn ein Programm wie ein Treiber einen nicht zugewiesenen Memory-Bereich referenzieren und damit auf den Adressbereich eines anderen Programms zugreifen will. Das Betriebssystem bemerkt dies und reagiert mit einem Blue Screen, um das System vor weiterem Schaden zu bewahren.

Grundsätzlich sollten wir davon ausgehen können, dass signierte Treiber vom Hersteller vor deren Veröffentlichung durch den Driver Verifier gelassen wurden und dadurch schon einen gewissen Reifegrad aufweisen. Dies scheint aber in unserem konkreten Fall nicht oder nur ungenügend passiert zu sein. Nun, dann nehmen wir das halt selber in Angriff.

Der Driver Verifier bietet verschiedene Test-Typen, welche Microsoft als Standard- und Additional klassifiziert. Die folgende Grafik zeigt einen Auszug aus der entsprechenden Auswahlliste.

mutznerblog1

Da die meisten Fehler mittels der Standard-Optionen identifiziert werden können, werden diese im Folgenden kurz vorgestellt.

Die Option Special Pool prüft den Treiber auf eine der häufigsten Probleme – die Memory Corruption. Dazu wird dem Treiber RAM aus einem abgeschotteten Bereich zugewiesen. Damit kann der Verifier überprüfen., ob der Treiber das Memory korrekt allokiert oder ob dieser auf Adressen unter- oder oberhalb des zugewiesenen Bereichs zugreifen will. Je nach Verhalten reagiert der Verifier mittels einem Bug Check 0xCD, 0xC1 oder 0xCC.

Mittels der Option Force IRQL (Interrupt Request Level) Checking wird das korrekte Verhalten des Treibers unter hoher Memory-Auslastung geprüft.

Wird Pool Tracking aktiviert, überprüft der Verifier, ob der Treiber nach dessen «unload» auch sämtliche allozierten Memory-Bereiche freigibt. Falls nicht, reagiert der Verifier mit einem Bug Check 0xC4.

Die Option I/O verification überwacht die Kommunikation des Treibers mit dem Memory.

Deadlock Detection analysiert den Code des Treibers mittels spezifischer Verfahren, um dessen Potenzial auf sogenannte Deadlocks festzustellen. Ein Deadlock in diesem Zusammenhang ist ein Konflikt, welcher bei einem zeitgleichen Zugriff von zwei oder mehreren Threads auf eine Ressource entstehen kann. Dies kann im schlimmsten Fall zu einem nicht mehr reagierenden System führen.

Bei der Aktivierung von DMA checking überwacht der Verifier die Implementierung von Direct Memory Access (DMA) des Treibers. Diese Technologie hat sich im Laufe der Windows-Versionen entwickelt und verändert, und einige Treiber basieren noch auf einer alten Implementierung. Falls der Verifier einen falschen oder fehlerhaften DMA Aufruf feststellt, reagiert er mit einem Bug Check 0xE6.

Die Optionen Security und Miscellaneous Checks machen eine Reihe von Tests in Bezug auf potenzielle Sicherheitslücken oder weitere bekannte Probleme von Treibern.

Die letzte Standard-Option ist das DDI compliance checking. Dabei wird der Treiber intensiv auf die korrekte Interaktion mit dem Kernel des Windows-Betriebssystems geprüft.

Nachdem die gewünschten Tests ausgewählt wurden, können die zu prüfenden Treiber selektiert werden. Es ist möglich, sämtliche Treiber gleichzeitig auf alle Standard-Options zu prüfen. Wenn umfangreichere Tests geplant sind, wie zum Beispiel auch die Option für die Simulierung von wenig Ressourcen (randomized low resources simulation), sollte nur ein Treiber ausgewählt werden. Ansonsten läuft man Gefahr, dass das System nicht mehr reagiert und die geschriebenen Logs nicht mehr oder nur noch sehr schwer auswertbar sind.

mutznerblog2

Je nach Fehler wird ein Blue Screen ausgelöst. Zudem zeichnet der Verifier diverse Parameter auf, welche dann ausgewertet werden können. In den Dumps finden sich in diesem Fall die Informationen, welche entweder selbst oder zusammen mit dem Hersteller des Treibers analysiert und so potenzielle Fehler des Treibers eingegrenzt und letztlich auch repariert werden können.

Es lohnt sich auf jeden Fall, sich intensiver mit dem Driver Verifier zu befassen und einen konkreten Hardware-Treiberstand der eingesetzten Systeme auf Herz und Nieren zu prüfen. Dies hilft wesentlich dabei, die Stabilität eines Systems im Betrieb hoch zu halten und nicht von plötzlichen Blue Screens überrascht zu werden.

Autor: Patrick Mutzner

November 2017
M D M D F S S
« Okt    
 12345
6789101112
13141516171819
20212223242526
27282930