Speculative-executionbug Zenbleed kan 30kB/s aan data van Zen 2-cpu afluisteren

Onderzoekers hebben een speculative-executionbug gevonden in AMD-cpu's op basis van Zen 2-architectuur. De bug, Zenbleed, is een use-after-freebug die het mogelijk maakt om tot 30kB/s per core af te luisteren van de chip. AMD heeft inmiddels een microcodepatch uitgebracht.

De onderzoekers noemen de bug Zenbleed. Dat is een vergelijkbare kwetsbaarheid in de zogenoemde speculative-executionfunctie van cpu's. In de afgelopen jaren zijn meerdere van zulke bugs naar buiten gekomen. Zenbleed werd ontdekt door beveiligingsonderzoekers die eerder bij Googles securityafdeling Project Zero werkten. De onderzoekers hebben een technische beschrijving gepubliceerd en een werkende proof of concept online gezet.

De bug treft alle Zen 2-processors, zowel de Ryzen- en Threadripper-serie als de zakelijke modellen zoals de Epyc Rome voor datacenters. De onderzoekers hebben hun bevindingen met AMD gedeeld. Dat heeft inmiddels een microcodepatch uitgebracht onder volgnummer AMD-SB-7008. De bug wordt verder gevolgd onder CVE-2023-20593.

Zenbleed is een speculative-executionbug. Speculative execution is een optimalisatiemethode waarbij een cpu bepaalde taken of berekeningen probeert te voorspellen om de processor sneller te maken. Zenbleed is een kwetsbaarheid in de vzeroupper-instruction die tijdens dat proces wordt gebruikt. Als die instruction aangeroepen wordt, wordt een van de vectorregisters veranderd in een 0-bit, zodat dat register voor een bepaalde actie kan worden gereserveerd. Als dat via een speculative execution gebeurt, maar het blijkt dat het register niet nodig is, dan wordt de 0-bit daar weer uit verwijderd. Maar in de tussentijd kan een aanvaller er met speciale malware voor zorgen dat die registerruimte wordt opgevuld met andere code en kan hij ook bestaande code uitlezen.

Volgens de onderzoeker lijkt dat op een use-after-freebug, iets dat voorheen amper voorkwam in cpu's. Hij zegt verder dat het mogelijk is om zijn malwarecode te optimaliseren om meer data af te luisteren dan normaal. Hij zou in totaal 30 kilobyte aan data per seconde kunnen afluisteren.

Reacties (55)

[laurxp]

Deze nieuwe bug is compleet anders dan de oude speculative execution bugs. Bij Spectre werkte de CPU namelijk gewoon naar behoren, maar bleek het mogelijk te zijn om informatie te vergaren door naar de neveneffecten van speculative execution te kijken. Het ging daar om een ontwerpfout in het hele concept van speculative execution. Je kon bijvoorbeeld de CPU zo ver krijgen om - afhankelijk van data waartoe je geen toegang zou moeten hebben - al dan niet een segment vanuit geheugen naar cache te laden, en vervolgens door het meten van de toegangstijd tot het segment de geheime data te ontdekken. Deze nieuwe bug is daar niet mee te vergelijken. Het gaat hier daadwerkelijk om een defect in een heel specifieke set van instructies, dus het lijkt meer op de FDIV bug van een jaar decennia terug.

De kern van Zenbleed is dat de fysieke registers in de CPU ontkoppelt zijn van de logische registers in assembly. Hierdoor kunnen instructies die niet van elkaar afhankelijk zijn tegelijkertijd uitgevoerd worden, ook al gebruiken ze dezelfde logische registers. De CPU houd een vertalingstabel bij van logisch register naar fysiek register. Omdat het nogal zinloos is om een fysiek register toe te kennen aan een lege waarde, kan een logisch register in de tabel ook een "zero flag" hebben - wat simpelweg aangeeft dat dat register leeg is.

