Perfil ACPI do ambiente de execução confiável

Artigo
06/20/2023

Licenciamento: a Microsoft concorda em conceder a você uma licença sem custos e livre de royalties para suas Declarações Necessárias em termos razoáveis e não discriminatórios apenas para fazer, usar, vender, oferecer à venda, importar ou distribuir qualquer implementação dessa especificação. "Declarações necessárias" são as declarações de patentes controladas pela Microsoft ou 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 violação é descrita em detalhes e não apenas referenciada nesta Especificação.

1.0 Tela de fundo

Essa especificação define o objeto de dispositivo ACPI para um dispositivo TPM 2.0 e os métodos de controle associados ao objeto de dispositivo ACPI necessário para Windows 8. Os métodos de controle implementam o equivalente à interface ACPI de presença física TCG, o equivalente à interface de Mitigação de Ataque de Redefinição de Plataforma e, opcionalmente, um método ACPI para enviar um comando para o dispositivo TPM 2.0.

Uma tabela ACPI estática adicional (TPM2) é usada para definir o mecanismo de comunicação entre o dispositivo TPM 2.0 e o sistema operacional Windows 8.

Observação

A Microsoft refere-se ao "TPM" do Grupo de Computação Confiável. Próximo" termo como "TPM 2.0"

2.0 Requisitos

Essa especificação pressupõe uma plataforma de computação que dá suporte à comunicação baseada em ACPI, conforme especificado em [ACPI09] entre um sistema operacional e um ambiente de firmware.

3.0 Cenários de uso (por exemplo, somente)

3.1 Enviar um comando de presença física

Um cenário de uso típico é o seguinte:

No ambiente do sistema operacional, um aplicativo detecta que o dispositivo TPM 2.0 não está totalmente provisionado para uso para Windows 8. (Um exemplo de como isso pode acontecer é se uma nova imagem do sistema operacional for instalada depois que uma imagem anterior do sistema operacional provisionou o TPM 2.0.)
O aplicativo inicia um assistente de sistema operacional para preparar o dispositivo TPM 2.0 para uso.
O assistente interage com o administrador do computador por meio da interface do usuário e determina que o administrador precisa limpar o dispositivo TPM 2.0 para provisioná-lo porque o valor de autorização de bloqueio de redefinição de dispositivo do TPM 2.0 não está disponível.
Para limpar o dispositivo TPM 2.0, o sistema operacional solicita (executando um método de controle ACPI para o objeto de dispositivo TPM 2.0) o firmware executa a operação para limpar o dispositivo TPM 2.0 na próxima inicialização, desde que um usuário fisicamente presente confirme que aprova a limpeza do dispositivo TPM 2.0.
O sistema operacional reinicia a plataforma.
Durante a parte inicial do processo de inicialização, o firmware reconhece a solicitação pendente do sistema operacional para limpar o dispositivo TPM 2.0.
O firmware apresenta uma interface do usuário a um usuário fisicamente presente solicitando que ele execute alguma ação para confirmar a limpeza do dispositivo TPM 2.0.
Um usuário fisicamente presente confirma a limpeza do dispositivo TPM 2.0.
O firmware limpa o dispositivo TPM 2.0 usando a autorização de hierarquia de plataforma.
Se necessário, para persistir a limpeza do dispositivo TPM 2.0, a plataforma será reinicializada imediatamente.
O sistema operacional é inicializado.
As consultas do sistema operacional (por meio de um método de controle ACPI no dispositivo TPM 2.0) se a última solicitação do sistema operacional para limpar o dispositivo TPM 2.0 foi (a) bem-sucedida, (b) não foi confirmada pelo usuário fisicamente presente ou (c) teve algum outro erro. A seguir, presumimos que o dispositivo TPM 2.0 foi limpo com êxito.
O assistente de provisionamento de dispositivos TPM 2.0 no sistema operacional executa comandos adicionais para preparar o dispositivo para uso pelo Windows.

3.2 Solicitando que a memória seja limpa na próxima inicialização

Esse cenário ilustra como o recurso de limpeza de memória do sistema ajuda a impedir ataques que coletam memória do sistema para material de chave depois que a plataforma é reiniciada inesperadamente.

De dentro do sistema operacional, um administrador em um sistema com um dispositivo TPM 2.0 ativa o recurso BitLocker para o volume do sistema operacional.
O recurso BitLocker chama o método de controle ACPI do dispositivo TPM 2.0 para definir o bit ClearMemory definido na Especificação de Mitigação de Ataque de Redefinição de Plataforma TCG.
O recurso BitLocker criptografa o volume do sistema operacional.
O administrador deixa o sistema autônomo com a tela bloqueada.
Uma pessoa mal-intencionada rouba o sistema enquanto ele está em execução.
A pessoa mal-intencionada insere um pen drive e remove rapidamente a bateria do sistema e a reinsere.
O sistema inicia a inicialização quando a bateria é reinserida.
Como o bit ClearMemory foi definido anteriormente, o firmware limpa toda a memória do sistema antes de iniciar qualquer código não fornecido pelo fabricante da plataforma.
A pessoa mal-intencionada configura o firmware durante a inicialização para inicializar no dispositivo USB, mesmo que o código no dispositivo USB não esteja assinado corretamente.
O código no dispositivo USB verifica a memória do sistema para a Chave Mestra de Volume do BitLocker, mas não é encontrado.

Aviso

