Se tudo correr como planejado, o dispositivo TPM2 encontrado no processador de segurança Microsoft Pluton nos mais recentes AMD Ryzen SoCs será suportado pelo Kernel Linux 6.3.
O processador de segurança Microsoft Pluton tem sido motivo de preocupação para muitos entusiastas de Linux/código aberto por ser uma "caixa preta" e muitas incógnitas em torno da raiz fornecida de confiança, identidade segura, atestado seguro e serviços criptográficos comercializados pela Pluton. O Pluton foi encontrado com os SoCs AMD Ryzen desde a série móvel 6000, mas não é encontrado nos processadores do servidor EPYC.
O especialista em segurança de software Matthew Garrett tem se envolvido com o Pluton desde sua estreia e, mais recentemente, tem trabalhado para expor seu dispositivo TPM2 no Linux. O TPM 2.0 Command Response Buffer (CRB) é uma interface padronizada do kernel do sistema operacional para se comunicar com o Trusted Platform Module que funciona independentemente da arquitetura/TPM. Mas com o Microsoft Pluton, algumas mudanças no driver do kernel "tpm_crb" do Linux são necessárias para que as coisas funcionem.
Garrett explicou no patch Linux TPM CRB habilitando o suporte ao Pluton:
"O Pluton é um processador de segurança integrado presente em algumas peças Ryzen recentes. Se estiver ativado, apresenta dois dispositivos - um dispositivo MSFT0101 ACPI que é amplamente uma implementação de um Buffer de Resposta de Comando TPM2 e um dispositivo MSFT0200 ACPI cuja funcionalidade não examinei em detalhes ainda. Este patch apenas tenta adicionar suporte para o dispositivo TPM.
Há algumas coisas que precisam ser tratadas aqui. A primeira é que a tabela TPM2 ACPI usa um identificador de método inicial indefinido anteriormente. O formato da tabela parece incluir 16 bytes de dados de inicialização, que correspondem a um endereço de 64 bits para uma mensagem inicial e um endereço de 64 bits para uma resposta de conclusão. A segunda é que as tabelas ACPI no Thinkpad Z13 em que estou testando não definem nenhuma janela de memória em _CRS (ou, mais precisamente, há duas janelas de memória vazias). Essa verificação não parece estritamente necessária, então pulei isso.
Por fim, parece que o chip precisa ser explicitamente solicitado a fazer a transição para o status pronto em todos os comandos. Deixar de fazer isso significa que, se dois comandos forem enviados sucessivamente sem uma transição inativo/pronto entre eles, tudo parecerá funcionar bem, mas a resposta é simplesmente o comando original. Estou trabalhando sem nenhum documento aqui, então não tenho certeza se esse é realmente o comportamento necessário ou se estou perdendo algo em algum outro lugar, mas fazer isso faz com que o chip funcione de maneira confiável."
O patch que adiciona esse suporte foi obtido hoje pela ramificação "next" do linux-tpmdd.git, tornando este material como parte das alterações do driver de dispositivo TPM previstas para o próximo ciclo do Kernel Linux 6.3.
Até a próxima !!
Nenhum comentário:
Postar um comentário