Het tweede essentiële deel is dat een CPU op data van verschillende lengtes kan werken. Origineel waren de vectorregisters (die trouwens niks te maken hebben met de gelinkte "Vector Processor" Wikipedia-pagina in het artikel) bij de introductie van SSE 128 bits breed, maar ze zijn met de introductie van AVX breder gemaakt, waardoor ze 256 bits breed zijn geworden. Het probleem is dat de oude SSE instructies alsnog alleen op de onderste 128 bits moesten werken! Het gevolg is dat de CPU een soort aparte "SSE-modus" en "AVX-modus" heeft gekregen, en switchen tussen de twee is nogal duur - vooral omdat je bij het switchen van AVX naar SSE data moet opslaan omdat je later weer terug naar AVX zou kunnen gaan. De oplossing is "vzeroupper", waarbij je bij het switchen van AVX naar SSE aangeeft dat je de bovenste 128 bits nooit meer gaat gebruiken. Dit maakt de switch een heel stuk goedkoper.

Wat er in de praktijk gebeurt, is dat de fysieke registers 128 bits breed zijn, en een 256-bit logisch register is simpelweg twee fysieke 128-bit registers. Bij het uitvoeren van een "vzeroupper" geeft de CPU het fysieke register dat bij de bovenste 128 bits hoort vrij, en zet het in de vertalingstabel voor dat logische register een "zero flag" aan. Het fysieke register kan nu door een ander proces gebruikt worden. Dit werkt allemaal nog naar behoren.

Waar de bug in zit, is dat de CPU speculatief instructies uitvoert. Ook al is het nog niet zeker wat de volgende instructie is, de CPU zal altijd één van de twee opties beginnen met uitvoeren. Het wacht alleen met het wegschrijven van de resultaten tot het 100% zeker is dat deze instructie daadwerkelijk uitgevoerd had moeten worden. Het probleem hier is dat de CPU begint met het uitvoeren van een vzeroupper, de bovenste 128 bits vrijgeeft voor een ander proces, vervolgens er achter komt dat vzeroupper helemaal niet uitgevoerd had moeten worden, en het register weer terug neemt.

Maar in sommige obscure omstandigheden gaat dit fout, en krijgt het een register terug dat al in gebruik is genomen door een ander proces. Het bevat ineens data waar je helemaal geen toegang toe zou moeten hebben! Dit is vergelijkbaar met een Dangling Pointer, en het is een soort use-after-free bug - wat inderdaad "amper voorkwam" in CPUs omdat het normaal gesproken een bug is op een compleet ander abstractieniveau. Het heeft niks te maken met malware, en er is geen aparte code nodig om het "op te vullen". Je krijgt gewoon ongevraagd ineens verkeerde data voorgeschotelt - en ieder programma zou dit kunnen doen.

De precieze details zijn nog niet 100% duidelijk en bronnen spreken elkaar tegen, maar hopelijk geeft dit wat meer helderheid dan alleen het artikel zelf.

[Patriot]

Maakt dat de kans dat deze fix leidt tot performanceverminderingen ook kleiner? Dat was bij Spectre en Meltdown natuurlijk nog een ding, omdat het er volgens mij min of meer op neer kwam dat er veel minder speculatief gedaan werd/kon worden en dat effectief dus neerkwam op minder kunnen doen per tik.

[laurxp]

Het zal absoluut voor performanceveranderingen zorgen, maar persoonlijk verwacht ik niet dat de gevolgen erg groot zijn. Zenbleed is alleen te triggeren door drie optimalisaties op precies de juiste manier te combineren. Alle CPUs bevatten zogeheten "chicken bits" om optimalisaties uit te zetten, dus ze zullen snelle workaround gewoon de goedkoopste uit zetten. Hierdoor zullen specifieke instructies een paar clock cycles langzamer worden - maar ik verwacht niet dat de impact meer dan 1% is. Op lange termijn is het wellicht mogelijk om de microcode aan te passen, waarmee je de hele bug teniet kan doen met zeer kleine performance-implicaties simpelweg door de interne optimalisatie te "herprogrammeren".