As etapas 11 a 16 são semelhantes às etapas anteriores, mas usam a interface UEFI em vez de ACPI
A pessoa mal-intencionada tenta inicializar o sistema normalmente.
Como o BitLocker foi habilitado com o protetor de chave do TPM, isso permite que o BootMgr "desmarque" o volume master chave para o volume do sistema operacional porque as medidas corretas estão no dispositivo TPM 2.0 quando o BootMgr é executado.
A inicialização prossegue para a tela de logon do sistema operacional.
A pessoa mal-intencionada remove novamente e reinsere a bateria e inicializa o código de um dispositivo USB.
Como o bit ClearMemory foi definido, o firmware do sistema apaga toda a memória do sistema durante a inicialização.
Embora o código do dispositivo USB examine a memória do sistema, a chave de criptografia de volume do sistema operacional não está na memória.

3.3 Emitir um comando para o dispositivo TPM 2.0

Este exemplo não é aplicável a todas as arquiteturas do sistema.

O driver do TPM 2.0 do Windows deseja emitir um comando para o dispositivo TPM 2.0.
O driver TPM 2.0 do Windows grava o comando a ser executado no endereço físico lido da Área de Controle definida pelo ACPI anteriormente durante a inicialização do driver TPM 2.0 do Windows.
O driver TPM 2.0 do Windows executa o método de controle ACPI para executar um comando TPM 2.0.
O driver do TPM 2.0 do Windows sonda os registros na área de controle até que indiquem que o comando TPM foi concluído.
O driver TPM do Windows lê a resposta de comando do endereço físico lido da Área de Controle definida pela ACPI anteriormente durante a inicialização do driver TPM do Windows.

4.0 Requisitos gerais de ACPI para o sistema e o dispositivo TPM 2.0

4.1 Considerações sobre energia

ACPI D1/D2

O dispositivo TPM 2.0 PODE dar suporte a ACPI D1 e/ou ACPI D2, mas DEVE se comportar como se estivesse no estado de energia ACPI D0 enquanto estava em D1 ou D2.

ACPI S3 (Suspensão)

O TPM 2.0 PODE dar suporte a S3, mas a entrada e saída do estado de baixa energia S3 para o dispositivo DEVE ser controlada pelo fabricante do sistema/plataforma.

O sistema operacional (ou outro software em execução no ambiente do sistema operacional) NÃO DEVE ser capaz de colocar o dispositivo TPM 2.0 no S3 ou fazer com que o dispositivo TPM 2.0 saia do S3. Por exemplo, se o dispositivo TPM 2.0 estiver em um barramento, o sistema operacional NÃO DEVERÁ ser capaz de desligar o barramento fazendo com que o dispositivo TPM 2.0 insira S3.

O driver Windows 8 TPM tentará emitir um comando TPM2_Shutdown antes de entrar no S3 (suspensão).

Se uma plataforma de hardware der suporte a S3 e o TPM não mantiver seu estado enquanto o sistema estiver no S3, a plataforma deverá emitir os comandos necessários TPM2_Init e TPM2_Startup(TPM_SU_STATE) durante a retomada do S3. É possível que o sistema operacional não tenha concluído o comando TPM2_Shutdown antes da entrada no S3. Isso pode fazer com que o resultado de retorno de TPM2_Startup(TPM_SU_STATE) retorne um erro. O firmware do sistema que é retomado do S3 DEVE lidar com um erro de TPM2_Startup adequadamente. Por exemplo, desabilitando o acesso ao TPM por meio de hardware, emitindo um comando TPM2_Startup(TPM_SU_CLEAR) e configurando o dispositivo com segurança executando ações como estender um separador com um resumo de erro (0x01) para PCRs 0 a 7 e bloquear índices NV.

O sistema DEVE considerar o tempo decorrido durante o S3 diminuindo a contagem de falhas de ataque do dicionário TPM (TPM_PT_LOCKOUT_COUNTER) durante o tempo em que o sistema estava em S3 de acordo com o intervalo de bloqueio (TPM_PT_LOCKOUT_INTERVAL). Isso pode exigir que uma implementação de plataforma forneça tensão de espera para reter o relógio TPM e/ou o estado durante o S3 ou uma plataforma também pode fornecer informações com segurança sobre quanto tempo passou enquanto o sistema estava em um estado de baixa energia para que o TPM possa atualizar de forma confiável sua contagem de falhas de autorização para sua lógica de ataque de dicionário.

Estados de baixa energia para sistemas em espera conectados

Windows 8 não executa nenhuma ação adicional associada ao TPM após a entrada e saída dos estados de baixa energia para sistemas de espera conectados. A plataforma DEVE executar todas as ações necessárias para que o TPM se comporte como se estivesse em D0 sempre que o sistema entra e sai dos estados de baixa energia para sistemas de espera conectados. Isso pode exigir uma implementação de plataforma para fornecer tensão de espera para ligar o relógio TPM e/ou manter o estado. Como alternativa, uma plataforma pode precisar fornecer informações com segurança sobre quanto tempo passou enquanto o sistema estava em um estado de baixa energia para o TPM, para que o TPM possa atualizar de forma confiável sua contagem de falhas de autorização para sua lógica de ataque de dicionário.

Sistema desativado

O sistema DEVE considerar com segurança o tempo decorrido durante o desligamento completo, diminuindo a contagem de falhas de ataque do dicionário TPM (TPM_PT_LOCKOUT_COUNTER) durante o tempo em que o sistema estava em S5 de acordo com o intervalo de bloqueio (TPM_PT_LOCKOUT_INTERVAL).

4.2 Tabelas ACPI

