Requisitos do Driver ELAM

A instalação do driver deve utilizar ferramentas existentes para instalação online e offline, registrando um driver por meio do processamento típico de INF. Para obter um código de driver ELAM de exemplo, consulte o seguinte: https://github.com/Microsoft/Windows-driver-samples/tree/main/security/elam

Instalação do driver AM

Para garantir a compatibilidade de instalação do driver, um driver ELAM se anuncia como um driver de inicialização semelhante a todos os outros drivers de inicialização. O INF define o tipo inicial como SERVICE_BOOT_START (0), o que indica que o driver deve ser carregado pelo carregador de inicialização e inicializado durante a inicialização do kernel. Um Driver ELAM anuncia seu grupo como "Early-Launch". O comportamento de inicialização antecipada para drivers nesse grupo será implementado no Windows, conforme descrito na próxima seção.

A seguir, um exemplo da seção de instalação do driver para um driver ELAM no arquivo INF.

[SampleAV.Service]
DisplayName    = %SampleAVServiceName%
Description    = %SampleAVServiceDescription%
ServiceType    = 1       ; SERVICE_KERNEL_DRIVER
StartType      = 0       ; SERVICE_BOOT_START
ErrorControl   = 3       ; SERVICE_ERROR_CRITICAL
LoadOrderGroup = “Early-Launch”

Como um driver AM não possui nenhum dispositivo, é necessário instalar o driver AM como um driver legado para que o driver seja adicionado apenas como um serviço no registro. (Se o driver AM estiver instalado como um driver PNP normal, ele será adicionado à seção de enumeração do registro e, portanto, terá uma referência de PDO, o que pode causar comportamentos indesejados ao descarregar o driver.)

Você também precisa incluir uma Seção SignatureAttributes no arquivo INF para o driver ELAM.

Instalação do Driver de Backup

Para fornecer um mecanismo de recuperação caso o driver ELAM esteja corrompido inadvertidamente, o instalador ELAM também instala uma cópia do driver em um local de backup. Isso permitirá que o WinRE recupere a cópia limpa e recupere a instalação.

O instalador lê o local do arquivo de backup a partir da chave BackupPath armazenada em

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EarlyLaunch

Em seguida, o instalador coloca a cópia de backup na pasta especificada no regkey.

Inicialização do driver AM

O carregador de inicialização do Windows, o Winload, carrega todos os drivers de inicialização e suas DLLs dependentes na memória antes da entrega para o kernel do Windows. Os drivers de inicialização de boot representam os drivers de dispositivo que precisam ser inicializados antes que a pilha de disco seja inicializada. Esses drivers incluem, entre outros, a pilha de disco e o gerenciador de volumes, o driver do sistema de arquivos e os drivers de barramento para o dispositivo do sistema operacional.

Interface de retorno de chamada do driver AM

Os drivers ELAM usam callbacks para fornecer ao gerenciador PnP uma descrição de cada driver de inicialização e DLL dependente, e ele pode classificar cada imagem de inicialização como um binário conhecido bom, binário conhecido ruim ou um binário desconhecido.

A política do sistema operacional padrão não é inicializar DLLs e drivers inválidos conhecidos. A política pode ser configurada e é medida pelo Winload como parte do atestado de inicialização.

O PnP usa a política e a classificação fornecida pelo driver AM para decidir se deve inicializar cada imagem de inicialização.

Retornos de chamada do Registro

Os drivers de inicialização antecipada podem usar retornos de chamada de driver de inicialização ou do registro do sistema para monitorar e validar os dados de configuração usados como entrada para cada driver de inicialização. Os dados de configuração são armazenados no hive do Registro do Sistema, que é carregado pelo Winload e está disponível no momento da inicialização do driver de inicialização.

Esses retornos de chamada são válidos durante o tempo de vida do driver ELAM e não serão registrados quando o driver for descarregado. Consulte mais informações em:

• CmRegisterCallbackEx
• CmRegisterCallback
• CmUnRegisterCallback

Retornos de chamada do driver de inicialização

Use IoRegisterBootDriverCallback e IoUnRegisterBootDriverCallback para registrar e cancelar o registro de um BOOT_DRIVER_CALLBACK_FUNCTION.

Esse retorno de chamada fornece atualizações de status do Windows para um driver ELAM, inclusive quando todos os drivers de inicialização foram inicializados e o recurso de retorno de chamada não está mais funcional.

Tipo de retorno de chamada

A enumeração BDCB_CALLBACK_TYPE define dois tipos de callbacks:

• Chamadas de retorno que fornecem atualizações de status para um driver ELAM (BdCbStatusUpdate)
• Callbacks usados pelo driver AM para classificar os drivers de inicialização e DLLs dependentes antes de inicializar as suas imagens (BdCbInitializeImage)

Os dois tipos de retorno de chamada têm estruturas de contexto exclusivas que fornecem informações adicionais específicas para o retorno de chamada.

A estrutura de contexto do retorno de chamada de atualização de status contém um único tipo enumerado que descreve o callout do Windows.

A estrutura de contexto para o retorno de chamada de inicialização de imagem é mais complexa, contendo informações de hash e certificado para cada imagem carregada. Além disso, a estrutura contém um campo que é um parâmetro de saída em que o driver AM armazena o tipo de classificação para o driver.

Um erro retornado de um retorno de chamada de atualização de status é tratado como um erro fatal e leva a uma verificação de bugs do sistema. Isso fornece a um driver ELAM a capacidade de indicar quando um estado é alcançado fora da política AM. Por exemplo, se um driver de tempo de execução AM não tiver sido carregado e inicializado, o driver Early Launch pode falhar no callback de preparação para descarregamento para impedir que o Windows entre em um estado sem um driver AM carregado.