Spectre en Meltdown waren eigenlijk alleen 100% op te lossen door alle speculative execution uit te zetten. Dat is best een flink probleem, want juist door speculative execution zijn CPUs tegenwoordig zo snel. In de praktijk werd de soep wat minder heet gegeten. Lekken van data binnen één proces (vooral belangrijk als je onvertrouwde code draait, zoals in een browser) kon voorkomen worden door minieme aanpassingen in de compiler, waardoor de kwetsbare assembly niet meer gegenereerd werd. Dit had een minieme performance impact. Lekken van data van de kernel naar het proces kon voorkomen worden door een aanpassing van de kernel, waardoor de kernel pages niet meer gemapped zijn in user mode. Dit heeft een performance impact, maar alleen voor syscall-heavy code en niet zo extreem als het uitzetten van speculative execution.

Vanwege deze twee workarounds werd het eigenlijk onmogelijk om de issues uit te buiten, dus was het niet nodig om speculatieve executie uit te zetten. Sure, je kán op oude hardware alsnog een programma schrijven en uitvoeren dat er vatbaar voor was als je dat graag wilde, maar waarom zou je dat doen?

[TD-er]

Zou dit ook tot bugs kunnen leiden waarbij proces A de data van proces B kan beinvloeden?
Dus niet zozeer dat je een pointer krijgt naar data van een ander proces wat niet meer gebruikt gaat worden door dat proces, maar meer dat proces A dus verder denkt te gaan met iets maar dat proces B dit al aangepast heeft?
Lijkt me op zich onwaarschijnlijk, want dat zou al lang tot vele bugreports hebben geleid, maar zoals je het hier uitlegt, klinkt het als een concurrency bug in de toewijzing van register mapping.

[Toettoetdaan]

Het lijkt uitsluitend te gaan om lezen van data in registers die als leeg geregisterd staan.

Een beetje zoals een harde schijf die na het verwijderen van een bestand slechts aangeeft dat de 1'en en 0'en van dat bestand mogen worden overschreven, maar zolang je het niet overschrijft kun je dat bestand nog steeds terughalen.

[laurxp]

Ja, dat lijkt zeker mogelijk te zijn. Je schrijft "5" naar een register, de CPU geeft het register per ongeluk vrij en maakt dat ongedaan, en je register bevat ineens "7" van een ander proces.

De reden dat dit niet voor bug reports zorgt is dat er een héél specifieke opvolging van instructies voor nodig is, waar ook nog eens een vrij precieze timing bij komt kijken. Het is niet alsof iedere "vzeroupper" de fout in gaat! Je moet eerst een "XMM Register Merge Optimization" hebben, gevolgd door een "register rename", gevolgd door een speculatieve "vzeroupper". En vervolgens trigger je de bug maar eens in de paar honderd/duizend/tienduizend gevallen. In reguliere code zal dit vrijwel nooit voorkomen.

[Sebazzz]

Ik heb dit geprobeerd op Ubuntu 20.04 op WSL, AMD Ryzen 7 3700X 8-Core Processor, en het werkt als een trein. Volgens mij kan ik ook geheugen lekken van de Windows host.

Thread 01: "eviceTyp"
Thread 06: "_1C07#9&28447684"
Thread 09: "_?r>"
Thread 09: "d#vid_04"
Thread 12: "l04#b&cc"
Thread 09: "412-16ec"
Thread 09: "gramData"
Thread 09: "412-16ec"
Thread 09: "race.log"
Thread 07: "%%%%%%%%%%%%%%%%"
Thread 11: "l04#b&cc"
Thread 14: " "
Thread 11: "ringInstallDat"
Thread 11: "d#vid_04"
Thread 08: "_1C07#9&28447684"
Thread 11: "539&mi_0"
Thread 11: "ringInstallDat"
Thread 12: "iceOKHID-com"
Thread 15: " "
Thread 09: "d#vid_04"
Thread 00: " "
Thread 04: "st:Sep:S"
Thread 04: ":Novembe"
Thread 04: ":November:Dec:De"
Thread 04: "er:Dec:December"
Thread 04: "st:Sep:S"
Thread 12: " 1.00, 0.00), (0"
Thread 04: "Xaml.dll"
Thread 10: "iceOKHID-com"
Thread 04: "000030}"
Thread 13: " "
Thread 10: "ringInstallDat"

