Compartilhar via


Protocolo EFI de ambiente de execução confiável

Licenciamento: a Microsoft concorda em conceder a você uma licença sem custo e sem royalties para suas Declarações Necessárias em termos razoáveis e não discriminatórios apenas para fazer, usar, vender, oferecer para venda, importar ou distribuir qualquer implementação dessa especificação. "Declarações Necessárias" são aquelas declarações de patentes controladas pela Microsoft ou controladas pela Microsoft que são tecnicamente necessárias para implementar as partes necessárias (que também incluem os elementos necessários de partes opcionais) dessa especificação, em que a funcionalidade que causa a infração é descrita em detalhes e não apenas referenciada nesta Especificação.

1.0 Introdução

Este documento especifica um protocolo EFI para interagir com um TrEE (Ambiente de Execução Confiável), implementando a funcionalidade TPM 2.0 de acordo com um subconjunto de uma especificação de biblioteca do TCG (Trusted Computing Group) Trusted Platform Module 2.0. Este documento também especifica os requisitos de medida de firmware da plataforma. O protocolo EFI definido aqui aproveita até um grande grau [TCG06a] e [TCG06b].

2.0 Estruturas de dados e acrônimos

2.1 Estruturas de dados

Como em [TCG06a], todos os valores de dados DEVEM ser representados no formato Little-Endian. Cadeias de caracteres DEVEM ser representadas como uma matriz de bytes ASCII com o caractere mais à esquerda colocado no local de memória mais baixo.

2.2 Acrônimos e Convenções

(Para acrônimos não definidos aqui, consulte [TCG06a])

Ambiente de execução TrEETrusted

O uso dos termos "MUST" e "SHALL" neste documento deve ser interpretado de acordo com [RFC2119].

3.0 Protocolo EFI TrEE

Esta seção fornece uma descrição detalhada do EFI_TREE_PROTOCOL e do EFI_TREE_SERVICE_BINDING_PROTOCOL. O Protocolo TrEE de EFI é usado para se comunicar com um TrEE.

3.1 Protocolo de Associação de Serviço de EFI tree

Esta seção define o protocolo de associação de serviço EFI tree.

Resumo – O Protocolo de Associação de Serviço tree da EFI é usado para localizar dispositivos TrEE compatíveis com um driver de Protocolo TrEE EFI e para criar e destruir instâncias de driver filho do protocolo TrEE EFI que podem usar o dispositivo TrEE subjacente.

GUID - #define EFI_TREE_SERVICE_BINDING_PROTOCOL_GUID \ {0x4cf01d0a, 0xc48c, 0x4271, 0xa2, 0x2a, 0xad, 0x8e, 0x55, 0x97,\ 0x81, 0x88}

DescriçãoUm aplicativo (ou driver) que requer serviços TrEE pode usar um dos serviços de manipulador de protocolo, como BS-LocateHandleBuffer>(), para pesquisar dispositivos que publicam um Protocolo de Associação de Serviço trEE EFI. Cada dispositivo com um protocolo de associação de serviço TrEE publicado dá suporte ao Protocolo TrEE de EFI e pode estar disponível para uso.

Após uma chamada bem-sucedida para o EFI_TREE_SERVICE_BINDING_PROTOCOL. Função CreateChild(), a instância filho do driver do Protocolo EFI TrEE está pronta para uso.

Antes que um aplicativo ou driver EFI encerre a execução, todas as chamadas bem-sucedidas para o EFI_TREE_SERVICE_BINDING_PROTOCOL. A função CreateChild() deve ser correspondida com uma chamada para o EFI_TREE_SERVICE_BINDING_PROTOCOL. Função DestroyChild().

3.2 Protocolo EFI tree

Resumo – O protocolo EFI TrEE é usado para se comunicar com um TrEE – para enviar comandos a um TrEE, usá-lo para operações de execução confiáveis e para fornecer acesso ao log de firmware de medidas estendidas no TrEE. O protocolo mantém um Log de Eventos de medidas registrado no TrEE com um formato idêntico ao TCG 1.2 TCG Event Log (consulte [TCG06b]); chamado de TCG 1.2 Event Log de Formato de Log de Eventos trEE nessa especificação. Os implementadores podem criar logs de eventos adicionais com outros formatos, mas essa versão do protocolo não define uma maneira de recuperá-los.

GUID - #define EFI_TREE_PROTOCOL_GUID \ {0x607f766c, 0x7455, 0x42be, 0x93, 0x0b, 0xe4, 0xd7, 0x6d, 0xb2,\ 0x72, 0x0f}

Estrutura da interface do protocolo -

