Linux 5.15 schakelt AMD SME-functie standaard uit vanwege opstartproblemen

Versie 5.15 van de Linux-kernel schakelt de Secure Memory Encryption-functie van bepaalde AMD-cpu's standaard uit. De functie werd voorheen standaard ingeschakeld op ondersteunde cpu's, maar zou voor opstartproblemen zorgen op Linux-systemen.

Volgens Phoronix werd SME standaard ingeschakeld sinds ondersteuning voor de feature werd toegevoegd aan de Linux-kernel. Linux-gebruikers hebben echter bugs opgemerkt, waarbij de feature leidde in bepaalde gevallen tot opstartproblemen. Dat zou bijvoorbeeld voorkomen door interactieproblemen tussen SME en de input-output memory management unit. Ook kan SME leiden tot problemen met bepaalde gpu-drivers, die soms op problemen stuiten als het geheugen van een pc is versleuteld.

Linux-gebruikers melden dat de problemen zich bijvoorbeeld kunnen voordoen op Raven Ridge-apu's van AMD, zoals de Ryzen 3 2200G. De opstartproblemen kunnen echter ook voorkomen bij andere processors. Gebruikers die SME alsnog willen gebruiken op Linux-systemen met kernelversie 5.15, kunnen de feature handmatig inschakelen door mem_encrypt=on toe te voegen aan de bootloader-opties.

De Secure Memory Encryption-extensie laat ondersteunde cpu's het systeemgeheugen hardwarematig versleutelen. Op de EPYC-serverprocessors en Ryzen Pro- en Threadripper Pro-cpu's van AMD, wordt de functie ook wel Memory Guard genoemd.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (20)

Die SME-functie is dus een nieuwe functionaliteit van de Zen-microarchitectuur.

De (officiele) kernel-support van SME lijkt sinds Linux Kernel 5.2.x erin te zitten.

ik vraag me wel af als het gemakkelijk uit te schakelen is en de OS werkt daarna prima, hoe eenvoudig het dan wel niet is voor een hacker om een kernel-mod te doen en te rebooten en voila je hebt (zonder het te weten) een kwetsbare server/router/iot/etc runnen.

Als iemand een kernel mod kan installeren en/of een restart kunt doen heb je al remote access + root rechten. Het systeem is dan toch al verloren. Het geheugen uitlezen is in dat geval vrij omslachtig en kun je beter keyloggers/root kits installeren of de filesystems scannen voor private keys, enz.

Er zit wel wat in, natuurlijk.

Stel dat je al wel beperkte toegang hebt tot een machine, en graag het versleutelde geheugen zou uitlezen. Dat lukt niet zolang SME nog actief is.

Als je via de ene exploit de boot-configuratie kunt aanpassen, en via een andere exploit een reboot kunt veroorzaken.

Daarna draait het systeem, zonder waarschuwing naast die ene vastloper, opeens zonder SME.

Als het voor jou belangrijk is dat SME aan staat op je systemen dan mag ik aan nemen dat je ook in de gaten houdt dat het daadwerkelijk geactiveerd is. Op Linux is dat eenvoudig te doen door te monitoren op de "sme" flag in /proc/cpuinfo. Mocht het scenario dat jij schetst voorkomen dan zou je monitoring dus meteen moeten gaan piepen.

Nee, dat werkt natuurlijk niet. Een kernel level anti-SME hack kan de /proc/cpuinfo ook vervalsen. Je hebt TPM-achtige systeemauthenticatie nodig om extern toegang tot betrouwbare informatie te krijgen.

Wat is de toegevoegde waarde van het volledig versleutelen van het geheugen? Is dat om te voorkomen dat kwaadaardige applicaties geheugen van andere applicaties kan lezen of om virtualisatie bij een cloudprovider veiliger te maken?

En hoe werkt dit dan? Een applicatie moet zelf namelijk ook gegevens in geheugen kunnen plaatsen en uit kunnen lezen.

[Reactie gewijzigd door OB1 op 18 oktober 2021 19:34]

Volgens mij beschermt het alleen tegen fysieke toegang.

Want als een applicatie uberhaupt buiten zijn eigen memory space kan lezen is de kernel al lek en kan de key waarmee het geheugen versleuteld is net zo goed uitgelezen worden.

Het beschermt ook tegen dingen als rowhammer tussen virtuele machines in. Als je enkele geheugenbits uit kunt lezen, zou je sleutels en andere geheimen kunnen lekken. Met geheugenencryptie krijg je versleutelde bits via de side channel attacks waar je niet direct wat nuttigs mee kan.