En:

Thread 04: "tr_log_tail_size"
Thread 04: "REAM_CONTENTNAME"
Thread 04: "SESSION_USERNAME"
Thread 04: "k4\\Servi"
Thread 04: ": DevicesMonitor"
Thread 04: "tor | TIME = 101"
Thread 04: "ice.exe"
Thread 04: ": DevicesMonitor"
Thread 04: "ice.exe"
Thread 04: "02(avg: 999) ms "
Thread 04: "-07-25 10:57:19."
Thread 04: ".7844 | 197 | IN"
Thread 04: "-07-25 10:57:19."
Thread 04: "(avg: 999) ms "
Thread 04: ": DevicesMonitor"
Thread 04: "02(avg: 999) ms "
Thread 04: "irLink4"
Thread 04: "ice.exe"
Thread 04: "(avg: 999) ms "
Thread 04: "023-07-25 10:57:"
Thread 04: "| 657 | INFO: De"
Thread 04: ".4308 | 21 | INF"
Thread 04: ".5197 | 4 | INFO"
Thread 04: ":45:43.6155 | 80"
Thread 08: "utePersistContex"
Thread 08: "\\Corsair"
Thread 08: "rvice.ex"
Thread 08: "\\Corsair"
Thread 08: "rvice.ex"
Thread 08: "86)\\Cors"
Thread 06: "6:09.8550 | 290 "
Thread 06: "O: DevicesMonito"
Thread 06: " 10:45:51.6744 |"
Thread 06: "3000000000000000"
Thread 06: "or | TIME = 1005

[Reactie gewijzigd door Sebazzz op 1 augustus 2024 22:32]

[laurxp]

Absoluut, dit negeert alle grenzen tussen host en VM. Als code na of tijdens elkaar dezelfde CPU core gebruikt, kan het data lekken.

[goarilla]

Dus eigenlijk is dit zowel anders als erger dan de Speculative Execution bugs van Intel.
Je hoeft hier immers als ik het goed begrijp helemaal geen timing attacks te doen en data vissen/zeven.
Gewoon een paar normale userland instructies gebruiken en andermans data is (gedeeltelijk)
zichtbaar.

En het is toevallig dat jij dit een use after free bug probleem in hw noemt, want
dat is exact wat de Slackware Security advisory van vandaag meedeelde:

Here are the details from the Slackware 15.0 ChangeLog:
+--------------------------+
patches/packages/kernel-firmware-20230724_59fbffa-noarch-1.txz: Upgraded.
AMD microcode updated to fix a use-after-free in AMD Zen2 processors.
From Tavis Ormandy's annoucement of the issue:
"The practical result here is that you can spy on the registers of other
processes. No system calls or privileges are required.
It works across virtual machines and affects all operating systems.
I have written a poc for this issue that's fast enough to reconstruct
keys and passwords as users log in."
For more information, see:
https://seclists.org/oss-sec/2023/q3/59
https://www.cve.org/CVERecord?id=CVE-2023-20593
(* Security fix *)
+--------------------------+

Danku voor de diepere info hieromtrend.

[JeroenED]

De onderzoekers noemen de bug Zenbleed, een verwijzing naar Heartbleed. Dat is een vergelijkbare kwetsbaarheid in de zogenoemde speculative-executionfunctie van cpu's.

@TijsZonderH Heartbleed was geen vergelijkbare kwetsbaarheid. Heartbleed was een kwetsbaarheid in OpenSSL die random data uit het memory kon doorgeven naar de hacker. Was destijds de starter van alle named vulnerabilties. Je hebt het waarschijnlijk over Meltdown en Spectre