typedef struct _EFI_TREE_PROTOCOL {
  EFI_TREE_GET_CAPABILITYGetCapability;
  EFI_TREE_GET_EVENT_LOGGetEventLog;
  EFI_TREE_HASH_LOG_EXTEND_EVENTHashLogExtendEvent;
  EFI_TREE_SUBMIT_COMMANDSubmitCommand;
} EFI_TREE_PROTOCOL;

Parâmetros

GetCapability

Esse serviço fornece informações sobre as funcionalidades tree e firmware

GetEventLog

Obter um ponteiro para um log de eventos de firmware

HashLogExtendEvent

Esse serviço fará com que o driver EFI TrEE estenda um evento e (opcionalmente) escreva o evento no log tree.

SubmitCommand

Esse serviço envia um comando diretamente para o TrEE.

Descrição – o EFI_TREE_PROTOCOL abstrai a atividade tree. Essa instância de protocolo fornece um Serviço de Inicialização e é instanciada como um Driver de Serviço de Inicialização.

Os Drivers de Serviço de Inicialização são encerrados quando ExitBootServices ( ) é chamado e todos os recursos de memória consumidos pelos Drivers dos Serviços de Inicialização são liberados para uso no ambiente do sistema operacional.

Esse Serviço de Inicialização deve criar um evento EVT_SIGNAL_EXIT_BOOT_SERVICES. Esse evento será notificado pelo sistema quando ExitBootServices ( ) for invocado.

EVT_SIGNAL_EXIT_BOOT_SERVICES é um evento síncrono usado para garantir que determinadas atividades ocorram após uma chamada para uma função de interface específica; nesse caso, essa é a limpeza que precisa ser feita em resposta à função ExitBootServices ( ). ExitBootServices ( ) não pode limpo em nome de drivers que foram carregados no sistema. Os drivers precisam fazer isso por conta própria criando um evento cujo tipo é EVT_SIGNAL_EXIT_BOOT_SERVICES e cuja função de notificação é uma função dentro do próprio driver. Em seguida, quando ExitBootServices ( ) tiver concluído sua limpeza, ele sinalizará o tipo de evento EVT_SIGNAL_EXIT_BOOT_SERVICES.

Para obter detalhes de implementação sobre como um Serviço de Inicialização instanciado como um Driver de EFI cria esse evento de EVT_SIGNAL_EXIT_BOOT_SERVICES necessário, consulte Seção 6.1 de [UEFI12].

3.3 EFI_TREE_PROTOCOL. GetCapability

A chamada de função GetCapability EFI_TREE_PROTOCOL fornece informações de capacidade de protocolo e informações de estado sobre o TrEE.

Protótipo

typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_CAPABILITY) (
  IN EFI_TREE_PROTOCOL      *This,
  IN OUT TREE_BOOT_SERVICE_CAPABILITY*ProtocolCapability,
);

Parâmetros

Este

Indica o contexto de chamada.

ProtocolCapability

O chamador aloca memória para uma estrutura TREE_BOOT_SERVICE_CAPABILITY e define o campo de tamanho para o tamanho da estrutura alocada. O receptor preenche os campos com as informações de funcionalidade do protocolo EFI e as informações de estado tree atuais até o número de campos que se ajustam ao tamanho da estrutura passada.

Definições relacionadas

typedef struct _TREE_VERSION { 
  UINT8 Major; 
  UINT8 Minor; 
} TREE_VERSION;
typedef UINT64 EFI_PHYSICAL_ADDRESS;
typedef UINT32 TREE_EVENT_LOG_BITMAP;
typedef UINT32 TREE_EVENT_LOG_FORMAT;
#define TREE_EVENT_LOG_FORMAT_TCG_1_2 0x00000001
typedef struct _TREE_BOOT_SERVICE_CAPABILITY { 
  UINT8 Size;
  TREE_VERSION StructureVersion; 
  TREE_VERSION ProtocolVersion;
  UINT32 HashAlgorithmBitmap;
  TREE_EVENT_LOG_BITMAPSupportedEventLogs;
  BOOLEAN TrEEPresentFlag;
  UINT16MaxCommandSize;
  UINT16MaxResponseSize;
  UINT32ManufacturerID;  
} TREE_BOOT_SERVICE_CAPABILITY;

#define TREE_BOOT_HASH_ALG_SHA1       0x00000001
#define TREE_BOOT_HASH_ALG_SHA256     0x00000002
#define TREE_BOOT_HASH_ALG_SHA384     0x00000004
#define TREE_BOOT_HASH_ALG_SHA512     0x00000008

Tamanho

Tamanho alocado da estrutura passada

StructureVersion

Versão da própria estrutura TREE_BOOT_SERVICE_CAPABILITY. Para esta versão do protocolo, a versão Principal será definida como 1 e a versão Secundária será definida como 0.

ProtocolVersion