Um sistema com um dispositivo TPM 2.0 DEVE fornecer uma tabela de objetos de dispositivo com uma ID de dispositivo de hardware e uma tabela estática específica do fornecedor do sistema operacional (TPM2), conforme descrito abaixo.

A tabela TPM2 e o objeto de dispositivo TPM 2.0 DEVEM ser persistentes quando a plataforma é enviada para um cliente. (Por exemplo, as opções de firmware NÃO DEVEM permitir a ocultação da tabela TPM2 ou do objeto de dispositivo TPM 2.0.) Uma exceção será se um sistema for fornecido com uma opção não padrão para fornecer funcionalidade do TPM 1.2 em vez da funcionalidade do TPM 2.0 (ou seja, para compatibilidade com sistemas operacionais mais antigos, como o Windows 7.) Nessa situação, a tabela TPM2 e o objeto de dispositivo TPM 2.0 PODEM ser removidos por meio de uma opção de configuração do BIOS e da enumeração de um TPM 1.2 executada. Observação: um sistema de espera conectado para Windows 8 é necessário para enviar, por padrão, um TPM 2.0 visível para o sistema operacional. Entre em contato com a Microsoft para obter diretrizes técnicas sobre como alternar entre um TPM 2.0 e o TPM 1.2 em uma plataforma de hardware.

4.3 Tabela ACPI do objeto de dispositivo TPM 2.0

4.3.1 Hierarquia de Barramento

A tabela Objeto do Dispositivo DEVE estar na tabela DSDT no namespace ACPI. O objeto de dispositivo TPM 2.0 DEVE estar localizado no barramento do sistema em "root\_SB".

4.3.2 Identificador de hardware

O identificador de hardware de plug and play real (por exemplo, _HID) para o objeto de dispositivo TPM 2.0 DEVE ser "MSFT0101" ou o dispositivo DEVE ter uma ID compatível de "MSFT0101" e o _HID pode ser específico do fornecedor.

4.3.3 Descritores de recursos

O objeto de dispositivo ACPI TPM 2.0 DEVE reivindicar todos os recursos usados pelo dispositivo TPM 2.0.

Métodos de controle 4.3.4

4.3.4.1 Mitigação de ataque de redefinição de plataforma

O sistema DEVE implementar todas as partes relacionadas a ACPI e UEFI de [TCG08] para UEFI. O objeto de dispositivo DEVE implementar a interface do método de controle definida em [TCG08], seção 6. A interface é necessária mesmo que a plataforma limpe incondicionalmente a memória em cada inicialização. A limpeza da memória NÃO DEVE ser condicional no estado do dispositivo TPM 2.0 (em contraste [TCG08] não exigirá limpeza de memória se o TPM 1.2 não for de propriedade). Além disso, as seções 3, 5 de [TCG08] DEVEM ser implementadas. A função de consulta _DSM DEVE ser implementada (índice de função 0) de acordo com a especificação acpi. (Observação: há um erro na especificação ACPI 4.0 sobre o valor retornado do método _DSM. O valor retornado do método _DSM deve ser um buffer que contém 0x03.) A implementação DEVE detectar automaticamente um desligamento ordenado do sistema operacional e limpar o bit ClearMemory nesses eventos.

Observação especial para sistemas Arm baseados em UEFI com um TPM 2.0: em sistemas Arm baseados em UEFI com um TPM 2.0, Windows 8 solicitará incondicionalmente que a memória seja limpa usando a interface UEFI em cada inicialização. A implementação da interface ACPI ainda é necessária, mas a interface PODE ser implementada para não alterar o estado dos sinalizadores ClearMemory ou DisableAutoDetect. (Observação: a Microsoft recomenda que a interface ACPI seja implementada de acordo com a especificação TCG para que chamar a interface ACPI altere o estado de ClearMemory ou DisableAutoDetect.)

4.3.4.2 Interface de presença física

O sistema DEVE implementar a especificação definida em [TCG11] de acordo com as observações adicionais abaixo:

O uso do TPM na especificação TCG deve ser equivalente ao dispositivo TPM 2.0.
Os métodos de controle definidos na seção 2 DEVEM ser implementados com as seguintes restrições:
1. A função de consulta _DSM DEVE ser implementada (índice de função 0) de acordo com a especificação acpi. (Observação: há um erro na especificação ACPI 4.0 sobre o valor retornado do método _DSM. O valor retornado do método _DSM deve ser um buffer que contém 0x01FF.)
2. A implementação DEVE retornar um valor de "2: Reinicializar" para "Obter Platform-Specific Ação para Fazer a Transição para o Ambiente do Pré-SISTEMA". As operações de PPI DEVEM ocorrer para uma transição de uma reinicialização e DEVE ocorrer para uma transição de desligamento.
3. A implementação dos seguintes métodos de controle é opcional: "Enviar solicitação de operação do TPM para o ambiente do pré-sistema operacional" (pode retornar "2: falha geral") e "Enviar idioma de usuário preferencial" (pode retornar "3: Não implementado").

Os requisitos na seção 3 DEVEM ser implementados com as seguintes revisões:

O BIOS não precisa fornecer armazenamento persistente para o sinalizador NoPPIProvision porque as operações autorizadas por ele não são relevantes para o estado do dispositivo TPM 2.0.

A Tabela 2 é revisada da seguinte maneira:

Tabela 1: tabela PPI revisada 2

OperationValue	Nome da operação	Estatística do TPM	Sinalizadores de gerenciamento do TPM do BIOS	Obrigatório versus opcional	Quando a confirmação de presença física é necessária	Pode precisar de um ciclo de inicialização adicional
0	Nenhuma operação			M
1-4	Nenhuma operação			M
5	TPM2_ClearControl(NÃO) + TPM2_Clear	X		M	NoPPIClear é FALSE	X
6-11	Nenhuma operação			M
12-13	Nenhuma operação			O
14	TPM2_ClearControl(NÃO) + TPM2_Clear	X		M	NoPPIClear é FALSE	X
15-16	Nenhuma operação			M
17	SetNoPPIClear_False		X	O1
18	SetNoPPIClear_True		X	O1	Sempre
19-20	Nenhuma operação			O2
21-22	TPM2_ClearControl(NÃO) + TPM2_Clear	X		M	NoPPIClear é FALSE	X
23 - 127	Reservado
>=128	Específico do fornecedor	X	X	O		X

Importante

Por SetNoPPIClear_False: se o BIOS implementar os itens marcados como "O1" ou "O2", ele deverá implementá-los como um conjunto. Para a Operação Sem que se segue SetNoPPIClear_True, o BIOS não deverá implementar as operações 19 e 20 se não implementar a operação 12.

A Tabela 3 é revisada da seguinte maneira:

Operação Valor	Operação Nome	Comandos do TPM enviados pelo BIOS e outras ações do BIOS para executar a operação
0	Nenhuma operação	Nenhuma operação
1-4, 6-13, 15-16, 19-20	Nenhuma operação	Sem operação. No entanto, o número da operação DEVE ser lembrado e o resultado, se consultado do sistema operacional, deverá retornar êxito.
5, 14, 21, 22	Limpar	TPM2_ClearControl(NÃO) + TPM2_Clear <PLATFORM RESET>* [*Se necessário para persistir as alterações do TPM de TPM2_CLEAR. A Microsoft prevê que, na maioria dos sistemas, isso é desnecessário.]
17	SetNoPPIClear_False (Exigir presença física para limpar.)	Essa operação não altera o estado do TPM. Limpa o Sinalizador de Gerenciamento do TPM do BIOS NoPPIClear como FALSE.
18	SetNoPPIClear_True (Não exigir confirmação de presença física para limpar.)	Essa operação não altera o estado do TPM. Define o Sinalizador de Gerenciamento do TPM do BIOS NoPPIClear como TRUE.
23 - 127	Reservado	Reservado, não implemente nem use
>=128	Específico do fornecedor	Mapeamento de comandos do TPM para a operação específica do fornecedor

O espírito da seção 4 DEVE ser mantido para obter a confirmação de um usuário fisicamente presente quando for necessário executar uma operação, mas o mecanismo real não precisa ser pressionamentos de tecla. As chaves ou outro mecanismo para afirmar o consentimento cabem ao fabricante da plataforma.

Valor

Operação

Nome

Confirmação

Texto

5, 14, 21 e 22

Limpar

Foi solicitada uma alteração de configuração para limpar o TPM (Trusted Platform Module) deste computador

AVISO: limpar apaga as informações armazenadas no TPM. Você perderá todas as chaves criadas e o acesso aos dados criptografados por essas chaves.

Pressione <CAK> para limpar o TPM

Pressione <RK> para rejeitar essa solicitação de alteração e continuar

SetNoPPIClear_True

Foi solicitada uma alteração de configuração para permitir que o Sistema Operacional limpasse o TPM (Trusted Platform Module) do computador sem solicitar a confirmação do usuário no futuro.

OBSERVAÇÃO: essa ação não limpa o TPM, mas ao aprovar essa alteração de configuração, as ações futuras para limpar o TPM não exigirão a confirmação do usuário.

AVISO: limpar apaga as informações armazenadas no TPM. Você perderá todas as chaves criadas e o acesso aos dados criptografados por essas chaves.

Pressione <CAK> para aprovar solicitações futuras do sistema operacional para limpar o TPM

Pressione <RK> para rejeitar essa solicitação de alteração e continuar

A seção 5 é informativa.
Sistemas de espera conectados PODEM codificar noPPIClear como TRUE e não implementar as operações 17 e 18. Isso significa que eles não precisam implementar nenhuma caixa de diálogo de confirmação para ações de presença física porque nenhuma operação de presença física exigirá a confirmação do usuário.
O firmware DEVE deixar as hierarquias de armazenamento e endosso habilitadas quando passar o controle para o código inicial do carregador do programa, como o Gerenciador de Inicialização do Windows.

4.3.4.3 Método de início de ACPI opcional

Observação: algumas plataformas podem implementar esse método ACPI opcional para permitir que o sistema operacional solicite que o firmware execute ou cancele um comando TPM 2.0. O uso do método ACPI Start é determinado pelo campo StartMethod da tabela ACPI estática (consulte a Seção 4.4.) Se o campo StartMethod da tabela ACPI estática indicar o uso desse método, o método ACPI Start deverá ser implementado. As funções ACPI definidas aqui devem residir no objeto do método de controle _DSM. [Observação: este não é um método de controle na tabela ACPI TPM2.] O método _DSM definido aqui no DEVE ser implementado da seguinte maneira:

UUID

Revisão

Função

Descrição

6bbf6cab-5463-4714-b7cd-f0203c0368d4

Conforme descrito em [ACPI09], Seção 9.14.1.

Iniciar

Início da função

Argumentos de entrada:

Arg0 (Buffer): UUID = 6bbf6cab-5463-4714-b7cd-f0203c0368d4
Arg1 (Integer): Revision ID = 0
Arg2 (Integer): Function Index = 1
Arg3 (Package): Arguments = Empty Package

