AMD Ryzen

Linux 6.3 va avea suport pentru Pluton CRB TPM2 pe procesoarele AMD Ryzen

Dacă lucrurile merg conform planului, dispozitivul TPM2 care se găsește în procesul de securitate Pluton de la Microsoft de pe cele mai recente SoC-uri AMD Ryzen va fi acceptat de Linux 6.3.

Procesorul de securitate Microsoft Pluton a fost o sursă de îngrijorare pentru mulți entuziaști Linux/open source din cauza faptului că este o „cutie neagră” și a numeroaselor necunoscute în jurul rădăcinii de încredere, identității sigure, a testării sigure și serviciilor criptografice oferite de Pluton.

Pluton se regăsește în SoC-urile AMD Ryzen încă din seria 6000 mobile, dar nu se regăsește în procesoarele pentru servere EPYC.

Microsoft Pluton Security Architecture

Expertul în securitate Matthew Garrett s-a ocupat de Pluton încă de la debutul său și, cel mai recent, a lucrat pentru a face ca dispozitivul TPM2 să fie expus sub Linux.

TPM 2.0 Command Response Buffer (CRB) este o interfață standardizată din nucleul sistemului de operare pentru a comunica cu Trusted Platform Module, care funcționează indiferent de arhitectură/TPM.

Dar cu Pluton de la Microsoft, sunt necesare unele modificări ale drivere-ului „tpm_crb” în nucleul Linux pentru ca lucrurile să funcționeze.

Matthew Garrett a explicat în patch-ul TPM CRB care activează suportul Pluton:

Pluton este un procesor de securitate integrat în prezent în unele componente Ryzen recente. Dacă este activat, acesta prezintă două dispozitive – un dispozitiv MSFT0101 ACPI care, în linii mari, este o implementare a unui TPM2 Command Response Buffer și un dispozitiv MSFT0200 ACPI a cărui funcționalitate nu am examinat-o încă în detaliu. Accest patch încearcă doar să adauge suport pentru dispozitivul TPM.

Sunt câteva lucruri care trebui rezolvate aici. Primul este faptul că tabelul ACPI TPM2 utilizează un identificator de metodă de pornire nedefinit anterior. Formatul tabelului pare să includă 16 octeți de date de pornire, ceea ce corespunde unei adrese de 64 de biți pentru un mesaj de pornire și unei adrese de 64 de biți pentru un răspuns de finalizare.

Al doilea este că tabelele ACPI de pe Thinkpad Z13 pe care testez acest lucru nu definesc nici o fereastră de memorie în _CRS (sau, mai exact, există două ferestre de memorie goală). Această verificare nu pare strict necesară, așa că am sărit peste ea.

În cele din urmă, se pare că cipul trebui să fie rugat în mod explicit să treacă în starea de pregătire la fiecare comandă.

Dacă nu se face acest lucru înseamnă că, dacă două comenzi sunt trimise succesiv fără o tranziție de așteptare/pregătire între ele, totul va părea să funcționeze bine, dar răspunsul este pur și simplu comanda inițială.

Lucrez fără nici un document aici, așa că nu sunt sigur dacă acesta este de fapt comportamentul necesar sau dacă îmi scapă ceva în altă parte, dar făcând acest lucru rezultă că cipul funcționează în mod fiabil.

Patch-ul care adaugă acest suport a fost preluat de ramura „next” linux-tpmdd.git, ceea ce face ca acest material să facă parte din modificările aduse drivere-lor de dispozitiv TPM programate pentru viitorul ciclul Linux 6.3

ThinkRoot99

Numele meu este Cristian Moldovan și sunt utilizator de Linux de peste 10 ani.Am făcut parte din mai multe echipe open source din România: Fundația Ceata, Linux Mint România, Rogentos Linux Group. Între 2014 și 2018 am fost propietarul și editorul site-ului de știri despre linux, gnulinux.ro și actual proprietar al rootlinux.ro

View all posts by ThinkRoot99 →

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *