Séparation d’état

  • Article

La séparation d’état est un modèle de maintenance et de sécurité amélioré qui utilise des limites de sécurité plus claires pour :

  • Contribuer à renforcer la sécurité dans les zones système clés
  • Activer des mises à jour et des réinitialisations système plus rapides et plus propres

Ce modèle est utilisé dans toutes les images de système d’exploitation d’usine. Les limites de sécurité sont classées selon les états suivants :

State Description Exemples
Immuable Cette zone ne peut pas être modifiée définitivement, sauf par le système d’exploitation lui-même.
  • Fichiers binaires du système d’exploitation
  • Ruches de registre : HKLM\SYSTEM et HKLM\SOFTWARE
Mutable, valeur élevée Vous pouvez apporter des modifications et vous attendre à ce qu’elles soient conservées après un redémarrage ou une mise à jour, mais pas après une réinitialisation du système
  • Paramètres système
  • Fichiers journaux
  • Données du programme.
    Remarque : Utilisez des API ou des variables d’environnement telles que %PROGRAMDATA% pour faire référence à ces dossiers. Si votre code inclut des chemins absolus comme C:\Program Data\ ou des écritures dans d’autres zones système, l’opération d’écriture peut échouer avec une violation d’accès.
Mutable, valeur faible Vous pouvez apporter des modifications, mais elles disparaîtront après un redémarrage ou une réinitialisation du système. Certains composants peuvent avoir besoin d’écrire dans des ruches de Registre, comme HKLM\SYSTEM et HKLM\SOFTWARE. Ces zones de Registre étant chargées comme volatiles, vos composants peuvent toujours effectuer l’opération d’écriture pour un runtime particulier. Au prochain redémarrage, les modifications disparaîtront.
Données utilisateur Peut être modifié. Chaque profil de données utilisateur étant chiffré sur sa propre partition, les modifications affectent uniquement l’utilisateur est connecté.
  • Profil utilisateur NT
  • Ruche du Registre : HKCU

Pour les tests d’usine, vous pouvez stocker des fichiers journaux et d’autres fichiers de test dans la partition de données ou dans %PROGRAMDATA%.

Violations de séparation d’état

Les violations de séparation d’état se produisent dans les cas suivants :

  • Un composant tente d’écrire dans le système de fichiers sur le volume MainOS.
  • Un composant écrit dans les ruches du HKLM\SYSTEM Registre ou HKLM\SOFTWARE .

Pour vous aider à développer des composants qui répondent à ces règles, Windows peut journaliser chaque fois qu’un composant tente d’écrire dans l’un de ces emplacements.

Notez que le fait que Windows effectue le suivi d’une opération d’écriture ne signifie pas nécessairement qu’il y a un problème : un composant peut parfois écrire intentionnellement dans les ruches du HKLM\SYSTEM Registre ou HKLM\SOFTWARE s’attendant à ce que la modification soit volatile.

Instrumentation

Il existe quelques méthodes pour collecter les journaux d’activité du registre et du système de fichiers. La détermination de la méthode appropriée à utiliser dépend du cas d’usage et du moment où, dans la séquence de démarrage, votre pilote devient actif. Vous trouverez ci-dessous un tableau qui résume quand utiliser chaque méthode pour rechercher les violations de séparation d’état et d’isolation des pilotes .

Méthode Quand exécuter ? Qu’est-ce qu’il trouve ?
Enregistreur d’événements automatiques de démarrage anticipé Vous souhaitez rechercher les violations de fichiers introuvables avec le vérificateur de pilote ou voir les violations de fichier et de Registre dans la même trace Toutes les violations de fichiers et la plupart des violations de registre
Enregistreur d’événements à la demande Vous souhaitez rechercher les violations de fichiers introuvables avec le vérificateur de pilote ou voir les violations de fichier et de Registre dans la même trace Toutes les violations de fichiers et la plupart des violations de registre
Trace de démarrage Vous souhaitez disposer d’informations détaillées sur la pile menant à une violation Toutes les opérations de fichier et de registre, qu’elles soient ou non une violation
Vérifications de l’isolation des pilotes du vérificateur de pilotes Vous souhaitez rechercher toutes les violations de Registre pendant l’affichage de l’appareil, les tests de pilotes génériques et/ou les tests de certification Aucune violation de fichier et toutes les violations de registre

Vue en temps réel des violations

La méthode la plus simple de suivi des violations de séparation d’état consiste à passer en revue les traces d’événements pour Windows (ETW) en temps réel via le portail d’appareil Windows.

Notes

Le pilote de filtre qui fournit ces données de télémétrie peut se charger après votre composant. Si votre composant est exercé au début du processus de démarrage, vous devez examiner la section suivante.

  1. Connectez-vous au portail d’appareil Windows, sur l’appareil testé
  2. Accédez à l’onglet Journalisation ETW à gauche.
  3. Sous Fournisseur personnalisé, activez le fournisseur suivant : d6e1490c-c3a6-4533-8de2-18b16ce47517 .
  4. Reprodiez votre scénario. Les violations s’affichent dans le tableau.
  5. Une fois que vous avez collecté suffisamment de données, cliquez sur Enregistrer dans le fichier pour obtenir un fichier texte (.csv) contenant les violations capturées. Il est souvent plus facile de travailler avec les données téléchargées que d’effectuer une analyse en temps réel.

Journalisation automatique de démarrage anticipé

Utilisez un autologger de démarrage précoce pour capturer les traces ETW pour les opérations effectuées au début du chemin de démarrage :

  1. Connectez-vous à l’appareil avec TShell.

  2. Exécutez Tracelog pour configurer l’auto-journal pour écouter le GUID du fournisseur : d6e1490c-c3a6-4533-8de2-18b16ce47517.

    Définissez les mémoires tampons sur 128 kilo-octets, avec un minimum de 12 mémoires tampons et un maximum de 34 mémoires tampons (des valeurs inférieures peuvent entraîner la suppression des événements).

    Pour le GUID de session, vous pouvez générer un GUID à l’aide uuidgen de , puis ajouter un signe numérique (#) avant celui-ci, ou vous pouvez fournir un nom de fichier qui inclut un GUID.

    Vous pouvez enregistrer le fichier journal n’importe où, mais nous vous recommandons d’utiliser un emplacement dans les dossiers de données de l’utilisateur ou de l’application, par -f %ProgramData%\Fabrikam\log.etlexemple .

    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. Redémarrez l’appareil pour commencer la session de trace AutoLogger

  4. Connectez-vous à l’appareil avec TShell.

  5. Arrêtez l’autologger :

    Tracelog.exe -stop StateSeparationViolationsAutologger

  6. Obtenez le fichier ETL et passez en revue les données :

    a. Capturez la valeur du répertoire ProgramData de l’appareil (par exemple, E:\ProgramData).

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

    b. Utilisez cette valeur pour copier le fichier ETL de l’appareil vers votre PC local. Exemple :

    PS C:\> getd E:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl

  7. Passez en revue les données d’activité de journalisation des traces à l’aide de Windows Performance Analzyer (WPA) ou d’autres outils.

Enregistreur d’événements à la demande

Utilisez un enregistreur d’événements à la demande pour capturer une trace ETW à la demande.

  1. Configurez une session de journalisation pour écouter le GUID du fournisseur d6e1490c-c3a6-4533-8de2-18b16ce47517 :

    Tracelog.exe -start StateSeparationViolations -f <path to save ETL> -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517

  2. Reproncez votre scénario ou exécutez votre test (tant que l’appareil ne redémarre pas).

  3. Arrêtez la session de journalisation.

    Tracelog.exe -stop StateSeparationViolations

  4. Copiez le fichier ETL hors de l’appareil.

    PS C:\> getd C:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl

  5. Ouvrez le fichier journal et passez en revue les données d’activité de journalisation des traces à l’aide de Windows Analyseur de performances.

Trace de démarrage

Avec une trace ETW de démarrage précoce configurée correctement, toutes les opérations de Registre et/ou opérations de fichier peuvent être capturées dans une trace et avoir des piles capturées pour chaque opération détaillant le chemin de code menant à cette opération de Registre.

  1. Se connecter à l’appareil avec TShell

  2. Inscrire la trace de démarrage (registry, fileio, ou les deux)

    wpr -boottrace -addboot registry
wpr -boottrace -addboot fileio

  3. Redémarrez l’appareil pour commencer à capturer la trace.

  4. Reconnectez-vous à l’appareil avec TShell.

  5. Arrêtez la trace :

    wpr -boottrace -stopboot <path where to write ETL>

  6. Copiez le fichier ETL hors de l’appareil.

    PS C:\> getd C:\<path on device to the>\log.etl C:\hostdir\log.etl

  7. Ouvrez le fichier journal et ouvrez les données d’activité de journalisation des traces à l’aide de Windows Analyseur de performances.

  8. Dans WPA, demandez-lui de charger des symboles afin que le fichier binaire en cours d’examen puisse être résolu dans les traces de pile, puis ouvrez une table récapitulative du Registre.

    Nous vous recommandons de filtrer la table pour afficher uniquement les opérations sur les ruches SYSTEM et SOFTWARE. Si vous affichez la colonne « arborescence de clé de base », développez REGISTRY , puis Machine. Sélectionnez plusieurs fois SYSTÈME et LOGICIEL, cliquez avec le bouton droit et sélectionnez Filtrer sur la sélection.

    Nous vous recommandons de filtrer la table uniquement sur les opérations où la pile implique l’examen du fichier binaire. Ce filtrage peut être effectué en plus du filtrage sur les ruches SYSTEM et SOFTWARE recommandées ci-dessus. Cliquez dans la colonne Pile et ouvrez la zone de recherche. Entrez le nom du fichier binaire en cours d’examen, puis cliquez sur Rechercher tout. Cliquez avec le bouton droit sur l’une des lignes en surbrillance de la pile contenant le nom binaire, puis sélectionnez Filtrer sur la sélection.

Vérifications de l’isolation du pilote du vérificateur de pilotes

Driver Verifier (DV) est un outil fourni avec Windows qui est utilisé pour surveiller les pilotes à la recherche d’appels de fonction incorrects ou d’actions susceptibles d’endommager le système. À compter de la build du système d’exploitation 19568, le vérificateur de pilotes dispose de nouvelles fonctionnalités pour prendre en charge les développeurs de pilotes Windows en surveillant les violations des exigences d’isolation du package de pilotes . L’isolation du package de pilotes est l’exigence clé que les pilotes doivent respecter sur les systèmes d’exploitation d’usine afin de respecter les exigences de séparation d’état.

Le vérificateur de pilote surveille les lectures et écritures de Registre incorrectes qui ne sont pas autorisées sur les systèmes de système d’exploitation d’usine. Utilisez cet outil au début du développement de pilotes pour comprendre et corriger les cas où votre composant enfreint les exigences d’isolation des pilotes.

Syntaxe :

Notes

Si vous activez sur un système d’exploitation d’usine, consultez Se connecter à l’aide de SSH pour vous connecter au système d’exploitation d’usine à distance via SSH

verifier /rc 33 36 /driver myDriver.sys

Cela permet de vérifier l’isolation des pilotes sur votre pilote ciblé (myDriver.sys). Vous pouvez également sélectionner plusieurs pilotes en séparant la liste par un espace :

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

Un redémarrage est nécessaire pour que les paramètres de vérification soient activés. Vous pouvez le faire en spécifiant :

shutdown /r /t 0

Comportement attendu - Mode de télémétrie :

Au cours des étapes initiales de l’affichage du pilote, le comportement recommandé pour ces vérifications est le mode de télémétrie. Il s’agit du comportement par défaut et permet aux développeurs d’afficher toutes les violations sans qu’une vérification d’erreur perturbe la progression.

Il est recommandé que les vérifications d’isolation des pilotes DV soient activées à l’aide de la syntaxe spécifiée dans la section ci-dessus avec un débogueur de noyau attaché. Une fois qu’un redémarrage a activé les paramètres DV, vous pouvez voir les violations dans la sortie du débogueur du noyau.

Voici quelques exemples de scénarios où un pilote ne respecte pas les exigences d’isolation des pilotes et à quoi ressemblerait la sortie classique :

Scénario : ZwCreateKey utilisant le chemin absolu complet :

« DRIVER_ISOLATION_VIOLATION : <nom> du pilote : les opérations de Registre ne doivent pas utiliser de chemins absolus. Détection de la création d’une clé de Registre « \Registry\Machine\SYSTEM » »

Scénario: ZwCreateKey utilisant le chemin relatif à un handle qui ne provient pas de l’API approuvée :

« DRIVER_ISOLATION_VIOLATION : <nom> du pilote : les opérations de Registre doivent utiliser uniquement les descripteurs de clé retournés par les API WDF ou WDM. Détection de la création de la clé de Registre « \REGISTRY\MACHINE\SYSTEM\SomeKeyThatShouldNotExist »

Tirez parti du mode de télémétrie pour établir une base de référence de toutes les violations pour votre composant et commencer à les corriger une par une, en testant au fur et à mesure.

Comportement attendu - Mode Bucheck :

Plus loin dans le processus de développement du pilote, il peut être utile d’activer les vérifications d’isolation des pilotes dans un mode qui rendra une violation évidente. DV peut être configuré pour induireabugcheck lorsqu’une violation se produit.

Cela génère un vidage de la mémoire qui fournit des détails précis sur l’endroit où la violation s’est produite. Pour activer DV en mode de vérification d’erreur, utilisez la syntaxe suivante :

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

Ce mode est utile lorsque le pilote est sur le point d’être prêt à la production et qu’il effectue les dernières étapes de validation et de test.

Optimisation des chemins d’accès au code :

Les règles d’isolation des pilotes DV peuvent être activées pendant l’exécution d’un IHV de leurs frameworks de test existants. Cela permet d’optimiser les chemins de code exercés par le pilote testé.

Les tests De base de l’appareil via la ligne de commande constituent une bonne base de référence de tests pour exercer des chemins de code standard pour votre pilote. Les développeurs peuvent activer ces tests avec des vérifications d’isolation des pilotes DV pour optimiser le potentiel de détection des violations d’isolation des pilotes le plus tôt possible.

Mode de développement : désactiver l’application

À des fins de développement, vous pouvez désactiver l’application de la séparation d’état en exécutant en mode de développement de séparation d’état. Cela vous permet de développer, tester et exécuter des applications et des pilotes (tels que des applications de test d’usine) qui ne sont pas conformes aux exigences.

En mode développement :

  • La partition MainOS est accessible en écriture.
  • Les modifications apportées à HKLM\SYSTEM, et HKLM\SOFTWARE sont conservées entre les redémarrages.
  • Windows continue de surveiller les activités qui, autrement, enfreindraient les règles de séparation d’état.

Vous pouvez configurer le mode développement au moment de la création de l’image en remplaçant la fonctionnalité : STATESEPARATION_ON par STATESEPARATION_DEVMODE.

Le tableau suivant détaille les différences entre chaque mode.

Mode de séparation d’état Accès immuable au système de fichiers Accès immuable au Registre
Mode Appliqué Écritures non autorisées Les modifications du Registre ne sont pas conservées pendant le redémarrage
Avertissement de violation dans la sortie ETW et débogueur Avertissement de violation dans la sortie ETW et débogueur
Dev Mode Lecture/écriture autorisée Les modifications du Registre persistent pendant le redémarrage
Avertissement de violation dans la sortie ETW et débogueur Avertissement de violation dans la sortie ETW et débogueur