Compartir a través de

Atributos extendidos del kernel

A partir de Windows 8, NTFS admite atributos extendidos del kernel. Verificar la firma de una imagen es una operación costosa. Almacenar información sobre si un binario validado previamente ha cambiado reduce el número de instancias en las que una imagen tiene que someterse a una comprobación de firma completa. El uso de EA del Kernel por este motivo aumenta el rendimiento de la validación de firmas de archivos de imagen.

Los EAs con el prefijo $Kernel solo se pueden modificar desde el modo núcleo. 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), primero debe emitir FSCTL_WRITE_USN_CLOSE_RECORD para confirmar las actualizaciones pendientes del diario de USN en el archivo. De lo contrario, el valor FileUSN podría cambiar poco después de establecer el atributo extendido del kernel.

Un Kernel EA debe contener al menos la siguiente información:

  • USN UsnJournalID

    • El campo UsnJournalID es un GUID que identifica la versión actual del archivo de diario USN. El diario USN se puede eliminar y crear desde el modo de usuario por cada volumen. Cada vez que se crea el USN Journal, se genera un nuevo UsnJournalID GUID. 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.

  • ARCHIVO USN

    • El valor fileUSN contiene el identificador de USN del último cambio realizado en el archivo y se realiza un seguimiento dentro del registro tabla de archivos maestros (MFT) del archivo especificado.
      • Cuando se elimina el diario de USN, FileUSN se restablece a cero.

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 EA válida.

Se ignora silenciosamente un intento de establecer un Atributo Extendido de kernel desde el modo de usuario. La solicitud devuelve STATUS_SUCCESS, pero no se realiza ninguna modificación real de EA.

Llamar a una API como ZwSetEaFile o FltSetEaFile para establecer un EA de kernel desde el modo kernel no es suficiente porque SMB permite la configuración de EAs a través de la red. Cuando una solicitud para establecer un EA pasa a través de SMB, se emite desde el modo kernel en el servidor que controla la solicitud SMB. Las solicitudes basadas en red podrían establecer de forma inapropiada un EA de Kernel localmente.

Para establecer un EA de kernel, quien llama también debe establecer el valor IRP_MN_KERNEL_CALL en el campo MinorFunction del IRP (paquete de solicitud de E/S). Dado que la única manera de establecer este campo es mediante la generación de un IRP personalizado, la rutina FsRtlSetKernelEaFile es la función de soporte técnico para configurar un EA de Kernel.

A partir de la versión 1803 de Windows 10, los EA de usuario y los EA 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 los AEs en un archivo desde el modo de usuario devuelve tanto AEs normales como de núcleo. Se devuelven al modo de usuario para minimizar cualquier problema de compatibilidad de aplicaciones. Las operaciones normales ZwQueryEaFile y FltQueryEaFile devuelven EAs normales y kernel de los modos de usuario y kernel.

Cuando solo hay un FileObject disponible, usar FsRtlQueryKernelEaFile puede ser más conveniente para consultar los EAs del kernel desde el modo kernel.

Consulta de la información del diario de número de secuencia de actualización

La operación de FSCTL_QUERY_USN_JOURNAL requiere SE_MANAGE_VOLUME_PRIVILEGE incluso cuando se emita desde el modo kernel a menos que el valor IRP_MN_KERNEL_CALL se establezca en el campo MinorFunction del IRP. La rutina FsRtlKernelFsControlFile permite fácilmente que los componentes en modo kernel emitan 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 USN ID del archivo ha cambiado puede ser costoso, ya que hay muchas razones benignas por las que una actualización de USN puede registrarse en el archivo. Para evitar volver a examinar innecesariamente, se añadió una función a NTFS para el autodelete de los Atributos Extendidos del Kernel.

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 del kernel comienza con: "$Kernel.Purge.", entonces, si se escribe alguna de las siguientes razones de USN en el journal USN, NTFS elimina todos los EA del kernel que existan en ese archivo y que se ajusten a la sintaxis de nomenclatura especificada.

  • RAZÓN_USN_SOBREESCRITURA_DE_DATOS
  • USN_REASON_DATA_EXTEND
  • Truncamiento de Datos USN
  • USN_MOTIVO_CAMBIO_PUNTO_DE_REANÁLISIS (USN_REASON_REPARSE_POINT_CHANGE)

Esta eliminación de EA de kernel se realiza correctamente incluso en situaciones de memoria baja.

Observaciones

Los componentes en modo de usuario no pueden alterar los atributos extendidos del kernel. Los EA de kernel pueden existir en el mismo archivo que un EA normal.

Véase también

FltQueryEaFile
FltSetEaFile
FSCTL_QUERY_USN_JOURNAL
FsRtlQueryKernelEaFileFsRtlSetKernelEaFile
ZwQueryEaFile
ZwSetEaFile

  • Last updated on