Attributs étendus du noyau

À compter de Windows 8, NTFS prend en charge les attributs étendus du noyau (AE du noyau). La vérification de la signature d’une image est une opération coûteuse. Le stockage d’informations sur la modification d’un binaire précédemment validé réduit le nombre d’instances où une image doit subir une vérification complète de la signature. L’utilisation d’EAs de noyau pour cette raison améliore les performances de la validation de la signature de fichier image.

Les attributs étendus ayant le préfixe de nom $Kernel ne peuvent être modifiés que depuis le mode noyau. Tout EA commençant par cette chaîne est considéré comme un EA de noyau. Avant de récupérer le numéro de séquence de mise à jour nécessaire (USN), vous devez d’abord émettre la commande FSCTL_WRITE_USN_CLOSE_RECORD pour enregistrer définitivement les mises à jour en attente dans le journal USN du fichier. Dans le cas contraire, la valeur FileUSN peut changer peu de temps après la définition du noyau EA.

Un noyau EA doit contenir 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éé à partir du mode utilisateur par volume. Chaque fois que le journal USN est créé, un GUID UsnJournalID est généré. Avec ce champ, vous pouvez déterminer s'il y a eu une période où le journal USN a été désactivé et peut être réactivé.
    • Cette valeur peut être récupérée à l’aide de FSCTL_QUERY_USN_JOURNAL.

• USN FileUSN

  • La valeur FileUSN contient l’ID USN de la dernière modification apportée au fichier et est suivie à l’intérieur de l’enregistrement MFT (Master File Table) pour le fichier donné.
    • Lorsque le journal USN est supprimé, FileUSN est réinitialisé à zéro.

Ces informations, ainsi que toute autre information nécessaire pour un usage donné, sont ensuite définies sur le fichier en tant qu'EA du noyau.

Définition d’un attribut étendu de noyau

Pour définir un noyau EA, il doit commencer par le préfixe "$Kernel." suivi d’une chaîne de nom EA valide.

Une tentative de définition d’un EA de noyau depuis le mode utilisateur est silencieusement ignorée. La requête retourne STATUS_SUCCESS mais aucune modification EA réelle n’est apportée.

L’appel d’une API comme ZwSetEaFile ou FltSetEaFile pour définir un noyau EA à partir du mode noyau n’est pas suffisant, car SMB autorise le paramètre des EA sur le réseau. Lorsqu’une demande de définition d’un contrat EA passe par SMB, elle est émise à partir du mode noyau sur le serveur qui gère la requête SMB. Les requêtes basées sur le réseau pourraient, de manière inappropriée, configurer un EA du noyau localement.

Pour définir un noyau EA, l’appelant doit également définir la valeur IRP_MN_KERNEL_CALL dans le champ MinorFunction du paquet de demande d’E/S (IRP). Étant donné que la seule façon de définir ce champ consiste à générer un IRP personnalisé, la routine FsRtlSetKernelEaFile est la fonction de prise en charge pour configurer un noyau EA.

À compter de Windows 10 version 1803, les EA utilisateur et les EAs de noyau peuvent être mélangées. La définition d’un noyau EA ne génère pas d’enregistrement USN_REASON_EA_CHANGE dans le journal USN. Le système génère USN_REASON_EA_CHANGE lorsque des EA utilisateur sont définies.

Interrogation d’un attribut étendu

L'interrogation des EA sur un fichier à partir du mode utilisateur retourne à la fois des EA normales et des EA du noyau. Ils sont retournés en mode utilisateur pour réduire les problèmes de compatibilité des applications. Les opérations ZwQueryEaFile et FltQueryEaFile normales retournent à la fois des EA normales et du noyau à partir des modes utilisateur et noyau.

Quand seul un FileObject est disponible, l’utilisation de FsRtlQueryKernelEaFile peut être plus pratique pour rechercher des EAs de noyau à partir du mode noyau.

Consultation des informations du journal de l'Update Sequence Number (USN)

L’opération de FSCTL_QUERY_USN_JOURNAL nécessite SE_MANAGE_VOLUME_PRIVILEGE même lorsqu’elle est émise à partir du mode noyau, sauf si la valeur IRP_MN_KERNEL_CALL a été définie dans le champ MinorFunction de l’IRP. La routine FsRtlKernelFsControlFile permet facilement aux composants en mode noyau d’émettre cette requête USN.

NOTE À compter de Windows 10, version 1703 et ultérieure, cette opération ne nécessite plus SE_MANAGE_VOLUME_PRIVILEGE.

Suppression automatique des attributs étendus du noyau

Ne scanner à nouveau un fichier que parce que l'ID USN a changé peut être coûteux, car il existe de nombreuses raisons bénignes pour lesquelles une mise à jour USN peut être effectuée pour ce fichier. Pour éviter une nouvelle analyse inutile, une fonctionnalité permettant de supprimer automatiquement les EA du noyau a été ajoutée à NTFS.

Étant donné que tous les EA de noyau ne souhaitent pas être supprimés dans ce scénario, un nom de préfixe EA étendu est utilisé. Si un EA de noyau commence par : "$Kernel.Purge.", alors si l’une des raisons USN suivantes est écrite dans le journal USN, NTFS supprime tous les EA de noyau existants sur ce fichier conformes à la syntaxe de nommage donnée.

• USN_REASON_DATA_OVERWRITE
• USN_REASON_DATA_EXTEND
• USN_RAISON_TRONCATION_DES_DONNÉES
• USN_REASON_REPARSE_POINT_CHANGE

Cette suppression d’EAs de noyau réussit même dans des situations de mémoire faible.

Remarques

Les composants en mode utilisateur ne peuvent pas altérer les EA du noyau. Les EA de noyau peuvent exister dans le même fichier qu’un ea normal.

Voir aussi

FltQueryEaFile
FltSetEaFile
FSCTL_QUERY_USN_JOURNAL
FsRtlQueryKernelEaFileFsRtlSetKernelEaFile
ZwQueryEaFile
ZwSetEaFile