Requisitos do controlador ELAM

A instalação do driver deve usar as ferramentas existentes para instalação on-line e off-line, registrando um driver através do processamento INF típico. Para obter um exemplo de código de driver ELAM, 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 arranque. O INF define o tipo de início 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 motorista ELAM anuncia seu grupo como "Lançamento antecipado". O comportamento de inicialização antecipada para drivers neste grupo será implementado no Windows, conforme descrito na próxima seção.

A seguir está um exemplo da seção de instalação de 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 Legacy para que o driver seja adicionado apenas como um serviço no registo. (Se o driver AM estiver instalado como um driver PNP normal, ele será adicionado à seção enum do registo e, portanto, terá uma referência PDO, o que levará a um comportamento indesejado 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 no caso de o driver ELAM estar inadvertidamente corrompido, 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 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 na chave de registro.

Inicialização do driver AM

O carregador de inicialização do Windows, Winload, carrega todos os drivers de inicialização e suas DLLs dependentes na memória antes da transferência para o kernel do Windows. Os controladores de arranque representam os controladores de dispositivo que precisam ser inicializados antes da pilha de discos ser inicializada. Esses drivers incluem, entre outros, a pilha de discos, o gestor de volumes, o driver do sistema de ficheiros e os drivers de barramento para o dispositivo do sistema operativo.

Interface de retorno de chamada do driver AM

Os drivers ELAM usam callbacks para fornecer ao gestor 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 como bom, binário conhecido como mau, ou um binário desconhecido.

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

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

Retornos de chamada do Registro

Os drivers de inicialização antecipada podem usar callbacks de registro ou de driver de arranque para monitorar e validar os dados de configuração usados como entrada para cada driver de arranque. Os dados de configuração são armazenados na colmeia do registro do sistema, que é carregada pelo Winload e está disponível no momento da inicialização dos controladores de arranque.

Esses retornos de chamada são válidos durante toda a vida útil do driver ELAM e não serão registrados quando o driver for descarregado. Para mais informações, consulte:

• 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 descreve dois tipos de callbacks:

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

Os dois tipos de retorno de chamada têm estruturas de contexto distintas que fornecem informações adicionais específicas de cada tipo de retorno de chamada.

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

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

Um erro retornado de um callback de atualização de status é tratado como um erro fatal e conduz a uma verificação de erros 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 foi carregado e inicializado, o driver de arranque antecipado pode falhar o retorno de chamada 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 é devolvido do callback de inicialização da imagem. Drivers desconhecidos são inicializados ou têm sua inicialização ignorada com base na 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 "Early Launch Drivers" em HKLM que é carregado pelo Winload. Cada driver AM tem uma chave exclusiva para armazenar seu BLOB (objeto binário grande) 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ários definidos que são medidos pela inicialização medida, e o fornecedor pode usar cada um:

• Medido
• Policy
• Configuração

A hive ELAM é descarregada após seu uso pelo Early Launch Antimalware para otimizar o desempenho. Se um serviço de modo de usuário quiser atualizar os dados da assinatura, ele deverá montar o arquivo hive a partir do local do arquivo \Windows\System32\config\ELAM. Por exemplo, você pode gerar um UUID, convertê-lo em uma cadeia de caracteres e usá-lo como uma chave exclusiva na qual montar a colmeia. O formato de armazenamento e recuperação desses BLOBs de dados é deixado para o ISV, mas os dados de assinatura devem ser assinados 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 cargo 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 assinaturas de malware.

Falha de 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 de execução AM assim que ele for iniciado.

Descarregando o driver AM

Quando o callback StatusType é BdCbStatusPrepareForUnload, isso indica ao driver AM que todos os drivers de inicialização foram inicializados, e que o driver AM deve se preparar para ser descarregado. Antes de descarregar, o driver AM de pré-inicialização precisa cancelar o registro de seus retornos de chamada. O cancelamento do registo não pode acontecer durante um retorno de chamada; em vez disso, deve ocorrer na função DriverUnload, que pode ser especificada por um driver durante o DriverEntry.

Para manter a continuidade da proteção contra malware e assegurar uma transferência adequada, o mecanismo AM de tempo de execução deve ser iniciado antes que o driver AM de inicialização antecipada seja descarregado. Isso significa que o motor AM em tempo de execução deve ser um driver de arranque verificado pelo driver AM de lançamento antecipado.

Desempenho

O condutor deve satisfazer os requisitos de desempenho definidos no quadro seguinte:

Inicializar controladores

Uma vez 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. Esta decisão é ditada pela política e está armazenada aqui no registo em:

HKLM\System\CurrentControlSet\Control\EarlyLaunch\DriverLoadPolicy

Isso pode ser configurado por meio da Diretiva de Grupo em um cliente 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á a tentar inicializar o próximo driver de inicialização na lista. Isso continua até que os drivers estejam todos inicializados, ou a inicialização falhe porque um driver de inicialização que foi omitido era crítico para a inicialização. Se a falha ocorrer depois que a pilha de discos for iniciada, haverá um despejo de crash, e este contém algumas informações sobre o motivo do crash, incluindo informações sobre os drivers ausentes. Isso pode ser usado no WinRE para determinar a causa da falha e tentar remediar.

ELAM e Bota Medida

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

Tbsi_Revoke_Attestation é chamável a partir do modo kernel. Ele estende a PCR[12] por um valor não especificado e incrementa o contador de eventos no TPM. Ambas as ações são necessárias, quebrando assim a confiança em todas as cotações que são criadas daqui em diante. Como resultado, os logs de inicialização medida não refletirão o estado atual do TPM durante o 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.