Toen de eerste Intel-aanvallen publiek werden, moesten hostingproviders als een malle gaan patchen met onverwachte downtime tot gevolg. Met geheugenversleuteling is de impact geringer en hoeft er geen noodpatch toegepast te worden.

Natuurlijk heb je liever geen datalekken via side channel attacks, maar versleuteld geheugen kan een laag beveiliging toevoegen in het geval dat er toch een fout tussensluipt.

Buiten virtuele machines zie ik er eigenlijk niet heel veel extra nut in, aangezien je inderdaad eigenlijk al niet zomaar bij dat geheugen mag komen. Het kan nog steeds een beveiligingslaag bieden als je bijvoorbeeld containers gebruikt die zelfs met semi-roottoegang niet buiten hun zandbak mogen treden, maar een container-escape-exploit is veel makkelijker en betrouwbaarder dan een geheugen-side-channelaanval voor zover ik weet.

tl;dr: Als jij niet weet waarom jij dit nodig zou hebben, dan heb je het niet nodig en kun je het prima uit schakelen.

Dat zou je inderdaad zo kunnen stellen, in elk geval totdat Windows en andere besturingssystemen er uitgebreid gebruik van maken. Zo was de IOMMU op de meeste processoren redelijk nutteloos en ongebruikt totdat Thunderbolt opkwam en Intel VT-d (en AMD-equivalent) staan nog steeds uit, ondanks dat Windows een behoorlijk beveiligingsvoordeel uit de technologie kan halen. VT-x (en equivalent) staat gelukkig wel standaard aan, en dat is hoe Virtualisation Based Security kan werken op Windows zonder grote performance-impact (aannemende dat de drivers en software erop voorbereid zijn) een enorme laag beveiliging kan bieden.

Het zou heel mooi zijn als je de setting het beste aan kon laten en je OS en browser automatisch de feature naar hun voordeel zouden gebruiken. In de praktijk duurt het helaas jaren voor zoiets daadwerkelijk geïmplementeerd wordt waar het uitkomt.

Er zijn in het verleden meerdere malen aanvallen gepubliceert die juist niet buiten hun eigen memory space zijn gekomen maar door de fysieke structuur van DRAM alsnog geheugen van andere applicaties konden lezen en/of manipuleren (bekend voorbeeld is Row Hammer). Door de content van het geheugen volledig te versleutelen maak je dat soort aanvallen een stuk minder effectief. Niks is compleet onkraakbaar maar het is wel een heel stuk veiliger. Vooral omdat we al weten dat dit soort exploits gewoon mogelijk zijn.

@OB1 Het is dus zeker wel relevant om RAM te versleutelen uit een security perspectief. Hoofdzakelijk natuurlijk voor enterprise/virtuatlisatie (waar natuurlijk ook de gehele cloud onder valt) maar ook voor desktops heeft dit, net als veel andere security mitigations, prima bestaansrecht.

[Reactie gewijzigd door Darkstriker op 18 oktober 2021 20:16]

Interessant leesvoer. Dank je wel!

Moet ik bij fysieke toegang dan denken aan bijvoorbeeld onderschepte moederborden?

Nee alleen actieve borden. Als de systemen powered down zijn is het geheugen vervlogen.

Dus als je alle pinnetjes fysiek uitleest terwijlde pc draait? Lijkt me wel een zeer uitzonderlijke situatie, dit is gewoon hardwarematige encryptie. Handig, want een kernel is vrijwel standaard lek Er zitten altijd bugs in.

Niet als je de RAM modules behoorlijk afkoelt en meteen verwijdert uit het moederbord na uitschakeling. Je kan nog steeds 80% van wat er in het geheugen is opgeslagen terughalen na zo'n 20 tot 30 minuten.

Niet weggelegd voor de meeste Tweakers, maar zo zeker dat RAM modules "leeg" zijn na uitschakeling moet je echt niet zijn.

Betekent dit dat geheugenversleuteling op bepaalde chips helemaal niet beschikbaar is als de IOMMU wordt gebruikt? Want dat zou erg jammer zijn voor mensen die een thuislab draaien voor virtual machines en dergelijke.

Vziw werkt SEV (Secure Encrypted Virtualization) ook zonder SME en zit in de IOMMU driver Secure Nested Paging zodat je niet het geheugen van een andere guest kan aanspreken.