Rapport hävdar säkerhetshål i processorer och styrkretsar från AMD

Jag är också lite besviken på Sweclockers. Titeln borde varit: "Påstådda säkerhetsbrister hos Ryzen" och det tog väldigt lång tid innan titeln ändrades.

Wait what? Företaget ifråga är inte Amerikanskt utan Viceroy har startats av en britt..

Djävulens största lögn var att övertyga världen om att han inte finns.
Vi kan helt enkelt vara överens om att vara oense i denna fråga.

Deras whitepaper säger uttryckligen att "disable PSP" i UEFI inte har någon effekt, och att "ryzenfall" fortfarande går att använda.

Med tanke på att all kommunikation till och från PSP omöjliggörs så låter det extra osannolikt... Det går rent tekniskt i det läget inte att komma åt PSP alls...
Om dom nu menar att det inte hjälper på en redan infekterad CPU så förstår jag det men inte på en ren sådan.

Skickades från m.sweclockers.com

@lastninja: Vilket inte är möjligt enligt andra och AMD själva från start då detta stänger av all kommunikation mellan PSP & CPU, nu friskriver CTS labs sig själva genom att kräva specifik hårdvara (enligt deras intervju med Anandtech) med specifik AGESA/EUFI och här skulle jag definitivt se potential för eufi buggar så som att PSP switch i eufi som inte fungerar som tänkt, det skulle mycket väl kunna intrräffa. Att dom kräver specifik hårdvara för att validera sina "exploits" är i sin sak lite underligt om det enbart skulle bero på säkerhetsluckor i cpuer

Men om man utgår från att det PSP switch fungerar som det ska så kan inte cpu få kontakt alls med PSP och inget ska vara inladdat i minne och i det läget ska dessa saker inte fungera, om det redan är hackad mjukvara inlagt så är det en annan historia då man kan ha tagit med detta i beräkningarna från början och switchen behöver i det läget inte hjälpa alls.

Att däremot flasha in mjukvara direkt som är fulhackad kommer egentligen ingenting hjälpa emot varken PSP switch eller annat (enbart write protect skulle funka eller ROM minne), dock är dessa exploits helt omöjligt i virtualiserad miljö och om du kan flasha bios live på en burk är det rätt osannolikt att du skulle behöva göra det då din access redan är 100%. Det man ska veta i detta läget är att en överväldigande majoritet av all hårdvara är mottagligt för liknande exploits men då är det mest privata burkar som är i riskzonen då dessa är majoriteten som inte körs virtualiserade. Är din access 100% redan så behöver intrånget inte vara detekterat alls så det kan rulla vidare under mycket långa tider utan extra effort. Att som hacker göra detta skulle enbart vara en payoff i enterprise miljö men där är systemen per definition immuna (på fjärr).

Sen "Sydbrygge exploits" där man nyttjar en bakdörr i ASmedia chip, samma exploit finns på alla moderkort som har asmedia chip, oavsett om det är AMD eller Intel eller annan. Detta i sin tur kräver också 100% access redan.

En mycket enkel fix vore som sagt write protect genom OS för Eufi på något vänster, detta skulle förhindra live bios flash från inuti OS.

Ja, det är ju anmärkningsvärt hur CTS agerade.
Bra att veta att de påstådda felen iaf existerar, även om de nu rapporterades på ett rätt kasst sätt.

Sedan är det ju ett problem för hela branschen med den här vågen av problem där fixar ska ut via UEFI/BIOS-uppdateringar.
Där är både viljan att släppa uppdateringar bristande och om tillverkaren sköter sig så är ändå infrastrukturen för dålig för att vanliga användare någonsin skall uppdatera i de allra flesta fallen. (Märks ju väldigt tydligt med Spectre v2 också, t.ex.)