Freigeben über


Statustrennung

Die Zustandstrennung ist ein verbessertes Wartungs- und Sicherheitsmodell, das klarere Sicherheitsgrenzen verwendet, um:

  • Helfen Sie bei der Erhöhung der Sicherheit bei wichtigen Systembereichen
  • Schnellere und sauberere Updates und Systemrücksetzungen

Dieses Modell wird in allen Factory OS-Images verwendet. Die Sicherheitsgrenzen werden durch die folgenden Zustände klassifiziert:

State BESCHREIBUNG Beispiele
Unveränderlich Dieser Bereich kann nicht dauerhaft geändert werden, außer durch das Betriebssystem selbst.
  • Betriebssystem-Binärdateien
  • Registrierungsstruktur: HKLM\SYSTEM und HKLM\SOFTWARE
Stummschaltung, hoher Wert Sie können Änderungen vornehmen und erwarten, dass sie nach einem Neustart oder einem Update beibehalten werden, aber nicht nach dem Zurücksetzen des Systems
  • Systemeinstellungen
  • Protokolldateien
  • Programmdaten
    Hinweis: Verwenden Sie APIs oder Umgebungsvariablen wie %PROGRAMDATA%, um auf diese Ordner zu verweisen. Wenn Ihr Code absolute Pfade wie C:\Program Data\ oder Schreibvorgänge in andere Systembereiche enthält, schlägt der Schreibvorgang möglicherweise mit einer Zugriffsverletzung fehl.
Stummschaltbarer, niedriger Wert Sie können Änderungen vornehmen, aber sie werden nach einem Neustart oder einem Systemrücksetzung ausgeblendet. Einige Komponenten müssen möglicherweise in Registrierungsstruktur wie z.B. HKLM\SYSTEM und HKLM\SOFTWARE. Diese Registrierungsbereiche werden als veränderlich geladen, sodass Ihre Komponenten den Schreibvorgang für eine bestimmte Laufzeit weiterhin ausführen können. Nach dem nächsten Neustart werden die Änderungen ausgeblendet.
Benutzerdaten Kann geändert werden. Jedes Benutzerdatenprofil wird auf einer eigenen Partition verschlüsselt, sodass sich die Änderungen nur auf den Benutzer auswirken, wenn er angemeldet ist.
  • NT-Benutzerprofil
  • Registrierungsstruktur: HKCU

Bei Factorytests ist es OK, Protokolldateien und andere Testdateien entweder in der Datenpartition oder in. %PROGRAMDATA%

Staatstrennungsverletzungen

Zustandstrennungsverletzungen treten auf, wenn:

  • Eine Komponente versucht, in das Dateisystem auf dem MainOS-Volume zu schreiben.
  • Eine Komponente schreibt in die HKLM\SYSTEM oder HKLM\SOFTWARE Registrierungsstrukturen.

Damit Sie Komponenten entwickeln können, die diesen Regeln entsprechen, kann Windows protokollieren, wenn eine Komponente versucht, an einen dieser Speicherorte zu schreiben.

Hinweis: Nur weil Windows einen Schreibvorgang verfolgt, bedeutet nicht unbedingt ein Problem: Eine Komponente kann manchmal absichtlich in die Struktur HKLM\SYSTEM der HKLM\SOFTWARE Registrierung schreiben, die erwarten, dass die Änderung veränderlich ist.

Instrumentierung

Es gibt einige Methoden zum Sammeln von Protokollen der Registrierungs- und Dateisystemaktivität. Die Bestimmung der richtigen Zu verwendenden Methode hängt vom Anwendungsfall ab, und wenn in der Startsequenz der Treiber aktiv wird. Nachfolgend finden Sie eine Tabelle, in der zusammengefasst wird, wann jede Methode verwendet wird, um Statustrennung und Treiberisolationsverletzungen zu finden.

Methode Wann ausführen? Was bedeutet das?
Auto-Logger für den frühen Start Möchten Sie Dateiverletzungen finden, die mit der Treiberüberprüfung nicht gefunden werden können oder Datei- und Registrierungsverletzungen in derselben Ablaufverfolgung anzeigen möchten Alle Dateiverletzungen und die meisten Registrierungsverletzungen
On-Demand-Logger Möchten Sie Dateiverletzungen finden, die mit der Treiberüberprüfung nicht gefunden werden können oder Datei- und Registrierungsverletzungen in derselben Ablaufverfolgung anzeigen möchten Alle Dateiverletzungen und die meisten Registrierungsverletzungen
Startablaufverfolgung Möchten Sie detaillierte Stapelinformationen haben, die zu einer Verletzung führen Alle Datei- und Registrierungsvorgänge, unabhängig davon, ob sie ein Verstoß sind oder nicht
Überprüfung der Treiberisolation des Treiberüberprüfungstreibers Möchten Sie alle Registrierungsverletzungen während der Geräteaufverfolgung, allgemeine Treibertests und/oder Zertifizierungstests finden. Alle Dateiverletzungen und die meisten Registrierungsverletzungen

Echtzeitansicht von Verstößen

Die einfachste Methode zum Nachverfolgen von Statustrennungsverletzungen besteht darin, Ereignisablaufverfolgungen für Windows (ETW) echtzeit über das Windows-Geräteportal zu überprüfen.

Hinweis

Der Filtertreiber, der diese Telemetrie bereitstellt, kann nach ihrer Komponente geladen werden. Wenn Ihre Komponente früh im Startprozess ausgeführt wird, müssen Sie sich den nächsten Abschnitt ansehen.

  1. Melden Sie sich beim Windows-Geräteportal auf dem Gerät unter Test an.
  2. Wechseln Sie links zur Registerkarte ETW-Protokollierung.
  3. Aktivieren Sie unter Benutzerdefinierter Anbieter den folgenden Anbieter: d6e1490c-c3a6-4533-8de2-18b16ce47517 .
  4. Stellen Sie Ihr Szenario erneut vor. Verstöße werden in der Tabelle angezeigt.
  5. Wenn Sie ausreichende Daten gesammelt haben, klicken Sie auf Speichern in Datei, um eine Textdatei (.csv) abzurufen, die die erfassten Verletzungen enthält. Es ist oft einfacher, mit den heruntergeladenen Daten zu arbeiten als eine Echtzeitanalyse.

Early boot AutoLogger