https://en.wikipedia.org/..._(security_vulnerability)
https://en.wikipedia.org/..._(security_vulnerability)
https://en.wikipedia.org/wiki/Heartbleed

[Reactie gewijzigd door JeroenED op 1 augustus 2024 22:32]

[TijsZonderH]

Ach je natuurlijk, ik raak ook in de war van het 'bleed'-gedeelte.

[jurroen]

Nou ja zeg, dat van de redacteur over alles security en privacy

Nee, alle gekheid in een SMT register op een stokje: we hebben nogal wat vulns gehad met een fancy nasn en logo. En sommige ook weer met verschilende versies (Spectre). Wellicht wat voor de T.net podcast? Named vulnerability trivia.

[HKS-Skyline]

Een lek is een lek, maar hoeveel kan nou effectief je met 30Kbps als er gigabytes per seconde doorheen gaan? Het kunnen planten van code lijkt mij een veel groter probleem.

[oef!]

Uit de bron: It turns out that mispredicting on purpose is difficult to optimize! It took a bit of work, but I found a variant that can leak about 30 kb per core, per second.

This is fast enough to monitor encryption keys and passwords as users login!

Zowel het planten van de code als de mogelijkheid om de data uit te lezen is een probleem, afhankelijk van wat een kwaadwillende wil doen.

[GertMenkel]

Deze kwetsbaarheid doorbreekt de virtualisatielaag, dus verschillende virtual machines die dezelfde core gebruiken kunnen ineens delen van elkaars geheugen lezen. Niet zomaar willekeurige geheugen, maar geheugen dat op dat moment gebruikt wordt!

Je kunt binnenkomende data als strings die worden vergeleken lezen uit de CPU zelf. Dingen als strcpy worden ook nog wel eens gebruikt om wachtwoorden in veilige buffers te stoppen voor ze door een hash worden gehaald en wellicht de hashes zelf.

Als je bijvoorbeeld een VM op een cloudhost kan krijgen op dezelfde fysieke machine als je doelwit (daar zijn hele papers over geschreven, duur maar goed mogelijk) zou je een reeks logins kunnen uitvoeren die bevestigt dat je je doelwit geraakt hebt en dan de inkomende usernames/passwords scrapen.

[Teun!]

Aan de andere kant, een veel voorkomend target is de encryptie key en die is niet zo groot.

[CH4OS]

Kilobyte, niet kilobit (KBps vs Kbps), dat scheelt al een factor 8. Daarnaast is het ook per core. Bij 8 cores dus 240KBps. Dat is misschien niet veel inderdaad, maar zolang het toch niet opgemerkt wordt dat er data lekt, kun je redelijk ongestoord te werk gaan. Wanneer het kleine hoeveelheden zijn, valt het ook minder op (heeft minder impact op de performance en stroomverbruik).

[Reactie gewijzigd door CH4OS op 1 augustus 2024 22:32]

[GarBaGe]

Consumenten kunnen dit dus fixen door te upgraden naar 5000-series Ryzen
Edit:
Zo te zien zit de fix in een AGESA update.
Ik kan me niet voorstellen dat veel consumenten hiervoor een BIOS update gaan installeren op basis van deze nieuwere AGESA (en dan moeten moederbord fabrikanten deze nieuwe AGESA wel verwerken in een nieuwe BIOS update)

[Reactie gewijzigd door GarBaGe op 1 augustus 2024 22:32]

[Sleepkever]

Ik zie juist in dit Tom's hardware artikel dat de meeste CPU's pas in november/december een AGESA release krijgen vanuit AMD naar de fabrikanten. En daarna gaat er dus nog tijd overheen om alle individuele moederboarden te patchen.

Microcode updates via het OS lijken voorlopig de way to go.

[Crugster]

