Partager via

Attributs étendus du noyau

  • Article

À partir de Windows 8, NTFS prend en charge les attributs étendus du noyau (Kernel EA). La vérification de la signature d'une image est une opération coûteuse. Le stockage d'informations permettant de savoir si un fichier binaire précédemment validé a été modifié réduit le nombre de cas où une image doit faire l'objet d'une vérification complète de la signature. L'utilisation des EA du noyau pour cette raison augmente les performances de la validation de la signature du fichier image.

Les EA dont le nom est précédé du préfixe $Kernel ne peuvent être modifiées qu'à partir du mode noyau. Tout EA commençant par cette chaîne est considéré comme un EA du noyau. Avant de récupérer le numéro de séquence de mise à jour (USN) nécessaire, il est recommandé de lancer d'abord FSCTL_WRITE_USN_CLOSE_RECORD pour valider toutes les mises à jour du journal USN en attente sur le fichier qui ont pu avoir lieu précédemment Dans le cas contraire, la valeur FileUSN peut changer peu de temps après la définition de l'EA du noyau.

Il est recommandé qu'un EA du noyau contienne au moins les informations suivantes :

  • USN UsnJournalID

    • Le champ UsnJournalID est un GUID qui identifie l'incarnation actuelle du fichier journal USN. Le journal USN peut être supprimé et créé en mode utilisateur par volume. Chaque fois que le journal USN est créé, un nouveau GUID UsnJournalID est généré. Ce champ vous permet de savoir si le journal USN a été désactivé pendant un certain temps et de le revalider.

  • USN FileUSN

    • La valeur FileUSN contient l'ID de conteneur de la dernière modification apportée au fichier et est enregistrée dans la table des fichiers principaux (MFT) pour le fichier en question.
      • Lorsque le journal USN est supprimé, FileUSN est remis à zéro.

Cette information, ainsi que toute autre dont une utilisation donnée pourrait avoir besoin, est ensuite définie sur le fichier en tant qu'EA du noyau.

Définition d'un attribut étendu du noyau

Pour définir un EA du noyau, celui-ci doit commencer par le préfixe "$Kernel." suivi d'une chaîne de nom d'EA valide. Toute tentative de définition d'un EA du noyau à partir du mode utilisateur est ignorée. La requête renvoie STATUS_SUCCESS mais aucune modification de l'EA n'est effectuée. L'appel à une API telle que ZwSetEaFile ou FltSetEaFile pour définir un EA du noyau à partir du mode noyau n'est pas suffisant car SMB prend en charge la définition d'EA sur le réseau et ces requêtes sont émises à partir du mode noyau sur le serveur.

Pour définir un EA du noyau, l'appelant doit également définir la valeur IRP_MN_KERNEL_CALL dans le champ MinorFunction de l'IRP (paquet de requêtes d'E/S). Étant donné que le seul moyen de définir ce champ est de générer une IRP personnalisée, la routine FsRtlSetKernelEaFile a été exportée du package FsRtl en tant que fonction de support pour configurer un EA du noyau.

À partir de la version 1803 de Windows 10, les EA utilisateur et les EA noyau peuvent être mélangés. La configuration d'une EA de noyau ne génère pas d'enregistrement USN_REASON_EA_CHANGE dans le journal USN. Le système génère en revanche un enregistrement USN_REASON_EA_CHANGE lorsqu'une EA utilisateur est définie.

Interrogation d'un attribut étendu

L'interrogation des EA d'un fichier à partir du mode utilisateur renvoie des EA normales et des EA du noyau. Ils sont renvoyés en mode utilisateur afin de minimiser les problèmes de compatibilité avec les applications. Les opérations normales ZwQueryEaFile et FltQueryEaFile renvoient les EA normaux et ceux du noyau depuis les modes utilisateur et noyau.

Lorsque seul un FileObject est disponible, l'utilisation de FsRtlQueryKernelEaFile peut s'avérer plus pratique pour interroger les EA du noyau à partir du mode noyau.

Interrogation des informations du journal des numéros de séquence de mise à jour

L'opération FSCTL_QUERY_USN_JOURNAL nécessite SE_MANAGE_VOLUME_PRIVILEGE même lorsqu'elle est effectuée à partir du mode noyau, à moins que la valeur IRP_MN_KERNEL_CALL n'ait été définie dans le champ MinorFunction de l'IRP. La routine FsRtlKernelFsControlFile a été exportée du package FsRtl dans le noyau pour permettre facilement aux composants en mode noyau d'émettre cette requête USN.

NOTE À partir de Windows 10, version 1703 et suivantes, cette opération ne nécessite plus SE_MANAGE_VOLUME_PRIVILEGE.

Suppression automatique des attributs étendus du noyau

La simple réanalyse d'un fichier parce que l'ID USN du fichier a changé peut être coûteuse, car il existe de nombreuses raisons bénignes pour lesquelles une mise à jour USN peut être postée dans le fichier. Pour simplifier ce processus, une fonctionnalité de suppression automatique des EA du noyau a été ajoutée à NTFS.

Comme tous les EA du noyau ne souhaitent pas nécessairement être supprimés dans ce scénario, un nom de préfixe d'EA étendu est utilisé. Si un EA de noyau commence par : "$Kernel.Purge.", alors si l'un des motifs USN suivants est écrit dans le journal USN, NTFS supprime tous les EA de noyau qui existent sur ce fichier et qui sont conformes à la syntaxe de dénomination donnée :

  • USN_REASON_DATA_OVERWRITE
  • USN_REASON_DATA_EXTEND
  • USN_REASON_DATA_TRUNCATION
  • USN_REASON_REPARSE_POINT_CHANGE

Cette suppression des EA du noyau réussit même dans les situations où la mémoire est faible.

Notes

Les composants en mode utilisateur ne peuvent pas modifier les EA du noyau. Les EA du noyau peuvent exister dans le même fichier qu'un EA normal.

Voir aussi

FltQueryEaFile
FltSetEaFile
FSCTL_QUERY_USN_JOURNAL
FsRtlQueryKernelEaFileFsRtlSetKernelEaFile
ZwQueryEaFile
ZwSetEaFile