Verwenden Sie einen frühen Start autoLogger, um ETW-Ablaufverfolgungen für Vorgänge zu erfassen, die früh im Startpfad ausgeführt werden:

  1. Stellen Sie eine Verbindung mit dem Gerät mit TShell her.

  2. Führen Sie Tracelog aus, um den Autologger zu konfigurieren, um die Anbieter-GUID zu hören: d6e1490c-c3a6-4533-8de2-18b16ce47517.

    Legen Sie Puffer auf 128 Kilobyte fest, mit mindestens 12 Puffern und maximal 34 Puffern (niedrigere Werte können dazu führen, dass Ereignisse gelöscht werden).

    Für die Sitzungs-GUID können Sie eine GUID mithilfeuuidgen einer GUID generieren und dann ein Nummernzeichen (#) hinzufügen, oder Sie können einen Dateinamen bereitstellen, der eine GUID enthält.

    Sie können die Protokolldatei überall speichern, obwohl wir empfehlen, einen Speicherort in den Benutzer- oder App-Datenordnern zu verwenden, z. B. -f %ProgramData%\Fabrikam\log.etl.

    Tracelog.exe -addautologger StateSeparationViolationsAutologger -sessionguid #aabbccdd-1234-5678-90ab-a00bb00ccdd -f %ProgramData%\Fabrikam\log.etl -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517 -b 128 -min 12 -max 34
    
  3. Starten Sie das Gerät neu, um die AutoLogger-Ablaufverfolgungssitzung zu starten

  4. Stellen Sie eine Verbindung mit dem Gerät mit TShell her.

  5. Beenden Sie die Automatische Protokollierung:

    Tracelog.exe -stop StateSeparationViolationsAutologger
    
  6. Rufen Sie die ETL-Datei ab, und überprüfen Sie die Daten:

    a. Erfassen Sie den Wert des ProgramData-Verzeichnisses des Geräts (z.B. E:\ProgramData).

    cmd-device -InformationVariable echoInfo echo %ProgramData% $deviceProgramData = $echoInfo[0]
    

    b. Verwenden Sie diesen Wert, um die ETL-Datei vom Gerät auf Ihren lokalen PC zu kopieren. Beispiel:

    PS C:\> getd E:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
    
  7. Überprüfen Sie die Aktivitätsdaten zur Ablaufverfolgung mithilfe von Windows Performance Analzyer (WPA) oder anderen Tools.

On-Demand-Logger

Verwenden Sie einen On-Demand-Logger, um eine On-Demand-ETW-Ablaufverfolgung zu erfassen.

  1. Konfigurieren Sie eine Protokollierungssitzung, um die Anbieter-GUID d6e1490c-c3a6-4533-8de2-18b16ce47517 zu hören:

    Tracelog.exe -start StateSeparationViolations -f <path to save ETL> -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517
    
  2. Stellen Sie Ihr Szenario vor, oder führen Sie Ihren Test aus (solange das Gerät nicht neu gestartet wird).

  3. Beenden Sie die Protokollierungssitzung.

    Tracelog.exe -stop StateSeparationViolations
    
  4. Kopieren Sie die ETL-Datei aus dem Gerät.

    PS C:\> getd C:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
    
  5. Öffnen Sie die Protokolldatei, und überprüfen Sie die Aktivitätsdaten der Ablaufverfolgung mithilfe von Windows Leistungsanalyse.

Startablaufverfolgung

Mit einer frühen Start-ETW-Ablaufverfolgung, die ordnungsgemäß eingerichtet wurde, können alle Registrierungsvorgänge und/oder Dateivorgänge in einer Ablaufverfolgung erfasst werden und stapelweise erfasst werden, die für jeden Vorgang erfasst werden, der den Codepfad enthält, der zu diesem Registrierungsvorgang führt.

  1. Stellen Sie eine Verbindung mit dem Gerät mit TShell her.

  2. Registrieren der Startablaufverfolgung (entweder Registrierung, Fileio oder beides)

    wpr -boottrace -addboot registry
    wpr -boottrace -addboot fileio
    
  3. Starten Sie das Gerät neu, um mit der Erfassung der Ablaufverfolgung zu beginnen.

  4. Stellen Sie eine Verbindung mit dem Gerät mit TShell her.

  5. Beenden Sie die Ablaufverfolgung.

    wpr -boottrace -stopboot <path where to write ETL>
    
  6. Kopieren Sie die ETL-Datei aus dem Gerät.

    PS C:\> getd C:\<path on device to the>\log.etl C:\hostdir\log.etl
    
  7. Öffnen Sie die Protokolldatei, und überprüfen Sie die Aktivitätsdaten der Ablaufverfolgung mithilfe von Windows Leistungsanalyse.

  8. Teilen Sie es in WPA mit, Symbole zu laden, damit die untersuchte Binärdatei in den Stapelablaufverfolgungen aufgelöst werden kann und dann eine Registrierungszusammenfassungstabelle öffnen.

    Es wird empfohlen, die Tabelle so zu filtern, dass nur Vorgänge in den SYSTEM- und SOFTWARE-Strukturen angezeigt werden. Wenn Sie die Spalte "Basisschlüsselstruktur" anzeigen, erweitern Sie DIE REGISTRIERUNG und dann DEN COMPUTER. Multiauswahl sowohl SYSTEM als auch SOFTWARE, klicken Sie mit der rechten Maustaste, und wählen Sie " Auswahl filtern" aus.

    Es wird empfohlen, die Tabelle nur auf Vorgänge zu filtern, bei denen der Stapel die binärdatei untersucht wird. Diese Filterung kann oben in der Filterung nur auf die oben empfohlene SYSTEM - und SOFTWARE-Struktur erfolgen. Klicken Sie in die Spalte Stapel, und öffnen Sie das Suchfeld. Geben Sie den Namen der zu untersuchenden Binärdatei ein, und klicken Sie auf Alle suchen. Klicken Sie mit der rechten Maustaste auf eine der hervorgehobenen Zeilen im Stapel, die den binären Namen enthalten, und wählen Sie Zu Auswahl filtern aus.

Überprüfung der Treiberisolation des Treiberüberprüfungstreibers

Gerätetreiber Verifizierer (DV) ist ein Tool, das mit Windows ausgeliefert wird, das verwendet wird, um Treiber auf fehlerhafte Funktionsaufrufe oder Aktionen zu überwachen, die das System beschädigen können. Ab Dem Betriebssystembuild 19568 verfügt Die Treiberüberprüfung über neue Funktionen, um Entwickler von Windows-Treibern zu unterstützen, indem Sie die Verletzung der Anforderungen an die Treiberpaketisolation überwachen. Die Treiberpaketisolation ist die wichtigste Anforderungstreiber, die auf Factory OS-Systemen eingehalten werden müssen, um die Zustandstrennungsanforderungen einzuhalten.

Die Treiberüberprüfung überwacht fehlerhafte Registrierungslese- und Schreibvorgänge, die auf Factory OS-Systemen nicht zulässig sind. Verwenden Sie dieses Tool frühzeitig bei der Treiberentwicklung, um zu verstehen und zu beheben, wo Ihre Komponente die Treiberisolationsanforderungen verletzt.

Syntax:

Hinweis

Wenn sie auf einem Factory OS-System aktiviert sind, lesen Sie bitte connect using SSH, um eine Remoteverbindung mit dem Factory OS-System über SSH herzustellen.

verifier /rc 33 36 /driver myDriver.sys

Dadurch wird die Treiberisolationsüberprüfung auf Ihren zielbezogenen Treiber (myDriver.sys) aktiviert. Sie können auch mehrere Treiber auswählen, indem Sie die Liste mit einem Leerzeichen trennen:

verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys

Ein Neustart ist erforderlich, damit die Überprüfungseinstellungen aktiviert werden. Sie können dazu das Cmdlet

shutdown /r /t 0

Erwartetes Verhalten – Telemetriemodus:

Während der Ersten Phasen des Treiber-Einfügevorgangs ist das empfohlene Verhalten für diese Prüfungen Telemetriemodus. Dies ist das Standardverhalten und bietet Entwicklern eine Möglichkeit, alle Verletzungen anzuzeigen, ohne dass ein Fehlercheck den Fortschritt beeinträchtigt.

Es wird empfohlen, die DV-Treiberisolationsüberprüfungen mithilfe der im abschnitt oben angegebenen Syntax mit einem kerneldebugger angefügten Kerneldebugger zu aktivieren. Nachdem ein Neustart die DV-Einstellungen aktiviert hat, können Sie Verstöße in der Kerneldebuggerausgabe sehen.

Nachfolgend finden Sie ein paar Beispielszenarien eines Treibers, der die Treiberisolationsanforderungen verletzt und wie die typische Ausgabe aussehen würde:

Szenario: ZwCreateKey mit vollständigem absoluten Pfad:

"DRIVER_ISOLATION_VIOLATION: Treibername<: >Registrierungsvorgänge sollten keine absoluten Pfade verwenden. Die Erstellung des nicht isolierten Registrierungsschlüssels '\Registry\Machine\SYSTEM' wurde erkannt"

Szenario: ZwCreateKey mit Pfad relativ zu einem Handle, der nicht von der genehmigten API stammt:

"DRIVER_ISOLATION_VIOLATION: Treibername<: >Registrierungsvorgänge sollten nur Schlüsselziehpunkte verwenden, die von WDF- oder WDM-APIs zurückgegeben werden. Die Erstellung des nicht isolierten Registrierungsschlüssels '\Registry\Machine\SYSTEM' wurde erkannt"

Nutzen Sie den Telemetriemodus, um einen Basisplan aller Verstöße für Ihre Komponente einzurichten und zu beheben, indem Sie diese einzeln beheben, während Sie gehen.

Erwartetes Verhalten – Bucheck-Modus:

Weiter im Treiberentwicklungsprozess kann es hilfreich sein, die Treiberisolierungsprüfungen in einem Modus zu ermöglichen, der eine Verletzung offensichtlich macht. DV kann so konfiguriert werden, dass eine Fehlerprüfung ausgelöst wird, wenn ein Verstoß auftritt.

Dadurch wird ein Speicherabbild generiert, das genaue Details dazu gibt, wo die Verletzung aufgetreten ist. Verwenden Sie die folgende Syntax, um DV im Bugcheckmodus zu aktivieren:

verifier /onecheck /rc 33 36 /driver myDriver1.sys

Dieser Modus ist nützlich, wenn sich der Treiber der Produktionsbereitschaft nähert und abschließende Phasen der Validierung und Tests durchlaufen wird.

Maximieren der Codepfade:

DV-Treiberisolationsregeln können während der Ausführung ihrer vorhandenen Testframeworks von IHV aktiviert werden. Dadurch werden die vom getesteten Treiber ausgeführten Codepfade maximiert.

Gerätegrundwerte-Tests über die Befehlszeile sind eine gute Basis für Tests, um typische Codepfade für Ihren Treiber zu üben. Entwickler können diese Tests mit DV-Treiberisolationsprüfungen aktivieren, um das Potenzial von Treiberisolationsverletzungen so früh wie möglich zu maximieren.

Entwicklungsmodus: Erzwingung deaktivieren

Für Entwicklungszwecke können Sie die Durchsetzung der Statustrennung deaktivieren, indem Sie den Zustandstrennungsmodus ausführen. Auf diese Weise können Sie Apps und Treiber (z. B. Factorytest-Apps) entwickeln, testen und ausführen, die nicht den Anforderungen entsprechen.

Im Entwicklungsmodus:

  • Die MainOS-Partition ist schreibbar.
  • Änderungen in HKLM\SYSTEM, und HKLM\SOFTWARE über Neustarts hinweg beibehalten.
  • Windows überwacht weiterhin Aktivitäten, die sonst die Regeln für die Zustandstrennung unterbrechen würden.

Sie können den Entwicklungsmodus zur Zeit der Bilderstellung konfigurieren, indem Sie das Feature durch ersetzen: STATESEPARATION_ON durch STATESEPARATION_DEVMODE.

In der folgenden Tabelle werden die Unterschiede zwischen den einzelnen Modus erläutert.

Zustandstrennungsmodus Unveränderlicher Dateisystemzugriff Unveränderlicher Registrierungszugriff
Erzwingungsmodus Schreibvorgänge nicht zulässig Registrierungsänderungen bleiben beim Neustart nicht bestehen
Verletzungswarnung in ETW- und Debugger-Ausgabe Verletzungswarnung in ETW- und Debugger-Ausgabe
Entwicklungsmodus Lese-/Schreibzugriff zulässig Registrierungsänderungen bleiben beim Neustart nicht bestehen
Verletzungswarnung in ETW- und Debugger-Ausgabe Verletzungswarnung in ETW- und Debugger-Ausgabe