Si todo va según lo previsto, el dispositivo TPM2 que se encuentra en el procesador de seguridad Pluton de Microsoft en los últimos SoC Ryzen de AMD será compatible con Linux 6.3.
El procesador de seguridad Pluton de Microsoft ha sido motivo de preocupación para muchos entusiastas de Linux y del código abierto debido a que se trata de una "caja negra" y a que existen muchas incógnitas en torno a la raíz de confianza, la identidad segura, la atestación segura y los servicios criptográficos comercializados por Pluton. Pluton ha estado presente en los SoC Ryzen de AMD desde la serie 6000 para móviles, pero no en los procesadores de servidor EPYC.
El experto en seguridad de software Matthew Garrett ha estado trabajando con Pluton desde su debut y más recientemente ha estado trabajando en conseguir que su dispositivo TPM2 se exponga en Linux. El TPM 2.0 Command Response Buffer (CRB) es una interfaz estandarizada del núcleo del sistema operativo para comunicarse con el Trusted Platform Module que funciona independientemente de la arquitectura/TPM. Pero con Pluton de Microsoft, se necesitan algunos cambios en el controlador del kernel "tpm_crb" de Linux para que las cosas funcionen.
Puede leer también | Realidades en el uso de Linux
Garrett explicó en el parche de Linux TPM CRB al habilitar el soporte de Pluton:
"Pluton es un procesador de seguridad integrado presente en algunas piezas Ryzen recientes. Si está habilitado, presenta dos dispositivos - un dispositivo MSFT0101 ACPI que es a grandes rasgos una implementación de un Command Response Buffer TPM2, y un dispositivo MSFT0200 ACPI cuya funcionalidad aún no he examinado en detalle. Este parche sólo intenta añadir soporte para el dispositivo TPM.
Hay algunas cosas que necesitan ser manejadas aquí. La primera es que la tabla ACPI del TPM2 utiliza un identificador de método de inicio no definido previamente. El formato de la tabla parece incluir 16 bytes de datos de inicio, que corresponden a una dirección de 64 bits para un mensaje de inicio y una dirección de 64 bits para una respuesta de finalización. La segunda es que las tablas ACPI del Thinkpad Z13 en el que estoy probando esto no definen ninguna ventana de memoria en _CRS (o, más exactamente, hay dos ventanas de memoria vacías). Esta comprobación no parece estrictamente necesaria, así que me la he saltado.
Por último, parece que hay que pedir explícitamente al chip que pase al estado listo en cada comando. No hacer esto significa que, si dos comandos se envían en la sucesión sin una transición de inactivo / listo en el medio, todo va a parecer que funciona bien, pero la respuesta es simplemente el comando original. Estoy trabajando sin documentos, así que no estoy seguro de si este es realmente el comportamiento requerido o si me estoy perdiendo algo en otra parte, pero haciendo esto resulta en el chip de trabajo de forma fiable. "
El parche que añade esta compatibilidad ha sido recogido ayer por la rama "next" de linux-tpmdd.git, lo que lo convierte en parte de los cambios en los controladores de dispositivos TPM previstos para el próximo ciclo Linux 6.3.
Créditos: Phoronix