Valor retornado:

Tipo: inteiro

Descrição do valor retornado:

0: Êxito

1: Falha geral

Comportamento funcional:

Essa função instrui o sistema a examinar os registros de status na área de controle de dispositivo do TPM 2.0 e tomar a ação apropriada para executar ou cancelar o comando TPM 2.0.

A função não está bloqueando. A chamada retornará imediatamente. (Não tente executar a execução de comando de dentro do método ACPI. As chamadas AML precisam ser curtas.) Quando o Valor retornado 0 for retornado, o comando enviado foi aceito e será executado pelo firmware ou cancelado se o campo Cancelar já estiver definido. Sempre que possível, o sistema deve retornar uma resposta TPM em vez de uma falha geral dessa chamada. Por exemplo, um comando não pode ser processado agora, um buffer de resposta de TPM2_RC_RETRY pode ser gravado e o campo START pode ser CLEARed. Se o comando tiver sido cancelado porque o campo Cancelar foi definido, esse método poderá gravar uma TPM2_RC_Cancelled código de retorno no buffer de resposta, limpar o campo Iniciar e retornar um valor igual a 0. Como alternativa, se o campo Cancelar for definido, o método poderá retornar um valor igual a 0 e o dispositivo TPM 2.0 poderá ser concluído posteriormente ou cancelar o comando de acordo com os requisitos para cancelar um comando.

Quando o Valor retornado 1 é retornado, o firmware não pode ler ou agir após a solicitação. Além do valor retornado, a solicitação é equivalente a um NO-OP. Exemplos são (a) um driver de sistema operacional inválido solicita a execução de comandos adicionais antes de um comando anterior ser concluído, (b) a área de controle não está na memória física [talvez devido à corrupção de memória], ou (c) os endereços físicos de comando ou resposta não existem. Um valor retornado de 1 pode fazer com que o driver TPM 2.0 do Windows possa parar de usar o dispositivo TPM 2.0 até a próxima inicialização completa do sistema (isso exclui ciclos de hibernação/retomada).

Observação: depois que a execução do comando for iniciada, esse método não será chamado uma segunda vez se o sistema operacional escolher cancelar o comando em execução no momento. (No entanto, é possível que o método de controle possa ser chamado inicialmente para um comando enquanto o campo de cancelamento está definido.)

4.4 Tabela ACPI Estática TPM2

Uma tabela ACPI chamada "TPM2" listada na tabela ACPI "RSDT" descreve a interface de hardware TPM 2.0 da plataforma. O driver do Windows TPM 2.0 usa essa tabela para determinar a maneira como ele se comunica com o dispositivo TPM 2.0. Os parâmetros na tabela ACPI necessários para dar suporte a essa interface são ilustrados na tabela abaixo.

Tabela 3: Layout da tabela ACPI TPM2

Campo

Comprimento do byte

Deslocamento de byte

Descrição

Cabeçalho

Assinatura

00h

'TPM2'. Assinatura para a tabela de interface de hardware do dispositivo TPM 2.0

Comprimento

04h

O comprimento da tabela, em bytes, incluindo o cabeçalho, começando do deslocamento 0. Esse campo é usado para registrar o tamanho de toda a tabela.

Revisão

08h

Revisão desta tabela, incluindo os dados e a estrutura referenciados por ela. Se alguma estrutura referenciada por essa alteração (por exemplo, Área de Controle), essa revisão DEVERÁ ser alterada. Valor 03h.

Checksum (soma de verificação)

09h

A tabela inteira, incluindo o campo soma de verificação, DEVE adicionar a zero para ser considerada válida.

OEM ID

0Ah

ID do OEM por especificação de ACPI. Uma cadeia de caracteres fornecida pelo OEM que identifica o OEM (esse pode ser o fornecedor do chipset).

ID da Tabela OEM

10h

A ID da Tabela OEM é a ID do modelo do fabricante (atribuída pelo OEM identificado por "ID do OEM"; pode ser o fornecedor do chipset).

Revisão do OEM

18h

Revisão de OEM para a ID da Tabela OEM fornecida. Por ACPI, "[an] Número de revisão fornecido pelo OEM. Supõe-se que números maiores sejam revisões mais recentes."

ID do Criador

1Ch

ID do fornecedor do utilitário que criou a tabela. Para as tabelas que contêm Blocos de Definição, essa é a ID do Compilador ASL.

Revisão do Criador

20h

Revisão do utilitário que criou a tabela. Para as tabelas que contêm Blocos de Definição, esta é a revisão do Compilador ASL.

Flags

24h

Reservado

DEVE ser sempre zero

Endereço da área de controle

28h

Endereço físico da Área de Controle. Pode estar na memória do dispositivo TPM 2.0 ou na memória reservada pelo sistema durante a inicialização. O driver TPM 2.0 mantém o conhecimento desse endereço durante um ciclo de inicialização, incluindo hibernação e ciclos de retomada. Se o sistema não usar a Área de Controle, esse valor DEVERÁ ser todos zeros.

Método Start

30h

O seletor de método start determina qual mecanismo o driver TPM 2.0 do Windows usa para comunicar comandos TPM 2.0 ao dispositivo e notificar o dispositivo TPM 2.0 de que um comando está disponível para processamento. Esse campo pode conter um dos seguintes valores:

