Partager via

Séparation de l’é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 domaines système clés
  • Activer les mises à jour plus rapides et plus propres et les réinitialisations système

Ce modèle est utilisé dans toutes les images de système d’exploitation Factory. Les limites de sécurité sont classées par 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 du Registre : HKLM\SYSTEM et HKLM\SOFTWARE
Mutable, valeur élevée Vous pouvez apporter des modifications et s’attendre à ce qu’elles persistent 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, faible valeur 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 telles que HKLM\SYSTEM et HKLM\SOFTWARE. Ces zones de Registre sont chargées comme volatiles, de sorte que vos composants peuvent toujours effectuer l’opération d’écriture pour un runtime particulier. Lors du prochain redémarrage, les modifications disparaîtront.
Données utilisateur Peut être modifié. Chaque profil de données utilisateur est chiffré sur sa propre partition, de sorte que les modifications affectent uniquement l’utilisateur est connecté.
  • Profil utilisateur NT
  • Ruche du Registre : HKCU

Pour les tests de fabrique, il est ok de stocker les 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 quand :

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

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, simplement parce que Windows effectue le suivi d’une opération d’écriture ne signifie pas nécessairement qu’il existe un problème : un composant peut parfois écrire intentionnellement dans les HKLM\SYSTEM ruches du registre ou HKLM\SOFTWARE s’attendre à 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, 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.

Method Quand exécuter ? Que trouve-t-il ?
Enregistreur automatique de démarrage anticipé Vous souhaitez rechercher des violations de fichier 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 des violations de fichier 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, indépendamment de leur violation ou non
Vérifications de l’isolation des pilotes du vérificateur de pilotes Vous souhaitez rechercher toutes les violations de Registre lors de l’affichage de l’appareil, des tests de pilotes génériques et/ou des tests de certification Aucune violation de fichier et toutes les violations de Registre

Affichage en temps réel des violations

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

Remarque

Le pilote de filtre qui fournit cette télémétrie peut se charger après votre composant. Si votre composant est exercé tôt dans le processus de démarrage, vous devez examiner la section suivante.

  1. Connectez-vous au portail d’appareil Windows, sur l’appareil sous test
  2. Accédez à l’onglet Journalisation ETW sur la gauche.
  3. Sous Fournisseur personnalisé, activez le fournisseur suivant : d6e1490c-c3a6-4533-8de2-18b16ce47517 .
  4. Reprovisionnez votre scénario. Les violations s’affichent dans le tableau.
  5. Lorsque 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 d’utiliser les données téléchargées que d’effectuer une analyse en temps réel.

AutoLogger de démarrage précoce

Utilisez un autologger de démarrage précoce pour capturer les traces ETW pour les opérations effectuées tôt dans le chemin d’amorçage :

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

  2. Exécutez Tracelog pour configurer l’autologger 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 (les 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 d’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ù, même si nous vous recommandons d’utiliser un emplacement dans les dossiers de données utilisateur ou d’application, tels que -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. 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. Reprovisionnez 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

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

  1. Se connecter à l’appareil avec TShell

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

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

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

  4. Connectez-vous à l’appareil à nouveau 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, indiquez-lui de charger des symboles afin que le fichier binaire examiné 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és de base », développez REGISTRY , puis MACHINE. Sélectionnez à la fois SYSTEM et SOFTWARE, cliquez avec le bouton droit et sélectionnez Filtrer dans la sélection.

    Nous vous recommandons de filtrer la table uniquement sur les opérations où la pile implique l’examen binaire. Ce filtrage peut être effectué au-dessus du filtrage uniquement sur la ruche SYSTÈME et SOFTWARE recommandée 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 mises en surbrillance dans la pile qui contenaient le nom binaire, puis sélectionnez Filtrer vers la sélection.

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

Le vérificateur de pilotes (DV) est un outil fourni avec Windows qui est utilisé pour surveiller les pilotes pour les appels ou actions de fonction incorrects qui peuvent endommager le système. À compter de la build du système d’exploitation 19568, Driver Verifier 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 la condition essentielle que les pilotes doivent respecter sur les systèmes de système d’exploitation Factory afin de respecter les exigences de séparation d’état.

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

Syntaxe :

Remarque

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

verifier /rc 33 36 /driver myDriver.sys

Cela active les vérifications d’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 sera nécessaire pour que les paramètres de vérification soient activés. Pour ce faire, spécifiez :

shutdown /r /t 0

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

Au cours des premières étapes 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 vérification de bogues qui perturbent 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 serez en mesure de voir les violations dans la sortie du débogueur du noyau.

Voici quelques exemples de scénarios d’un conducteur qui enfreint les exigences d’isolation des pilotes et de ce que la sortie classique ressemblerait à :

Scénario : ZwCreateKey à l’aide du 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 isolée '\Registry\Machine\SYSTEM'"

Scénario : ZwCreateKey utilisant le chemin d’accès 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 handles de clé retournés par les API WDF ou WDM. Détection de la création d’une clé de Registre isolée '\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 un par un, en testant à mesure que vous le faites.

Comportement attendu - Mode Bucheck :

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

Cela génère un vidage de 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 de bogue, utilisez la syntaxe suivante :

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

Ce mode est utile lorsque le pilote approche de la préparation de la production et subit des phases finales de validation et de test.

Optimisation des chemins de 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 des tests pour exercer des chemins de code classiques 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étecter les violations d’isolation des pilotes dès que 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 s’exécutant en mode dev de séparation d’état. Cela vous permet de développer, de tester et d’exécuter des applications et des pilotes (tels que des applications de test d’usine) qui ne respectent pas les exigences.

En mode développement :

  • La partition MainOS est accessible en écriture.
  • Modifications apportées aux HKLM\SYSTEMredémarrages et HKLM\SOFTWARE persister entre les redémarrages.
  • Windows continue de surveiller les activités qui interrompent autrement 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é par STATESEPARATION_ON 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 lors du redémarrage
Avertissement de violation dans la sortie et le débogueur Avertissement de violation dans la sortie et le débogueur
Mode de développement Lecture/écriture autorisée Les modifications du Registre persistent lors du redémarrage
Avertissement de violation dans la sortie et le débogueur Avertissement de violation dans la sortie et le débogueur