Requisitos do driver ELAM

Artigo
06/15/2023

A instalação do driver deve usar ferramentas existentes para instalação online e offline, registrando um driver por meio do processamento inf típico. 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 "Início Antecipado". O comportamento de inicialização antecipada para drivers nesse grupo será implementado no Windows, conforme descrito na próxima seção.

Veja a seguir um exemplo da seção de instalação do driver de um DRIVER ELAM 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 Herdado 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 enumeração do registro 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 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 o limpo copiar e recuperar 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 regkey.

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 entrega para o kernel do Windows. Os drivers de inicialização 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 discos e o gerenciador de volumes, o driver do sistema de arquivos e os drivers de ônibus para o dispositivo do sistema operacional.

Interface de retorno de chamada do driver AM

Os drivers ELAM usam retornos de chamada 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 bom conhecido, binário ruim conhecido ou um binário desconhecido.

A política padrão do sistema operacional não é inicializar drivers e DLLs 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 fornecidas pelo driver AM para decidir se deseja inicializar cada imagem de inicialização.

Retornos de chamada do Registro

Os drivers de Inicialização Antecipada podem usar retornos de chamada do registro ou do driver de inicialização 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.

Observação

Todas as alterações no hive do registro ELAM são descartadas antes da inicialização do sistema. Como resultado, um driver ELAM deve usar o log padrão do ETW (Rastreamento de Eventos para Windows) em vez de gravar no registro.

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. Para saber mais, veja:

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 status do Windows para um driver ELAM, incluindo quando todos os drivers de inicialização foram inicializados e a instalação de retorno de chamada não está mais funcional.

Tipo de retorno de chamada

A enumeração BDCB_CALLBACK_TYPE descreve dois tipos de retornos de chamada:

Retornos de chamada que fornecem atualizações status 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 exclusivas que fornecem informações adicionais específicas para o retorno de chamada.

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

A estrutura de contexto para o retorno de chamada inicializar 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 status é tratado como um erro fatal e leva a um bug do sistema marcar. Isso fornece a um driver ELAM a capacidade de indicar quando um estado é atingido fora da política am. Por exemplo, se um driver de runtime am não tiver sido carregado e inicializado, o driver de Inicialização Antecipada poderá falhar no retorno de chamada de preparação para descarregar para impedir que o Windows entre em um estado sem um driver AM carregado.

Uma imagem é tratada como desconhecida quando um erro é retornado do retorno de chamada inicializar 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 "Drivers de Inicialização Antecipada" em HKLM carregado pelo Winload. Cada driver AM tem uma chave exclusiva na qual 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ário definidos que são medidos pela Inicialização Medida e o fornecedor pode usar cada um:

Medido
Política
Config

O hive ELAM é descarregado após seu uso pelo Antimalware de Inicialização Antecipada para desempenho. Se um serviço de modo de usuário quiser atualizar os dados de assinatura, ele deverá montar o arquivo hive do local 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 é 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 para cada ISV am. As funções primitivas criptográficas CNG estão disponíveis para ajudar a verificar 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 esse marcar falhar ou se não houver dados de assinatura, a inicialização do driver ELAM ainda terá êxito. 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 do runtime assim que ele for iniciado.

Descarregando o driver AM

Quando o StatusType de retorno de chamada é BdCbStatusPrepareForUnload, isso é uma indicação para o driver AM de 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 inicialização antecipada precisa desregistrar seus retornos de chamada. O cancelamento do registro não pode ocorrer durante um retorno de chamada; em vez disso, isso precisa acontecer na função DriverUnload, que um driver pode especificar durante 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 inicialização antecipada.

Desempenho

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

Cenários	Hora de início	Hora de término	Limite Superior
Avalie o driver crítico de inicialização carregada antes de permitir que ele seja inicializado. Isso também inclui status atualizar retornos de chamada.	O kernel chama de volta para o driver antimalware para avaliar o driver crítico de inicialização carregado.	O driver antimalware retorna o resultado da avaliação.	0,5 ms
Avaliar todos os drivers críticos de inicialização carregados	O kernel chama de volta para o driver antimalware para avaliar o primeiro driver crítico de inicialização carregado.	O driver antimalware retorna o resultado da avaliação do último driver crítico de inicialização.	50 ms
Volume (driver + dados de configuração na memória)	N/D	N/D	128kB

Inicializando drivers

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 por meio de Política de Grupo em um cliente ingressado no 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 depois que a pilha de disco for iniciada, haverá um despejo de memória e ela conterá algumas informações sobre o motivo ou a falha, para incluir informações sobre drivers ausentes. Isso pode ser usado no WinRE para determinar a causa da falha e tentar corrigir.

ELAM e inicialização medida

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 indicavam que o sistema estava em um bom estado. A função retornará um erro se houver um problema com a inicialização medida, por exemplo, nenhum TPM no sistema.

Tbsi_Revoke_Attestation pode ser chamado no modo kernel. Ele estende PCR[12] por 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 é dividida em todas aspas 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 resto do tempo em que o TPM estiver ligado e os sistemas remotos não poderão formar confiança no estado de segurança do sistema.

Partilhar via