Versão do protocolo TrEE. Para esta versão do protocolo, a versão Principal será definida como 1 e a versão Secundária será definida como 0.

HashAlgorithmBitMap

Algoritmos de hash com suporte

SupportedEventLogs

Bitmap de formatos de log de eventos com suporte (veja acima)

TrEEPresentFlag

False = TrEE não presente

MaxCommandSize

Tamanho máximo (em bytes) de um comando que pode ser enviado para o TrEE

MaxResponseSize

Tamanho máximo (em bytes) de uma resposta que pode ser fornecida pelo TrEE

ManufacturerID

ID do fornecedor de 4 bytes (consulte [TCG07], seção "ID do fornecedor de funcionalidades do TPM")

Descrição

A chamada de função Obter Funcionalidade do EFI_TREE_PROTOCOL fornece informações de versão e funcionalidade do protocolo EFI, bem como informações de estado sobre o TrEE. O chamador deve definir o campo Tamanho da estrutura de TREE_BOOT_SERVICE_CAPABILITY alocada. Espera-se que versões futuras dessa chamada de função possam adicionar campos adicionais à estrutura. O valor Tamanho passado permitirá que a função preencha apenas os campos para os qual o chamador aloca memória alocada. Por exemplo:

ProtocolCapability.Size = sizeof(TREE_BOOT_SERVICE_CAPABILITY);

Para esta versão da especificação:

  1. Se os parâmetros This ou ProtocolCapability forem NULL, a chamada funcional retornará EFI_INVALID_PARAMETER.

  2. Se a entrada ProtocolCapability.Size < sizeof(TREE_BOOT_SERVICE_CAPABILITY) a função definirá ProtocolCapability.Size igual a sizeof(TREE_BOOT_SERVICE_CAPABILITY) conforme definido nesta especificação e retornará o código de erro EFI_BUFFER_TOO_SMALL, os valores dos campos restantes serão indefinidos.

  3. Os seguintes valores retornados DEVEM ser definidos:

    ProtocolCapability.StructureVersion.Major = 1

    ProtocolCapability.StructureVersion.Minor = 0

    ProtocolCapability.ProtocolVersion.Major = 1

    ProtocolCapability.ProtocolVersion.Minor = 0

  4. Se a plataforma não tiver um TrEE, os seguintes valores deverão ser retornados:

    ProtocolCapability.SupportedEventLogs = 0

    ProtocolCapability.HashAlgorithmBitmap = 0

    ProtocolCapability.TrEEPresentFlag = FALSE

    ProtocolCapability.MaxCommandSize = 0

    ProtocolCapability.MaxResponseSize = 0

    ProtocolCapability.ManufacturerID = 0

  5. MaxCommandSize e MaxResponseSize devem ser 0x500 (ou superiores) para Windows.

Códigos de status retornados

EFI_SUCCESS

Operação concluída com sucesso.

EFI_DEVICE_ERROR

O comando não teve êxito. A variável ProtocolCapability não será preenchida.

EFI_INVALID_PARAMETER

Um ou mais dos parâmetros estão incorretos. A variável ProtocolCapability não será preenchida.

EFI_BUFFER_TOO_SMALL

A variável ProtocolCapability é muito pequena para conter a resposta completa. Ele será parcialmente preenchido (o campo Tamanho necessário será definido).

3.4 EFI_TREE_PROTOCOL. GetEventLog

A chamada da função Obter Log de Eventos EFI_TREE_PROTOCOL permite que um chamador recupere o endereço de um determinado log de eventos e sua última entrada.

Protótipo

typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_EVENT_LOG) (
  IN  EFI_TREE_PROTOCOL      *This,
  IN  TREE_EVENT_LOG_FORMATEventLogFormat,
  OUT EFI_PHYSICAL_ADDRESS*EventLogLocation,
  OUT EFI_PHYSICAL_ADDRESS*EventLogLastEntry,
  OUT BOOLEAN*EventLogTruncated
);

Parâmetros

EventLogFormat

O tipo do log de eventos para o qual as informações são solicitadas.

EventLogLocation

Um ponteiro para o endereço de memória do log de eventos.

EventLogLastEntry

Se o Log de Eventos contiver mais de uma entrada, esse será um ponteiro para o endereço do início da última entrada no log de eventos na memória. Para obter informações sobre quais valores são retornados nesse parâmetro nos casos especiais de um Log de Eventos vazio ou um Log de Eventos com apenas uma entrada, consulte a seção Descrição abaixo.

EventLogTruncated

Se o Log de Eventos estiver faltando pelo menos uma entrada porque um evento teria excedido a área alocada para eventos, esse valor será definido como TRUE. Caso contrário, o valor será FALSE e o Log de Eventos será concluído.

Descrição