Zie ook het officiële AMD-SB-7008 bulletin (i.e. voor desktops duurt het inderdaad nog wel een paar maandjes en dan zit je nog met de 'supply chain' wachttijd (de MOBO fabrikanten zelf etc.).

P.S. Ben benieuwd wanneer mijn Win11 mij een Microcode update voorschotelt!

[Reactie gewijzigd door Crugster op 1 augustus 2024 22:32]

[CH4OS]

Een microcode update hoeft dan ook niet altijd per se via een BIOS update te worden uitgerold.

[GarBaGe]

Hoe dan? AMD Ryzen Master utility doet dit niet, toch?

[The Zep Man]

Hoe dan?

Kan gewoon door het OS ingeladen worden tijdens het booten. Windows doet dit, en Linux ook in veel standaardconfiguraties. Zo kan in sommige configuraties wel eens sprake zijn van drie verschillende versies van microcode:

• Wat in de CPU zit ingebakken.
• Wat de BIOS inlaadt.
• Wat het OS inlaadt.

Dit conflicteert niet met elkaar.

Overigens zijn er zeldzame situaties waarin je juist een lagere microcodeversie zou willen gebruiken, zoals toen een aantal Intel-CPU's onofficieel met AVX-512 konden omgaan. Dat schakelde Intel uit met een nieuwere microcodeversie. In andere gevallen kosten deze updates gewoon prestaties, omdat ze bepaalde functionaliteit herconfigureren of uitschakelen. Uiteraard zijn zulke uitzonderlijke gevallen enkel nuttig in een labomgeving of voor specifiek afgezonderd gebruik. Vuistregel is gewoon netjes de laatste versie draaien, en daar hoef je niet over na te denken. Dat doet je OS voor je.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 22:32]

[Crugster]

Weet iemand wat de methode is om te kijken of er een Microcode update via het OS is doorgevoerd (ik ben zowel in Win11/10 en Linux Debian/Ubuntu geïnteresseerd)?

Lees: Hoe check je of je "veilig" zit beschermd door je OS (tot het moment dat je moederbord fabrikant een EUFI/BIOS update beschikbaar stelt)?

En is er al een OS gebaseerde Microcode update beschikbaar is voor Win11 (en Linux Debian/Ubuntu)?

[The Zep Man]

Weet iemand wat de methode is om te kijken of er een Microcode update via het OS is doorgevoerd (ik ben zowel in Win11/10 en Linux Debian/Ubuntu geïnteresseerd)?

Linux:
dmesg | grep 'microcode'

Het resultaat is iets van:
microcode: updated early: 0x(versie laag) -> 0x(versie hoog), date = (datum nieuwe microcode)

Windows:
Zie dit.

Lees: Hoe check je of je "veilig" zit beschermd door je OS (tot het moment dat je moederbord fabrikant een EUFI/BIOS update beschikbaar stelt)?

Standaard (je houdt Windows up-to-date, of je draait een standaard aanbevolen installatie van Linux) hoef je je hier niet druk over te maken. Het OS zal nieuwere microcode inladen wanneer beschikbaar.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 22:32]

[CrazyJoe]

De AVX-512 functionaliteit beperkte zich tot the P-cores, terwijl de E-Cores hier niet mee konden omgaan. Dus als je AVX-512 code wilde gebruiken moest je de E-Cores uitschakelen omdat deze anders bij task migration ineens met code geconfronteerd zouden kunnen worden die ze niet uitvoeren konden, wat in dit soort gevallen voor unexpected behavior kan zorgen.

Dus dat Intel dit via micro-code gepatcht heeft lijkt me zeker geen slecht idee. Jammer voor die paar applicaties die AVX-512 konden gebruiken, maar als je een groot gedeelte van je processor moet deactiveren om deze te kunnen draaien, dan lijkt me dat geen goed argument voor deze functionaliteit in de processor te laten zitten.

[RoyD]

Je kunt toch ook taken aan bepaalde kernen vastzetten? Dan speelt het geschetste scenario niet.

[CrazyJoe]

Maar als je dat niet doet (en het zal niet automatisch gebeuren) dan is de kans op crashes erg groot. Een ander aspect is natuurlijk ook dat Intel je voor AVX-512 liever een van de Xeon processoren wil verkopen. Er zijn namelijk niet zoveel consumer applicaties die voordeel hebben bij AVX-512 over AVX2. En op Intel processoren heeft AVX-512 ook een sterke impact op stroomverbruik en temperatuurontwikkeling

En hoewel AMD nu AVX-512 in ZEN4 ondersteunt, is de manier waarop een beetje een workaround: ze gebruiken in principe i.p.v. een 512 bit datapath voor de instructies, een double pump principe waarbij ze twee 256 bits waarden (die AVX2 ook gebruikt) na elkaar doorschuiven naar de AVX-512 engine.

Dat is in principe een langzamere methode om data te laden in de AVX-512 registers dan Intels oplossing, maar maakt het implementeren van AVX-512 een stuk eenvoudiger (geen redesign om 512 bits datapaths toe te voegen).

[CH4OS]

Ik zie geregeld op Linux microcode OS updates voorbij komen, Windows heeft ze ook (en komt het dus via Windows Updates mee).

[Reactie gewijzigd door CH4OS op 1 augustus 2024 22:32]

[Koen Hendriks]

Bij mijn Dell XPS worden BIOS updates ook automatisch meegenomen met Windows updates volgens mij.

[rbr320]

Dat kan kloppen, hardware uit de professionele/zakelijke lijnen van de grote fabrikanten zoals Dell en HP stellen steeds vaker hun BIOS (tegenwoordig heet dat officieel UEFI) als hardware-apparaat beschikbaar aan het OS, waardoor het via de reguliere kanalen geupdate kan worden alsof het een driver/firmware update betreft. Uiteraard wordt deze pas echt actief na een herstart van het systeem.

[mjl]

Wel grappig dat het wel als BIOS update benoemd wordt in Windows Update zal zijn omdat de meeste gebruikers UEFI niks zegt 😀

[rbr320]

Klopt, de term BIOS is zo ingeburgerd dat hij zelfs onder Tweakers nog veel gebruikt wordt, zoals je aan de comments hier kunt zien. Ondanks dat de meesten wel zullen weten dat het technisch incorrect is.

[IamGrimm]

UEFI is ook wat ongemakkelijk uit te spreken. Zeker ten opzichte van het makkelijke BIOS.

[Koen Hendriks]

Ik ben me prima op de hoogte van UEFI, maar noem het hier BIOS update omdat Dell doodleuk op het scherm laat zien "Updating BIOS" haha

[mjl]

Klopt net als MS Windows voor de massa beter te begrijpen, alleen wij storen ons er aan 🧐

[Tomino]

nieuws: Onderzoekers ontdekken ongepatchte backdoor in 271 Gigabyte-moederborden

Daar hebben niet alle fabrikanten goede ervaringen mee..

[rbr320]

De ervaring van de fabrikanten is prima, die krijgen wat ze hebben willen, zoals in dit geval dat hun crappy "update center" bloatware geïnstalleerd wordt. Het is de ervaring van de klant die niet goed is, want die zit met beveiligingsproblemen die ze moeten oplossen of op z'n minst mitigeren.

[vectormatic]

Kleine caveat, sommige 5x00 laptop chips zijn ook nog Zen 2, zoals mijn 5500u (en de 5300u en 5700u)

En ik geloof zelfs dat er in de 7xxx serie laptop chips nog Zen 2 spul uitkomt, ik dacht de 7x20 chips

[bwerg]

En de Ryzen 4000's op desktop.

[StGermain]

Het was misschien wel handig geweest als de auteur verduidelijkt had dat bij zen 2 over een deel van de ryzen 3xxx cpu’s gaat.

[bwerg]