Valor	Descrição
0	Reservado.
1	Reservado (específico do fornecedor)
2	Usa o método AcPI Start.
3-5 6	Reservado (específico do fornecedor) Reservado para a Interface de E/S mapeada para memória (TIS 1.2+Cancelar). Essa opção não está Windows 8 em conformidade com a Certificação de Hardware. O uso dessa opção requer uma solicitação de contingência Windows 8 WHLK aprovada para certificação de logotipo. Entre em contato com a Microsoft para obter detalhes.
7 8	Usa a interface do buffer de resposta de comando. Usa a Interface do Buffer de Resposta de Comando com o método AcPI Start.
…	Reservado.

Parâmetros específicos da plataforma

variável

34h

O conteúdo dos parâmetros específicos da plataforma é determinado pelo mecanismo de início usado pela interface do dispositivo TPM 2.0 desse sistema. Esse campo contém valores que podem ser usados para iniciar o processamento de comandos. Essas informações podem ser específicas do fornecedor. Para os valores do Método Start de 2 ou 6, o campo não é usado e o Comprimento do Byte é zero.

4.4.1 Conteúdo da área de controle

A estrutura Área de Controle contém status campos, bem como outros bits/campos de controle e um ou mais endereços. A Área de Controle contém o endereço físico do buffer de comando e o endereço físico do buffer de resposta.

Nem todas as implementações de interface do TPM 2.0 usam a Área de Controle, por exemplo, um valor do Método Start de 6 não usa a Área de Controle e as informações nesta seção não são aplicáveis à plataforma.

A área de controle DEVE estar na memória AddressRangeReserved da ACPI.

A estrutura Área de Controle é mostrada na tabela abaixo e, a menos que especificado, caso contrário, todos os acessos à área de controle são feitos no formato little endian.

Tabela 4: Layout da área de controle

Campo	Comprimento do byte	Deslocamento	Descrição
Campos de status			Campos de status do TPM 2.0
Reservado	4	00h	Reservado. (DEVE ser zero.)
Erro	4	04h	SET pelo TPM 2.0 para indicar uma condição de erro
Cancelar	4	08h	SET pelo DRIVER para anular o processamento de comando
Iniciar	4	0Ch	SET pelo DRIVER para indicar que um comando está disponível para processamento.
Controle de interrupção	8	10h	Reservado. (DEVE ser zero.)
Tamanho do comando	4	18h	Tamanho do buffer de comando
Comando	8	1Ch	Esse campo contém o endereço físico do buffer de comando. Observe que o buffer de comando real (não o endereço físico do buffer de comando) está no formato big-endian conforme exigido pelo TCG.
Tamanho da resposta	4	24h	Tamanho do buffer de resposta
Resposta	8	28h	Esse campo contém o endereço físico do buffer de resposta. Observe que o buffer de resposta real (não o endereço físico do buffer de resposta) está no formato big-endian conforme exigido pelo TCG.

O driver TPM 2.0 lê as seguintes informações uma vez durante a inicialização do sistema operacional:

O endereço físico da área de controle
O tamanho do buffer de comando
O local físico do buffer de comando
O tamanho do buffer de resposta
O local físico do buffer de resposta

Para sistemas que usam a área de controle (ou seja, o valor do Método Start não é igual a 6) e dão suporte à hibernação e à retomada, os cinco valores acima DEVEM permanecer constantes nos ciclos de hibernação e retomada.

Erro 4.4.1.1

O dispositivo TPM 2.0 pode DEFINIR esse status. Ele só pode gravar esse status quando Iniciar for SET. Imediatamente após o dispositivo TPM 2.0 SETs esse status, ele CLEARs o valor Iniciar. O driver do Windows TPM 2.0 não lerá o campo Erro, a menos que o campo Iniciar seja CLEAR.

Um valor SET do campo Erro é tratado como um erro genérico do dispositivo TPM 2.0 ou de sua interface de hardware. Qualquer valor SET resulta no cancelamento do comando atual. O comando DEVE ser revertido, portanto, o dispositivo TPM 2.0 é deixado em um estado consistente.

Para um dispositivo com um método INICIAR ACPI, esse campo só deve ser usado para erros para os quais um código de resposta não pode ser fornecido. Um exemplo é: o buffer de resposta não está na memória física. O driver do TPM 2.0 do Windows pode parar de usar o dispositivo TPM 2.0 quando esse campo for SET.

O valor inicial desse campo após ExitBootServices DEVE refletir se o dispositivo funciona ou não.

4.4.1.2 Cancelar

O driver do Windows TPM 2.0 pode DEFINIR esse campo para solicitar que o processamento do dispositivo TPM 2.0 do comando atual seja encerrado. O driver do Windows TPM 2.0 não invoca o método Start para iniciar o processamento da solicitação de cancelamento.

Quando Cancel for SET pelo driver do Windows TPM 2.0 e o dispositivo TPM 2.0 estiver processando um comando, o dispositivo TPM 2.0 deixará de processar o comando atual no ponto conveniente mais cedo. Para a maioria dos comandos, espera-se que o dispositivo TPM 2.0 conclua o comando e forneça uma resposta normal. Para comandos de execução prolongada (por exemplo, geração de chave RSA), o dispositivo TPM 2.0 pode sair com TPM_RC_CANCELLED. O dispositivo TPM 2.0 precisa concluir ou cancelar o comando dentro de 90 segundos. (Geralmente, a maioria dos comandos TPM 2.0 deve ser concluída em menos de 500 ms, exceto comandos de geração de chave RSA que podem levar mais tempo e o cancelamento de comando deve ocorrer dentro de 200 ms)