O firmware gerencia um Log de Eventos das medidas registradas no TrEE durante o processo de inicialização. Durante o processo de inicialização, antes da inicialização da plataforma UEFI, uma entrada é feita no Log de Eventos para cada medida estendida no TrEE. No ambiente UEFI, sempre que uma chamada é feita para HashLogExtendEvent para estender uma medida no TrEE, um evento geralmente é registrado no Log de Eventos que contém a medida estendida. Se a área alocada por firmware para o Log de Eventos for muito pequena para manter todos os eventos adicionados, a chamada de função indicará que o Log de Eventos foi truncado e tem entradas ausentes. Esta versão da especificação requer apenas que um Log de Eventos de medidas SHA1 seja mantido. Versões futuras dessa especificação podem manter logs de eventos adicionais que dão suporte a diferentes algoritmos de hash.

A área log de eventos retornada por essa função é lançada quando ExitBootServices ( ) é chamado. Os chamadores desse método não DEVEM acessar a área depois que ExitBootServices ( ) tiver sido chamado. Para esta versão da especificação:

  1. Se EventLogFormat não for igual a TREE_EVENT_LOG_FORMAT_TCG_1_2, a chamada de função DEVERÁ retornar EFI_INVALID_PARAMETER.

  2. Se nenhum TrEE estiver presente, a função DEVERÁ definir os seguintes valores e retornar EFI_SUCCESS:

    1. EventLogLocation = NULL

    2. EventLogLastEntry = NULL

    3. EventLogTruncated = FALSE

  3. O valor EventLogLocation DEVE ser definido como o início do formato de log de eventos especificado na memória

  4. Se o log de eventos especificado:

    1. não contém nenhum evento e EventLogLastEntry DEVE ser definido como 0

    2. contém exatamente uma entrada e EventLogLastEntry DEVE ser definida com o mesmo valor que EventLogLocation

    3. contém mais de um evento e EventLogLastEntry DEVE ser definido como o endereço inicial do último evento do Log de Eventos especificado

  5. Se uma chamada anterior para EFI_TREE_PROTOCOL. HashLogExtendEvent retornou EFI_VOLUME_FULL, em seguida, EventLogTruncated DEVE ser definido como TRUE, caso contrário, deve ser definido como FALSE.

Códigos de status retornados

EFI_SUCCESS

Operação concluída com sucesso.

EFI_INVALID_PARAMETER

Um ou mais dos parâmetros estão incorretos (por exemplo, solicitar um log de eventos cujo formato não tem suporte).

3,5 EFI_TREE_PROTOCOL. HashLogExtendEvent

A chamada de função HashLogExtendEvent EFI_TREE_PROTOCOL oferece aos chamadores uma oportunidade de estender e, opcionalmente, registrar eventos sem exigir conhecimento dos comandos TPM reais. A operação de extensão ocorrerá mesmo se essa função não puder criar uma entrada de log de eventos (por exemplo, devido ao log de eventos estar cheio).

Protótipo

typedef
EFI_STATUS
(EFIAPI * EFI_TREE_HASH_LOG_EXTEND_EVENT) (
  IN EFI_TREE_PROTOCOL*This,
  IN UINT64Flags,
  IN EFI_PHYSICAL_ADDRESSDataToHash,
  IN UINT64DataToHashLen,
  IN TrEE_EVENT*Event,
);

Parâmetros

Este

Indica o contexto de chamada.

Sinalizadores

Bitmap fornecendo informações adicionais (veja abaixo).

DataToHash

Endereço físico do início do buffer de dados a ser

Hash.

DataToHashLen

O comprimento em bytes do buffer referenciado por DataToHash.

Evento

Ponteiro para o buffer de dados que contém informações sobre o evento.

Definições relacionadas

#pragma pack(1)
typedef struct _TrEE_EVENT {
  UINT32Size;            
  TrEE_EVENT_HEADERHeader;
  UINT8Event[ANYSIZE_ARRAY];
} TrEE_EVENT;
typedef struct _TrEE_EVENT_HEADER {
  UINT32HeaderSize;
  UINT16HeaderVersion;
  TrEE_PCRINDEXPCRIndex;
  TrEE_EVENTTYPEEventType;
} TrEE_EVENT_HEADER;
#pragma pack()
typedef UINT32 TrEE_PCRINDEX;
typedef UINT32 TrEE_EVENTTYPE;

Tamanho

Tamanho total do evento, incluindo o componente Tamanho, o cabeçalho e os dados de Evento .

HeaderSize

Tamanho do cabeçalho do evento em si (sizeof(TrEE_EVENT_HEADER)).

HeaderVersion

Versão do cabeçalho. Para esta versão dessa especificação, o valor será 1.

PCRIndex

Índice do PCR que deve ser estendido (0 a 23).

EventType

