Atributos Extensíveis do Kernel
A partir do Windows 8, o NTFS suporta Atributos Estendidos do Kernel (EAs do Kernel). Verificar a assinatura de uma imagem é uma operação cara. O armazenamento de 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 aumenta o desempenho da validação de assinatura de arquivo de imagem.
EAs com o prefixo de nome $Kernel
só podem ser modificados a partir do modo kernel. Qualquer EA que comece com esta string é considerado um EA do kernel. Antes de recuperar o número de sequência de atualização (USN) necessário, você deve primeiro emitir FSCTL_WRITE_USN_CLOSE_RECORD para confirmar quaisquer atualizações pendentes do USN Journal no arquivo. Caso contrário, o valor FileUSN pode mudar logo após a configuração do EA do kernel.
Um EA do kernel deve conter pelo menos as seguintes informações:
USN UsnJournalID
- O campo UsnJournalID é um GUID que identifica a versão atual do USN Journal File. O USN Journal pode ser excluído e criado a partir do modo de utilizador por volume. Cada vez que o USN Journal é criado, um novo UsnJournalID GUID é gerado. Com este campo, você pode saber se houve um período de tempo em que o USN Journal foi desativado e pode revalidar.
- Esse valor pode ser recuperado usando FSCTL_QUERY_USN_JOURNAL.
- O campo UsnJournalID é um GUID que identifica a versão atual do USN Journal File. O USN Journal pode ser excluído e criado a partir do modo de utilizador por volume. Cada vez que o USN Journal é criado, um novo UsnJournalID GUID é gerado. Com este campo, você pode saber se houve um período de tempo em que o USN Journal foi desativado e pode revalidar.
Arquivo USN
- O valor FileUSN contém a ID USN da última alteração feita no arquivo e é rastreado dentro do registro MFT (Master File Table) para o arquivo determinado.
- Quando o Jornal USN é eliminado, o FileUSN é reiniciado para zero.
- O valor FileUSN contém a ID USN da última alteração feita no arquivo e é rastreado dentro do registro MFT (Master File Table) para o arquivo determinado.
Essas informações, juntamente com qualquer outra que um determinado uso possa precisar, são então definidas no arquivo como um EA do kernel.
Definindo um atributo estendido do kernel
Para definir um Kernel EA, deve começar com o prefixo "$Kernel."
seguido por um nome de EA válido.
Uma tentativa de definir um EA do Kernel a partir do modo de usuário é ignorada de forma silenciosa. A solicitação retorna STATUS_SUCCESS, mas nenhuma modificação real da EA é efetuada.
Chamar uma API como ZwSetEaFile ou FltSetEaFile para definir um EA do kernel a partir 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 através do SMB, ela é emitida do modo kernel no servidor que lida com a solicitação SMB. Solicitações baseadas em rede podem definir inadequadamente um EA do kernel 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 EA do kernel.
A partir do Windows 10 versão 1803, os EAs do usuário e os EAs do kernel podem ser misturados. Definir um EA do kernel não gera um registro de USN_REASON_EA_CHANGE para o USN Journal. O sistema gera USN_REASON_EA_CHANGE quando os EAs de qualquer utilizador forem definidos.
Consultando um atributo estendido
Consultar os EAs em um arquivo a partir do modo de usuário retorna EAs normais e do kernel. Eles retornam ao modo de usuário para minimizar quaisquer problemas de compatibilidade de aplicativos. As operações normais ZwQueryEaFile e as operações FltQueryEaFile retornam EAs normais e do kernel, tanto dos modos de usuário quanto dos modos de kernel.
Quando apenas um FileObject está disponível, usar FsRtlQueryKernelEaFile pode ser mais conveniente para consultar EAs do kernel a partir do modo kernel.
Consultando informações do registo do número de sequência de atualização
A operação FSCTL_QUERY_USN_JOURNAL requer SE_MANAGE_VOLUME_PRIVILEGE mesmo quando emitida no modo kernel, a menos que o valor IRP_MN_KERNEL_CALL tenha sido definido no campo MinorFunction do IRP. A rotina FsRtlKernelFsControlFile permite facilmente que componentes de modo kernel emitam essa solicitação USN.
NOTA A partir do Windows 10, versão 1703 e posterior, esta operação já não requer SE_MANAGE_VOLUME_PRIVILEGE.
Exclusão automática de atributos estendidos do kernel
Fazer uma nova varredura de um ficheiro apenas porque o ID USN do ficheiro mudou pode ser dispendioso, pois existem muitas razões benignas para uma atualização USN ser registada no ficheiro. Para evitar uma nova verificação desnecessária, um recurso para excluir automaticamente 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 USN forem gravados no diário USN, o NTFS excluirá todos os EAs do kernel existentes nesse arquivo que estejam em conformidade com a sintaxe de nomenclatura fornecida:
- Razão_USN_SOBRESCRITA_DE_DADOS
- USN_RAZÃO_EXTENSÃO_DE_DADOS
- TRUNCAMENTO DE DADOS USN_REASON
- Razão_USN_Mudança_de_Ponto_de_Reanálise
Esta exclusão de EAs do kernel é bem-sucedida mesmo em situações de pouca memória.
Comentários
Os componentes do modo de usuário não podem adulterar os EAs do kernel. Os EAs do kernel podem existir no mesmo arquivo que um EA normal.
Ver também
FltQueryEaFile
FltSetEaFile
FSCTL_QUERY_USN_JOURNAL
FsRtlQueryKernelEaFileFsRtlSetKernelEaFile
ZwQueryEaFile
ZwSetEaFile