O driver TPM 2.0 do Windows pode limpar esse valor quando o campo Iniciar for CLEAR. O valor inicial desse campo após ExitBootServices DEVE ser CLEAR.

4.4.1.3 Iniciar

O driver TPM 2.0 do Windows pode DEFINIR esse status para indicar que um novo comando foi colocado no buffer de comando. O driver do TPM 2.0 do Windows pode invocar o método Start para iniciar o processamento do comando. O dispositivo TPM 2.0 limpará esse status quando concluir o processamento de um comando.

O driver do Windows TPM 2.0 pode limpar esse status quando falha na invocação do método Start.

O valor inicial desse campo após ExitBootServices DEVE ser CLEAR.

Comando 4.4.1.4

Esse é o endereço físico no qual o driver do Windows TPM 2.0 gravará o comando a ser executado. O driver do Windows TPM 2.0 nunca gravará um comando maior que "Tamanho do Comando".

O driver do Windows TPM 2.0 não deve gravar nessa área de memória, a menos que o campo Iniciar seja CLEAR. Observe que o endereço é especificado no formato little-endian na área de controle, mas o buffer de comando real está no formato big-endian, conforme exigido pelo TCG.

4.4.1.5 Resposta

Esse é o endereço físico do qual o driver do Windows TPM 2.0 lerá respostas de comando. O driver do Windows TPM 2.0 nunca lerá uma resposta maior que "Tamanho da Resposta".

O driver do Windows TPM 2.0 lerá apenas uma resposta depois que o campo Iniciar for alterado de SET para CLEAR e Error for CLEAR. Observe que o endereço é especificado no formato little-endian na área de controle, mas o buffer de resposta real está no formato big-endian, conforme exigido pelo TCG.

4.5 Definição da interface da área de controle

Para plataformas de hardware que usam a Área de Controle como a interface TPM 2.0, esta seção e as informações na seção 4.4 descrevem a interação do driver TPM 2.0 com o hardware. Um exemplo de um sistema que usa a Área de Controle é um sistema com um valor de Método Start igual a 2 na tabela TPM2.

4.5.1 Combinações de Estado

A Tabela 5 descreve o comportamento esperado para alterações feitas pelo driver TPM 2.0 do Windows. Observe que apenas algumas combinações são permitidas. Somente as combinações e alterações permitidas são documentadas. Todas as outras combinações são inválidas. Alterações de campo sem ação pelo driver do Windows TPM 2.0 significa que o dispositivo TPM 2.0 ou o método ACPI Start alteraram os campos.

Estados marcados com '0' indicam que esse campo é CLEAR. Estados marcados com '1' indicam que esse campo é SET. Estados marcados com '?' indicam que o valor desse campo pode ser CLEAR ou SET. Os campos status são abreviados com: 'ERR' - Error, 'CCL' - Cancel e 'STR' - Start. Um campo pode ser gravado pelo driver do Windows TPM 2.0 ou pela interface do dispositivo TPM 2.0, que é detalhada na coluna de ação.

	\|---	Estado Presente	---\|	\|---	Campo Gravado	---\|	\|---	Próximo Estado	---\|	Ação executada pela interface do dispositivo TPM 2.0
#	ERR	CCL	STR	ERR	CCL	STR	ERR	CCL	STR
1	0	1	0	-	0	-	0	0	0	O driver do Windows TPM 2.0 CLEARs o valor Cancelar para preparar a Área de Controle para o próximo comando. O driver do Windows TPM 2.0 pode LIMPAR o valor Cancelar somente quando START for CLEAR. (O dispositivo TPM 2.0 NÃO DEVE gravar no campo Cancelar.)
2	0	0	0	-	-	1	0	0	1	O driver do Windows TPM 2.0 SETs o valor Iniciar para indicar que um comando está presente na área Comando. O driver TPM 2.0 do Windows pode chamar o método ACPI Start para iniciar a execução do comando. Após a conclusão do método ACPI Start, o dispositivo TPM 2.0 DEVE concluir comandos e LIMPAR o campo Iniciar dentro de 90 segundos. Exceder o limite de tempo pode fazer com que o driver TPM 2.0 do Windows assuma que o dispositivo TPM 2.0 está travado.
3	0	?	1	-	-	0	0	?	0	O dispositivo TPM 2.0 CLEARs o campo Iniciar quando ele termina de processar o comando ou cancela o comando. Se o comando tiver sido cancelado, uma resposta com código de retorno TPM_RC_CANCELLED será colocada no buffer de resposta e Iniciar será CLEARed. O driver do Windows TPM 2.0 pode ler o buffer de resposta enquanto o campo Iniciar é CLEAR. O driver do Windows TPM 2.0 NÃO DEVE ler o buffer de resposta enquanto o campo Iniciar é SET.
4	0	0	1	-	1	-	0	1	1	O driver do Windows TPM 2.0 SETs Cancela para indicar o dispositivo TPM 2.0 para cancelar o comando atual. Geralmente, comandos de execução longa devem ser cancelados no próximo ponto conveniente. Comandos de execução curta podem ser concluídos. Especificamente, o dispositivo TPM 2.0 deve limpar o campo Iniciar dentro de 90 segundos após o campo Cancelar ser SET. (Uma boa meta de desempenho é 200ms em vez de 90 segundos.) Observação: é possível que o campo Cancelar possa ser definido quando o método INICIAR ACPI for chamado porque um thread dentro do sistema operacional pode DEFINIR o campo Cancelar antes que outro thread invoque o Método Iniciar acpi.
5	0	?	1	1	-	-	1	?	1	O dispositivo TPM 2.0 indica uma condição de erro no dispositivo. O estado do dispositivo TPM 2.0 é como se a execução do comando nunca tivesse sido iniciada. O driver do Windows TPM 2.0 trata esse valor como uma falha genérica do dispositivo TPM 2.0 e cancela o processamento do comando.
6	1	?	1	-	-	0	1	?	0	O dispositivo TPM 2.0 CLEARs o campo Iniciar imediatamente após SETting do campo Erro. O driver do Windows TPM 2.0 só inspeciona o campo Erro quando o campo Iniciar é CLEAR ou se a execução ou cancelamento de comando não ocorre dentro da janela de tempo necessária. O driver TPM 2.0 do Windows pode parar de usar o dispositivo TPM 2.0 quando o campo Erro for SET.