Tipo do evento que deve ser estendido (e, opcionalmente, registrado).

Valores de sinalizador

A variável Flags é um bitmap que fornece dados adicionais da seguinte maneira:

#define TREE_EXTEND_ONLY 0x0000000000000001

Esse bit deve ser definido quando um evento deve ser estendido, mas não registrado.

#define PE_COFF_IMAGE 0x0000000000000010

Esse bit deve ser definido quando a intenção é medir uma imagem PE/COFF.

Descrição

A chamada da função evento EFI_TREE_PROTOCOL Hash Log Extend calcula a medida de um buffer de dados (possivelmente contendo uma imagem binária PE/COFF) e faz com que o driver TrEE estenda a medida. Além disso, o serviço opcionalmente cria uma entrada de log de eventos e a acrescenta ao Log de Eventos para cada formato de log de eventos com suporte do serviço. O serviço permite que um chamador use o TrEE sem saber nada sobre comandos TrEE específicos.

O uso dessa função para medir imagens PE/COFF deve ser feito antes que as realocações sejam aplicadas à imagem. Observação: tenha cuidado ao usar esse método para medir imagens PE/COFF. Geralmente, as implementações que carregam imagens PE/COFF removem dados importantes durante o processo de carregamento da imagem e podem alterar o alinhamento da seção de imagem na memória. O resultado líquido é calcular o hash de uma imagem na memória não corresponde à medida real da imagem, conforme calculado corretamente quando ela é carregada da mídia de armazenamento.

Após a invocação, a função deverá executar as seguintes ações:

  1. Se qualquer um dos parâmetros This, DataToHash ou Event for NULL, a função DEVERÁ retornar EFI_INVALID_PARAMETER.

  2. Se Event.Size for menor que Event.Header.HeaderSize + sizeof(UINT32), a função DEVERÁ retornar EFI_INVALID_PARAMETER.

  3. Se Event.Header.PCRIndex não for de 0 a 23, inclusive, a função DEVERÁ retornar EFI_INVALID_PARAMETER.

  4. Se o bitmap Flags tiver a PE_COFF_IMAGE bit SET, mas a imagem PE/COFF estiver corrompida ou não entender, a função DEVERÁ retornar EFI_UNSUPPORTED.

  5. A função permite qualquer valor para o parâmetro Event.Header.EventType.

  6. A função DEVE calcular o resumo (medida) dos dados começando em DataToHash com um comprimento de DataToHashLen. Quando o bit PE_COFF_IMAGE é definido, a função DEVE calcular a medida da imagem PE/COFF de acordo com "Medindo uma imagem PE/COFF" no Apêndice A abaixo.

  7. A função DEVE enviar com êxito o comando TPM2_PCR_Extend para o TrEE para estender o PCR indicado por Event.Header.PCRIndex com o resumo da medida. Se o comando não puder ser enviado com êxito, a função deverá retornar EFI_DEVICE_ERROR. Se o firmware der suporte a mais algoritmos do que SHA1, ele poderá calcular resumos usando outros algoritmos e estendê-los também.

  8. Se uma chamada anterior para essa função retornasse EFI_VOLUME_FULL e o bit TREE_EXTEND_ONLY for definido no parâmetro Flags, a função DEVERÁ retornar EFI_VOLUME_FULL. (Nenhuma tentativa é feita para adicionar a entrada de log de eventos aos logs de eventos).)

  9. A função DEVE criar uma entrada de Log de Eventos TCG da seguinte maneira: (Observação: a estrutura TCG_PCR_EVENT é definida em [TCG06b] e deve ser considerada alinhada a bytes.)

    1. TCG_PCR_EVENT. PCRIndex = Event.Header.PCRIndex

    2. TCG_PCR_EVENT. EventType = Event.Header.EventType

    3. TCG_PCR_EVENT. Digest = <o resumo da medida SHA1 calculado acima>

    4. TCG_PCR_EVENT. EventSize = Event.Size - sizeof(UINT32) - Event.Header.HeaderSize

    5. TCG_PCR_EVENT. Event = Event.Event (Observação: esta é uma cópia de memória de EventSize bytes)

  10. A função PODE criar entradas de log de eventos semelhantes para outros formatos de Log de Eventos com suporte.

  11. Se a entrada TCG_PCR_EVENT Log de Eventos criada acima não se ajustar à área alocada para o Log de Eventos TCG 1.2 do Formato de Log de Eventos do TrEE, a função DEVERÁ retornar EFI_VOLUME_FULL.

  12. Se o firmware der suporte a formatos adicionais do Log de Eventos e qualquer um dos eventos criados para esses logs de eventos exceder a área alocada para o Log de Eventos, a função DEVERÁ retornar EFI_VOLUME_FULL.

  13. A função DEVE acrescentar os eventos criados aos logs de eventos correspondentes e o serviço DEVE atualizar seu ponteiro interno para o início do último evento para cada Log de Eventos.