Uma imagem é tratada como desconhecida quando um erro é retornado do callback de inicialização da imagem. Drivers desconhecidos são inicializados ou têm sua inicialização ignorada de acordo com a política do sistema operacional.

Assinaturas de malware

Os dados de assinatura de malware são determinados pelo ISV AM, mas devem incluir, no mínimo, uma lista aprovada de hashes de driver. Os dados de assinatura são armazenados no registro em um novo hive "Drivers de Inicialização Antecipada" em HKLM que é carregado pelo Winload. Cada driver AM tem uma chave exclusiva na qual armazenar seu objeto binário grande (BLOB) de assinatura. O caminho e a chave do Registro têm o formato:

HKLM\ELAM\<VendorName>\

Dentro da chave, o fornecedor é livre para definir e usar qualquer um dos valores. Há três valores de blob binário definidos que são medidos pelo Boot Medido e que o fornecedor pode utilizar cada um deles.

• Medido
• Policy
• Configuração

O hive ELAM é descarregado para melhorar o desempenho após seu uso pelo Antimalware de Inicialização Antecipada. Se um serviço de modo de usuário quiser atualizar os dados de assinatura, ele deverá montar o arquivo hive a partir do caminho do arquivo \Windows\System32\config\ELAM. Por exemplo, você pode gerar uma UUID, convertê-la em uma cadeia de caracteres e usá-la como uma chave exclusiva na qual montar o hive. O formato de armazenamento e recuperação desses BLOBs de dados fica a cargo do ISV. No entanto, deve-se assinar os dados para que o driver AM possa verificar a integridade dos dados.

Verificando assinaturas de malware

O método para verificar a integridade dos dados de assinatura de malware é deixado a critério de cada ISV de AM. As funções primitivas criptográficas CNG estão disponíveis para ajudar na verificação de assinaturas digitais e certificados nos dados de assinatura de malware.

Falha na assinatura de malware

Se o driver ELAM verificar a integridade dos dados de assinatura e essa verificação falhar ou se não houver dados de assinatura, a inicialização do driver ELAM ainda será bem-sucedida. Nesse caso, para cada driver de inicialização, o driver ELAM deve retornar "desconhecido" para cada retorno de chamada de inicialização. Além disso, o driver ELAM deve passar essas informações para o componente AM em tempo de execução assim que ele for iniciado.

Descarregando o driver AM

Quando o StatusType do callback é BdCbStatusPrepareForUnload, isso indica ao driver AM que todos os drivers de inicialização foram inicializados e que o driver AM deve preparar-se para ser descarregado. Antes de descarregar, o driver AM de inicialização precoce precisa desregistrar seus retornos de chamada. O desregistro não pode ocorrer durante um callback; em vez disso, ele precisa ocorrer na função DriverUnload, que um driver pode especificar durante o DriverEntry.

Para manter a continuidade na proteção contra malware e garantir a entrega adequada, o mecanismo AM de runtime deve ser iniciado antes do driver AM de inicialização antecipada ser descarregado. Isso significa que o mecanismo AM de runtime deve ser um driver de inicialização verificado pelo driver AM de lançamento inicial.

Desempenho

O driver deve atender aos requisitos de desempenho definidos na tabela a seguir.

Inicializando controladores

Depois que os drivers de inicialização são avaliados pelo driver ELAM, o Kernel usa a classificação retornada pelo ELAM para decidir se deseja inicializar o driver. Essa decisão é determinada pela política e é armazenada aqui no registro em:

HKLM\System\CurrentControlSet\Control\EarlyLaunch\DriverLoadPolicy

Isso pode ser configurado através das Políticas de Grupo em um dispositivo associado ao domínio. Uma solução antimalware pode querer expor essa funcionalidade ao usuário final em cenários não gerenciados. Os seguintes valores são definidos para DriverLoadPolicy:

PNP_INITIALIZE_DRIVERS_DEFAULT 0x0  (initializes known Good drivers only)
PNP_INITIALIZE_UNKNOWN_DRIVERS 0x1  
PNP_INITIALIZE_BAD_CRITICAL_DRIVERS 0x3 (this is the default setting)
PNP_INITIALIZE_BAD_DRIVERS 0x7

Falhas de inicialização

Se um driver de inicialização for ignorado devido à política de inicialização, o Kernel continuará tentando inicializar o próximo driver de inicialização na lista. Isso continua até que todos os drivers sejam inicializados ou a inicialização falhe porque um driver de inicialização que foi ignorado foi fundamental para a inicialização. Se a falha ocorrer após a inicialização da pilha de disco, haverá um despejo de memória que contém algumas informações sobre a causa da falha, incluindo dados sobre drivers ausentes. Isso pode ser usado no WinRE para determinar a causa da falha e tentar corrigir.

ELAM e Measured Boot

Se o driver ELAM detectar uma violação de política (um rootkit, por exemplo), ele deverá chamar imediatamente Tbsi_Revoke_Attestation para invalidar os PCRs que indicaram que o sistema estava em um bom estado. A função retornará um erro se houver um problema com a inicialização verificada, como a ausência de um TPM no sistema.

Tbsi_Revoke_Attestation pode ser chamado do modo kernel. Ele estende o PCR[12] com um valor não especificado e incrementa o contador de eventos no TPM. Ambas as ações são necessárias, portanto, a confiança é quebrada em todas as cotações que são criadas daqui para frente. Como resultado, os logs de Inicialização Medida não refletirão o estado atual do TPM pelo restante do tempo em que o TPM estiver ligado, e os sistemas remotos não poderão estabelecer confiança no estado de segurança do sistema.