4.5.2 Diagrama de estado ao usar o método ACPI Start

Esse diagrama de estado é somente para fins informativos. A descrição normativa do comportamento é o texto nas seções anteriores. Se houver transições de estado ausentes ou ambíguas, consulte o texto acima.

estados do dispositivo tpm 2.0 ao usar o método acpi start

Figura 1: estados do dispositivo TPM 2.0 ao usar o método ACPI Start

Observação

(a) Observe que vários threads simultâneos podem interagir com a Área de Controle simultaneamente. Por exemplo: um thread pode iniciar um comando definindo o campo Iniciar e, em seguida, emitindo o método Start. Outro thread pode definir o campo Cancelar em paralelo. Portanto, a possibilidade de definir o campo Cancelar depois de definir o campo Iniciar, mas antes de emitir o método Start. (b) Um driver do Windows TPM 2.0 pode reagir a condições de erro de forma diferente da ilustrada. Ele pode, por exemplo, fazer a transição para um estado de erro quando um tempo limite atingir.

4.5.3 Diagrama de estado sem um método INICIAR ACPI

estados do dispositivo tpm 2.0 sem o método acpi start

Figura 2: estados do dispositivo TPM 2.0 sem o método INICIAR ACPI

4.6 Interface de E/S mapeada de memória

Para plataformas de hardware que usam a Interface de E/S Mapeada para Memória, esta seção e as informações na seção 4.4 descrevem a interação do driver TPM 2.0 com o hardware. Um exemplo de um sistema que usa a interface de E/S mapeada de memória é um sistema com um valor método Start de 6 na tabela TPM2.

4.6.1 Requisitos de especificação de interface TPM TCG

O sistema DEVE estar em conformidade com os requisitos de interface de hardware do TPM 1.2 no [TCG12] para as seguintes seções:

Seção 9.1: Níveis de localidade do TPM

Seção 9.2: Usos de localidade

Seção 9.3: Uso de localidade por registro

Seção 10: Espaço de Registro do TPM

Seção 11: Interação e fluxos do sistema

Exceto: Todos os modos de falha da seção 11.2.4

Exceto a seção 11.2.5: Duração do comando, item normativo 2

Exceto a seção Todos da seção 11.2.6: Tempos limite

Exceto a seção All of 11.2.8: Self Test and Early Platform Initialization

Exceto a seção 11.2.9: Tamanho do buffer de entrada

Exceto a seção 11.2.10: Erros, itens normativos 2c e 3.

Seção 13: Protocolo de Hardware do TPM

Para especificações de rascunho futuras do [TCG12], entre em contato com a Microsoft.

4.6.2 Suporte para cancelar um comando

O Windows exige que o dispositivo TPM 2.0 permita o cancelamento de um comando TPM 2.0 usando a interface de E/S mapeada de memória exibindo o comportamento descrito abaixo.

O bit 24 não utilizado anteriormente do Registro sts é definido apenas como gravação e chamado de commandCancel.

Uma gravação de '1' no commandCancel durante a fase de execução do comando PODE cancelar o comando em execução no momento e uma resposta DEVE ser retornada. A resposta indica se o comando foi cancelado (nenhuma alteração de estado do TPM 2.0, mas um código de resposta de cancelamento TPM_RC_CANCELLED é retornado) ou concluído (uma resposta TPM 2.0 regular é retornada indicando o resultado do comando). Grava no registro commandCancel quando o TPM não está no estado de execução do comando DEVE ser ignorado.

4.6.3 Requisitos adicionais

Todos os comandos TPM DEVEM ser concluídos dentro de no máximo 90 segundos.
Se o driver do TPM 2.0 solicitar o cancelamento de um comando, ele deverá ser concluído ou cancelado dentro de 90 segundos.
Os seguintes valores TIMEOUT DEVEM ser implementados: TIMEOUT_A = 1 segundo, TIMEOUT_B = 2 segundos, TIMEOUT_C = 1 segundo, TIMEOUT_D = 1 segundo.
O tamanho mínimo do buffer de entrada DEVE ser 0x500 (ou maior).

5.0 Referências

[ACPI09]	"Especificação avançada de configuração e power interface", versão 4.0, 16 de junho de 2009.
[TCG08]	Grupo de Computação Confiável, "Especificação de Mitigação de Ataque de Redefinição de Plataforma TCG", versão 1.0, 15 de maio de 2008.
[TCG11]	Grupo de Computação Confiável, "Especificação da Interface de Presença Física do TCG", versão 1.20, 10 de fevereiro de 2011.
[TCG12]	Grupo de Computação Confiável, "Pc Client Work Group PC Client Specific TPM Interface Specification (TIS) Versão 1.21, Revisão 1.00.

Partilhar via