Códigos de status retornados.

EFI_SUCCESS

Operação concluída com sucesso.

EFI_DEVICE_ERROR

O comando não teve êxito.

EFI_VOLUME_FULL

A operação de extensão ocorreu, mas o evento não pôde ser gravado em um ou mais logs de eventos.

EFI_INVALID_PARAMETER

Um ou mais dos parâmetros estão incorretos.

EFI_UNSUPPORTED

Não há suporte para o tipo de imagem PE/COFF.

3,6 EFI_TREE_PROTOCOL. SubmitCommand

Esse serviço permite o envio de comandos para o TrEE.

Protótipo

typedef
EFI_STATUS
(EFIAPI *EFI_TREE_SUBMIT_COMMAND) (
  IN EFI_TREE_PROTOCOL*This,
  IN UINT32InputParameterBlockSize,
  IN UINT8*InputParameterBlock,
  IN UINT32OutputParameterBlockSize,
  IN UINT8*OutputParameterBlock 
);

Parâmetros

Este

Indica o contexto de chamada.

InputParameterBlockSize

Tamanho do bloco de parâmetros de entrada TrEE.

InputParameterBlock

Ponteiro para o bloco de parâmetros de entrada TrEE.

OutputParameterBlockSize

Tamanho do bloco de parâmetros de saída TrEE.

OutputParameterBlock

Ponteiro para o bloco de parâmetros de saída TrEE.

Descrição

A chamada de função Enviar Comando EFI_TREE_PROTOCOL fornece uma funcionalidade de passagem do chamador para o TrEE do sistema.

O chamador é responsável por criar o fluxo de bytes de comando a ser enviado para o TrEE e também é responsável por interpretar o fluxo de bytes resultante retornado pelo TrEE. Os operandos de entrada e saída do TrEE para cada comando TrEE são definidos em outro lugar.

Observe que os códigos de status retornados refletem o resultado da invocação da função e não o êxito (ou falha) do comando TrEE subjacente.

O TPM 2.0 não DEVE retornar TPM2_RC_RETRY antes da conclusão da chamada para ExitBootServices(). (O motivo para esse requisito é que o código de retorno bloquearia o processo de inicialização até que o comando TPM pudesse ser compeleted.)

O TPM 2.0 DEVE ter acesso ao armazenamento persistente antes da conclusão da chamada para ExitBootServices. Se a implementação do TPM 2.0 pode não ter acesso ao armazenamento persistente após a chamada para ExitBootServices, entre em contato com a Microsoft para obter requisitos adicionais.

Códigos de status retornados

EFI_SUCCESS

O fluxo de bytes de comando foi enviado com êxito para o dispositivo e uma resposta foi recebida com êxito.

EFI_DEVICE_ERROR

O comando não foi enviado com êxito para o dispositivo ou uma resposta não foi recebida com êxito do dispositivo.

EFI_INVALID_PARAMETER

Um ou mais dos parâmetros estão incorretos.

EFI_BUFFER_TOO_SMALL

O bloco de parâmetro de saída é muito pequeno.

Referências

[MSFT08]

Microsoft Corporation, "Windows Authenticode Portable Executable Signature Format", versão 1.0, 21 de março de 2008.

[RFC2119]

Bradner, S., "Palavras-chave para uso em RFCs para indicar níveis de requisito", IETF RFC 2119, março de 1997.

[TCG06a]

Grupo de Computação Confiável, "Protocolo TCG EFI", versão 1.20 Revisão 1.00, 9 de junho de 2006.

[TCG06b]

Trusted Computing Group, "TCG EFI Platform Specification", versão 1.20 Revisão 1.0, 7 de junho de 2006.

[TCG07]

Grupo de Computação Confiável, "Registro de ID do Fornecedor TCG", Versão 1.0, Revisão 0.1, 31 de agosto de 2007.

[UEFI12]

UEFI, "Unified Extensible Firmware Interface Specification", versão 2.3.1 Errata C,

Junho de 2012.

Apêndice A: Raiz Estática das Medidas de Confiança

Importante

Apêndice Uma implementação de medidas PCR[7] é obrigatória para sistemas InstantGo.

Em um alto nível, o firmware é responsável por medir os seguintes componentes durante a inicialização:

  • Firmware de plataforma que contém ou mede os Serviços de Inicialização da UEFI e os Serviços de Runtime da UEFI

  • Variáveis relevantes de segurança associadas ao firmware de plataforma

  • Drivers UEFI ou aplicativos de inicialização carregados separadamente

  • Variáveis associadas a drivers UEFI carregados separadamente ou aplicativos de inicialização UEFI

