Atributos estendidos do kernel

Do Windows 8 em diante, o NTFS oferece suporte aos EAs (atributos estendidos) do kernel. Verificar a assinatura de uma imagem é uma operação cara. Armazenar informações sobre se um binário validado anteriormente foi alterado reduz o número de instâncias em que uma imagem precisa passar por uma verificação de assinatura completa. O uso de EAs do kernel por esse motivo impulsiona o desempenho da validação da assinatura do arquivo de imagem.

EAs com o prefixo de nome $Kernel só podem ser modificados no modo kernel. Qualquer EA que comece com essa cadeia de caracteres é considerado um EA do kernel. Antes de recuperar o USN (número de sequência de atualização) necessário, primeiro você deve emitir FSCTL_WRITE_USN_CLOSE_RECORD para confirmar as atualizações pendentes do USN Journal no arquivo. Caso contrário, o valor FileUSN poderá ser alterado logo após a configuração do Kernel EA.

Um Kernel EA deve conter pelo menos as seguintes informações:

• USN UsnJournalID

  • O campo UsnJournalID é um GUID que identifica a encarnação atual do arquivo de diário de USN. O diário de USN pode ser excluído e criado no modo de usuário por volume. Cada vez que o diário de USN é criado, um novo GUID UsnJournalID é gerado. Com esse campo, você poderá saber se houve um período em que o diário de USN foi desativado e poderá revalidar.
    • Esse valor poderá ser recuperado usando o comando FSCTL_QUERY_USN_JOURNAL.

• USN FileUSN

  • O valor FileUSN contém a ID do USN da última alteração feita no arquivo e é rastreado dentro do registro da MFT (tabela mestra de arquivos) para o arquivo fornecido.
    • Quando o diário do USN é excluído, FileUSN é redefinido como zero.

Essas informações, juntamente com qualquer outra que um determinado uso possa precisar, são definidas no arquivo como um EA do kernel.

Configurar um atributo estendido do kernel

Para definir um EA do kernel, ele deve começar com o prefixo "$Kernel." seguido por uma cadeia de caracteres de nome de EA válida.

Uma tentativa de definir um EA do kernel no modo de usuário é ignorada silenciosamente. A solicitação retorna o valor STATUS_SUCCESS, mas nenhuma modificação real do EA é feita.

Chamar uma API como ZwSetEaFile ou FltSetEaFile para definir um Kernel EA do modo kernel não é suficiente porque o SMB permite a configuração de EAs em toda a rede. Quando uma solicitação para definir um EA vem por meio do SMB, ela é emitida do modo kernel no servidor que está tratando a solicitação SMB. Solicitações baseadas em rede podem configurar de forma inadequada um Kernel EA localmente.

Para definir um EA do kernel, o chamador também deve definir o valor IRP_MN_KERNEL_CALL no campo MinorFunction do IRP (pacote de solicitação de E/S). Como a única maneira de definir esse campo é gerando um IRP personalizado, a rotina FsRtlSetKernelEaFile é a função de suporte para configurar um Kernel EA.

Do Windows 10 versão 1803 em diante, os EAs de usuário e os EAs do kernel poderão ser misturados. Definir um EA do kernel não gera um registro USN_REASON_EA_CHANGE para o diário de USN. O sistema gera USN_REASON_EA_CHANGE quando qualquer EA de usuário é definido.

Consultar um atributo estendido

Consultar os EAs em um arquivo no modo de usuário retorna EAs normais e do kernel. Eles são retornados ao modo de usuário para minimizar problemas de compatibilidade de aplicativos. As operações normais ZwQueryEaFile e FltQueryEaFile retornam AEs normais e de kernel a partir dos modos de usuário e kernel.

Quando apenas um FileObject está disponível, o uso de FsRtlQueryKernelEaFile pode ser mais conveniente para consultar os EAs do Kernel no modo kernel.

Consultar informações do diário de número de sequência de atualização

A operação FSCTL_QUERY_USN_JOURNAL requer SE_MANAGE_VOLUME_PRIVILEGE mesmo quando emitida do modo kernel, a menos que o valor IRP_MN_KERNEL_CALL tenha sido definido no campo MinorFunction do IRP. A rotina FsRtlKernelFsControlFile permite que os componentes do modo kernel emitam facilmente essa solicitação USN.

OBSERVAÇÃO Do Windows 10 versão 1703 e posterior em diante, essa operação não exige mais SE_MANAGE_VOLUME_PRIVILEGE.

Exclusão automática de atributos estendidos do kernel

Reanalisar um arquivo simplesmente porque a alteração na ID de USN do arquivo pode ser cara, pois há muitas razões benignas para que uma atualização USN possa ser registrada no arquivo. Para evitar a verificação desnecessária, um recurso para autoexcluir os EAs do Kernel foi adicionado ao NTFS.

Como nem todos os EAs do Kernel podem querer ser excluídos nesse cenário, um nome de prefixo EA estendido é usado. Se um EA do kernel começar com: "$Kernel.Purge.", então, se qualquer um dos seguintes motivos de USN for gravado no diário do USN, o NTFS excluirá todos os EAs do kernel existentes no arquivo em questão que estejam em conformidade com a sintaxe de nomenclatura fornecida:

• USN_REASON_DATA_OVERWRITE
• USN_REASON_DATA_EXTEND
• USN_REASON_DATA_TRUNCATION
• USN_REASON_REPARSE_POINT_CHANGE

Essa exclusão de EAs do Kernel é bem-sucedida mesmo em situações de memória baixa.

Comentários

Os componentes do modo de usuário não podem adulterar EAs do kernel. Os EAs do kernel podem existir no mesmo arquivo que um EA normal.

Confira também

FltQueryEaFile
FltSetEaFile
FSCTL_QUERY_USN_JOURNAL
FsRtlQueryKernelEaFileFsRtlSetKernelEaFile
ZwQueryEaFile
ZwSetEaFile