Atributos extendidos de kernel
A partir de Windows 8, NTFS admite atributos extendidos de kernel (EA de kernel). Comprobar la firma de una imagen es una operación costosa. Almacenar información sobre si se ha modificado un binario previamente validado reduce el número de casos en los que una imagen debe someterse a una comprobación de firma completa. El uso de EA de kernel por este motivo aumenta el rendimiento de la validación de firmas de archivo de imagen.
Los EA con el prefijo de nombre $Kernel solo se pueden modificar desde el modo kernel. Cualquier EA que comience con esta cadena se considera un EA de kernel. Antes de recuperar el número de secuencia de actualización necesario (USN), se recomienda emitir primero FSCTL_WRITE_USN_CLOSE_RECORD para confirmar las actualizaciones pendientes del diario de USN en el archivo que pueden haberse producido anteriormente. De lo contrario, el valor de FileUSN puede cambiar poco después de establecer el EA de kernel.
Se recomienda que un EA de kernel contenga al menos la siguiente información:
UsnJournalID de USN
- El campo UsnJournalID es un GUID que identifica la aparición actual del archivo de diario USN. El diario USN se puede eliminar y crear a partir del modo de usuario por volumen. Cada vez que se crea el diario USN, se genera un nuevo GUID de UsnJournalID. Con este campo, puede indicar si hubo un período de tiempo en el que se deshabilitó el diario USN y puede volver a validarse.
- Este valor se puede recuperar mediante FSCTL_QUERY_USN_JOURNAL.
- El campo UsnJournalID es un GUID que identifica la aparición actual del archivo de diario USN. El diario USN se puede eliminar y crear a partir del modo de usuario por volumen. Cada vez que se crea el diario USN, se genera un nuevo GUID de UsnJournalID. Con este campo, puede indicar si hubo un período de tiempo en el que se deshabilitó el diario USN y puede volver a validarse.
FileUSN de USN
- El valor de FileUSN contiene el identificador de USN del último cambio realizado en el archivo y se realiza un seguimiento dentro del registro de la tabla de archivos maestros (MFT) del archivo especificado.
- Cuando se elimina el diario de USN, FileUSN se restablece a cero.
- El valor de FileUSN contiene el identificador de USN del último cambio realizado en el archivo y se realiza un seguimiento dentro del registro de la tabla de archivos maestros (MFT) del archivo especificado.
Esta información, junto con cualquier otro uso determinado que necesite, se establece en el archivo como un EA de kernel.
Establecimiento de un atributo extendido de kernel
Para establecer un EA de kernel, debe comenzar con el prefijo "$Kernel." seguido de una cadena de nombre de EA válida. Se omite silenciosamente un intento de establecer un EA de kernel desde el modo de usuario. La solicitud devuelve STATUS_SUCCESS pero no se realiza ninguna modificación real del EA. Llamar a una API como ZwSetEaFile o FltSetEaFile para establecer un EA de kernel desde el modo kernel no es suficiente porque SMB admite la configuración de EA a través de la red y esas solicitudes se emiten desde el modo kernel en el servidor.
Para establecer un EA de kernel, el llamador también debe establecer el valor IRP_MN_KERNEL_CALL en el campo MinorFunction del IRP (paquete de solicitud de E/S). Puesto que la única manera de establecer este campo es mediante la generación de un IRP personalizado, la rutina FsRtlSetKernelEaFile se ha exportado desde el paquete FsRtl como una función de soporte para configurar un EA de kernel.
A partir de la versión 1803 de Windows 10, los EA de usuario y de kernel se pueden mezclar. Establecer un EA de kernel no genera un registro de USN_REASON_EA_CHANGE en el diario USN. El sistema genera USN_REASON_EA_CHANGE cuando se establecen EA de usuario.
Consulta de un atributo extendido
La consulta de EA en un archivo desde el modo de usuario devuelve EA normales y de kernel. Se devuelven al modo de usuario para minimizar cualquier problema de compatibilidad de aplicaciones. Las operaciones normales ZwQueryEaFile y FltQueryEaFile devuelven EA normales y de kernel de los modos de usuario y kernel.
Cuando solo hay un FileObject disponible, el uso de FsRtlQueryKernelEaFile puede ser más cómodo de usar para consultar EA de kernel desde el modo kernel.
Consulta de la información del diario de número de secuencia de actualización
La operación FSCTL_QUERY_USN_JOURNAL requiere SE_MANAGE_VOLUME_PRIVILEGE incluso cuando se emite desde el modo kernel, a menos que el valor de IRP_MN_KERNEL_CALL se haya establecido en el campo MinorFunction del IRP. La rutina FsRtlKernelFsControlFile se ha exportado desde el paquete FsRtl en el kernel para que los componentes del modo kernel puedan emitir fácilmente esta solicitud USN.
NOTA A partir de Windows 10, versión 1703 y posteriores, esta operación ya no requiere SE_MANAGE_VOLUME_PRIVILEGE.
Eliminación automática de atributos extendidos del kernel
Simplemente volver a examinar un archivo porque el ID de USN del archivo cambió puede ser costoso, ya que hay muchas razones válidas por las que se puede publicar una actualización USN en el archivo. Para simplificarlo, se agregó una característica de eliminación automática de EA de kernel a NTFS.
Dado que es posible que no todos los EA de kernel quieran eliminarse en este escenario, se usa un nombre de prefijo de EA extendido. Si un EA de kernel comienza por: "$Kernel.Purge.", si alguno de los siguientes motivos de USN se escribe en el diario USN, NTFS elimina todos los EA de kernel que existen en ese archivo que se ajustan a la sintaxis de nomenclatura especificada:
- USN_REASON_DATA_OVERWRITE
- USN_REASON_DATA_EXTEND
- USN_REASON_DATA_TRUNCATION
- USN_REASON_REPARSE_POINT_CHANGE
Esta eliminación de EA de kernel se realiza correctamente incluso en situaciones de poca memoria.
Comentarios
Los componentes en modo de usuario no pueden alterar los EA de kernel. Los EA de kernel pueden existir en el mismo archivo que un EA normal.
Consulte también
FltQueryEaFile
FltSetEaFile
FSCTL_QUERY_USN_JOURNAL
FsRtlQueryKernelEaFileFsRtlSetKernelEaFile
ZwQueryEaFile
ZwSetEaFile