As medidas acima são definidas pela especificação TCG EFI Platform [TCG06b] Seções 5.1 - 5.5 e não são referenciadas aqui. As medidas em PCR[1] e PCR[3] são opcionais dependendo da configuração da plataforma.

Para Windows, PCR[7] é usado para refletir a política de Inicialização Segura UEFI 2.3.1. Essa política depende do firmware que autentica todos os componentes de inicialização iniciados antes do ambiente UEFI e do código de inicialização da plataforma UEFI (ou código de firmware anterior) gravando invariavelmente as informações da política de Inicialização Segura no PCR[7].

O firmware de plataforma que está aderindo à política deve, portanto, medir os seguintes valores em PCR[7]:

  1. O conteúdo da variável PK

  2. O conteúdo da variável KEK

  3. O conteúdo da variável EFI_IMAGE_SECURITY_DATABASE

  4. O conteúdo da variável EFI_IMAGE_SECURITY_DATABASE1

  5. Entradas no EFI_IMAGE_SECURITY_DATABASE que são usadas para validar drivers EFI ou aplicativos de inicialização EFI no caminho de inicialização

  6. O conteúdo da variável SecureBoot

Devido às variáveis DE UEFI PK, KEK, EFI_IMAGE_SECURITY_DATABASE, EFI_IMAGE_SECURITY_DATABASE1 e SecureBoot NÃO devem ser medidas em PCR[3].

Além disso, se a plataforma fornecer um depurador de firmware que pode ser iniciado antes do ambiente UEFI, ele deverá registrar esse fato no PCR[7]. Da mesma forma, se a plataforma fornecer um depurador para o ambiente UEFI, a inicialização do depurador DEVERÁ ser registrada no PCR[7].

Nota de implementação

A função UEFI LoadImage DEVE registrar medidas em PCR[2] ou PCR[4] por eventos descritos em [TCG06b] e também PCR[7] por eventos descritos na seção "Medindo a configuração da UEFI em PCR[7]" abaixo. Para determinar se uma medida de imagem se aplica a PCR[2] ou PCR[4], LoadImage DEVE examinar o campo Subsistema na imagem PE/COFF. Os valores IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER, IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER e IMAGE_SUBSYSTEM_EFI_ROM correspondem a PCR[2]. O valor IMAGE_SUBSYSTEM_EFI_APPLICATION corresponde a PCR[4]. Se a imagem carregada for de algum outro tipo, ela deverá ser registrada em PCR[4]. Imagens que LoadImage não carrega devido a (a) falha de verificação de assinatura ou (b) porque a imagem não está em conformidade com a política de Inicialização Segura uefi 2.3.1 atualmente imposta não precisam ser medidas em um PCR.

Definições relacionadas

#define EV_EFI_VARIABLE_DRIVER_CONFIG \
                                  0x80000001 /* Defined in [TCG06b] */
#define EV_EFI_ACTION             0x80000007 /* Defined in [TCG06b] */
#define EV_EFI_VARIABLE_AUTHORITY 0x800000E0

This specification requires a modified TCG structure definition for EFI_VARIABLE_DATA.  The revised structure is:
typedef struct {
  EFI_GUIDVariableName;
  UINT64        UnicodeNameLength;    // The TCG Defintion used UINTN
  UINT64        VariableDataLength;   // The TCG Defintion used UINTN
  CHAR16       UnicodeName[1];
  INT8         VariableData[1];   
} EFI_VARIABLE_DATA;

Medindo uma imagem PE/COFF

Ao medir uma imagem PE/COFF, o EventType deve ser definido em [TCG06b] (por exemplo, ao medir um aplicativo de inicialização EFI, o EventType deve ser EV_EFI_BOOT_SERVICES_APPLICATION) e o valor event deve ser o valor da estrutura EFI_IMAGE_LOAD_EVENT definida em [TCG06b].

O serviço HashLogExtendEvent DEVE hash da imagem PE/COFF de acordo com o procedimento especificado na seção "Calculando o hash de imagem PE" de [MSFT08].

Medindo a configuração da UEFI em PCR[7]