En over de Ryzen 4100/4500/4700S, en sommige mobiele 5000's. En over sommige Ryzen 7000's en de komende 8000's en wat daarna dan ook moge komen, waarbij de architectuur in theorie kan afleiden aan het gedrocht van AMD's nieuwe naamgevingsconventie, zo uit mijn hoofd het derde van de vier nummertjes.

TL;DR: bij twijfel, zoek de architectuur gewoon op op AMD.com of wikipedia.

[Reactie gewijzigd door bwerg op 1 augustus 2024 22:32]

[MrMonkE]

Man mijn AMD CPU zit ondertussen op het snelheids nivo van 68k Mototrola in mijn Amiga met all die microcode patched. Of wordt het sneller door al deze patches.?

[Pieter_621]

Bij security patches kan je CPU zeker wat langzamer worden, soms moet daarvoor iets minder optimaal opgelost worden. Maar patches die de processor efficiënter of sneller laten werken zijn ook mogelijk.

[blahenazo]

Overdrijven is op dit eigenste moment verheven naar een kunstvorm.

Mag ik vragen over welke AMD cpu u beschikt ? Zo kan ik in een grote boog rond de cpu lopen.

[MeNTaL_TO]

Ik zou sowieso niet over een CPU lopen als ik jou was, onafhankelijk van het merk. /s

[sfc1971]

Kan nu toch juist nu ze de pinnen naar het moederbord hebben verhuist?

[Sinester]

Je vind dat hij overdrijft, maar neemt hem wel serieus dat je de CPU niet meer zou overwegen

[MrMonkE]

Mag ik vragen over welke AMD cpu u beschikt ?
Zo kan ik in een grote boog rond de cpu lopen.

3900X. Merk er niet zoveel van maar het is natuurlijk ook 'death by a 1000 cuts' dus kun je het niet echt in dagelijks gebruik merken. Je moet echt gaan benchen om het te zien denk ik.

[Amiga3000]

Helaas komen die niet meer in de buurt qua performance, zelfs mijn A3000 niet
Wel jammer dat er van die kant geen concurrentie meer is.

Wat wel zorgelijk is dat blijkbaar javascript zoveel ellende kan aanrichten. En dit is niet de eerste keer.

[Reactie gewijzigd door Amiga3000 op 1 augustus 2024 22:32]

[CyBeR]

Wat wel zorgelijk is dat blijkbaar javascript zoveel ellende kan aanrichten. En dit is niet de eerste keer.

Deze bug vereist dat je heel exact bepaalde CPU instructies gebruikt zodanig dat je een branch prediction miss veroorzaakt op een specifieke instructie, daar komt absoluut geen javascript aan te pas. De PoC is geschreven in C met het werkende deel in assembly.

[Amiga3000]

Ah ik dacht te lezen dat dit ook via javascript te doen was. my bad.

[CriticalHit_NL]

Kon me nog herinneren met die speculative execution exploits bij Intel dat iedereen zoiets had van:
'Intel is aan het cheaten om de benchmarks te winnen blabla.'

En nu is het zover voor AMD, gewoon een algemene manier om taken sneller te kunnen uitvoeren, ze zijn beiden niet heilig en zal dus ook geen keuze voor de CPU hiervan afhankelijk maken.

[locke960]

top level comment ook gelezen? De eerste paragraaf legt haarfijn het verschil uit.

[CriticalHit_NL]

Dat heb ik inderdaad.

Waar de bug in zit, is dat de CPU speculatief instructies uitvoert. Ook al is het nog niet zeker wat de volgende instructie is.

Speculatief dus, met het gokken wat het volgende zal zijn, dat doet Intel net zo goed.
Zoals het artikel ook zelf vermeld:

Speculative execution is een optimalisatiemethode waarbij een cpu bepaalde taken of berekeningen probeert te voorspellen om de processor sneller te maken.

Dat is ook precies wat ik zeg, dat het er is om zaken te proberen te versnellen, iets wat doen bij Intel afgedaan werd door sommigen als cheaten om bovenaan te staan bij de benchmarks.