Para todos os eventos de valor de variável EFI, o EventType deve ser EV_EFI_VARIABLE_DRIVER_CONFIG definido acima e o valor event deve ser o valor da estrutura de EFI_VARIABLE_DATA definida acima nessa especificação (essa estrutura deve ser considerada alinhada por bytes). O resumo da medida deve ser o hash SHA-1 dos dados do evento, que é a estrutura EFI_VARIABLE_DATA. (Observação: esse é um resumo diferente do especificado por [TCG06b].) O EFI_VARIABLE_DATA. O valor UnicodeNameLength é o número de caracteres CHAR16 (não o número de bytes). O EFI_VARIABLE_DATA. O conteúdo UnicodeName NÃO DEVE incluir um terminador nulo. Se a leitura da variável EFI retornar EFI_NOT_FOUND, o EFI_VARIABLE_DATA. O campo VariableDataLength DEVE ser definido como zero e EFI_VARIABLE_DATA. O campo VariableData terá um tamanho igual a zero.

  1. Se a plataforma fornecer um modo de depurador de firmware que pode ser usado antes do ambiente UEFI ou se a plataforma fornecer um depurador para o ambiente UEFI, a plataforma DEVERÁ estender um evento EV_EFI_ACTION conforme especificado em [TCG06b] para PCR[7] antes de permitir o uso do depurador. A cadeia de caracteres de evento deve ser "Modo de Depuração UEFI". Além disso, a plataforma DEVE criar uma entrada de Log de Eventos TCG da seguinte maneira:

    1. TCG_PCR_EVENT. PCRIndex = 7

    2. TCG_PCR_EVENT. EventType = EV_EFI_ACTION

    3. TCG_PCR_EVENT. Digest = <o resumo SHA-1 do valor da cadeia de caracteres "Modo de Depuração UEFI" sem o caractere NULL de terminação>

    4. TCG_PCR_EVENT. EventSize = strlen("UEFI Debug Mode")

    5. TCG_PCR_EVENT. Evento = "Modo de Depuração UEFI"

    A plataforma PODE criar entradas de log de eventos semelhantes para outros formatos de Log de Eventos com suporte.

  2. Antes de executar qualquer código não autenticado criptograficamente como sendo fornecido pelo Fabricante da Plataforma, o firmware Fabricante da Plataforma DEVE medir os seguintes valores na ordem listada usando o tipo de evento EV_EFI_VARIABLE_DRIVER_CONFIG para PCR[7]:

    1. Valor da variável SecureBoot

    2. O valor da variável PK

    3. O valor da variável KEK

    4. O valor da variável EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE

    5. O valor da variável EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1

  3. Se a plataforma der suporte à alteração de qualquer uma das seguintes variáveis de política uefi depois que elas forem inicialmente medidas em PCR[7] e antes de ExitBootServices ( ) ter sido concluída sem reiniciar incondicionalmente a plataforma, ela deverá medir a variável novamente imediatamente após a alteração. Além disso, o processo de atualização normal para definir qualquer uma das variáveis UEFI abaixo DEVE ocorrer antes da medição inicial no PCR[7] ou após a conclusão da chamada para ExitBootServices().

    1. Valor da variável SecureBoot

    2. O valor da variável PK

    3. O valor da variável KEK

    4. O valor da variável EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE

    5. O valor da variável EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1

  4. O sistema DEVE medir o evento EV_SEPARATOR no PCR[7]. (Isso ocorre ao mesmo tempo em que o separador é medido para PCR[0] por meio de PCR[7].)

  5. Antes de iniciar um Driver EFI ou um aplicativo de inicialização EFI (e independentemente de a inicialização ser devido ao Gerenciador de Inicialização do EFI escolher uma imagem das variáveis UEFI DriverOrder ou BootOrder ou uma imagem já iniciada chamando a função UEFI LoadImage(), o firmware UEFI deve medir a entrada na variável EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE que foi usada para validar a imagem EFI no PCR[7]. A medida DEVE ocorrer em conjunto com a carga da imagem. Para esse evento, EventType deve ser EV_EFI_VARIABLE_AUTHORITY e o valor event deve ser o valor da estrutura EFI_VARIABLE_DATA (a estrutura é definida acima nessa especificação com uma definição diferente da especificação TCG). O EFI_VARIABLE_DATA. O valor VariableData deve ser o valor EFI_SIGNATURE_DATA do EFI_SIGNATURE_LIST que continha a autoridade usada para validar a imagem e o EFI_VARIABLE_DATA. VariableName deve ser definido como EFI_IMAGE_SECURITY_DATABASE_GUID. O EFI_VARIABLE_DATA. UnicodeName deve ser definido como o valor de EFI_IMAGE_SECURITY_DATABASE. O valor não deve incluir o caractere NULL de terminação.

  6. Antes de iniciar drivers EFI adicionais ou aplicativos de inicialização EFI, o firmware UEFI deverá marcar se a entrada na variável EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE que valida a imagem EFI foi medida anteriormente com o tipo de evento EV_EFI_VARIABLE_AUTHORITY em PCR[7]. Se não tiver sido, ele deverá ser medido conforme descrito na etapa anterior. Se tiver sido medido anteriormente, ele NÃO DEVERÁ ser medido novamente.

Observação

Um exemplo de medida para medidas PCR[7] está disponível mediante solicitação da Microsoft.