Intels processorer drabbas av sårbarheten Crosstalk

Permalänk
Medlem
Skrivet av perost:

Att Intel betalar forskare för att hitta buggar i deras processorer medan AMD inte gör det. Vill du tro på konspirationsteorier så får du väl göra det, jag kan inte bevisa att Intel inte finansierar hemlig forskning som specifikt riktar sig mot AMD. Men forskningen som gjorts de senaste åren ser för mig ut att återspegla de båda företagens inställning till buggar ganska bra.

Konspirationsteorier - skulle jag? Har uttryckt i flera svar "intill dess att annat bevisas". Jag fördöker enbart följa det som rapporteras, och det handlar mestadels om Intels processorer - min uppfattning.

Permalänk
Medlem
Skrivet av lillaankan_i_dammen:

Köpte nyss en intel i9-10900K men bryr mig knappt, det är bara inaktivera alla kärnor utan en så man går säker.

Ja det är ju singeltråd som är viktigast, iaf om du frågar userbenchmark

Visa signatur

🛜🫀: HP ProDesk 400 G3, i5 6500, 8GB DDR4, Intel X520-DA2
🐳🐧: AMD R5 3600 | Google Coral.ai | ASRock X570D4U-2L2T | Silverstone CS381 | 80GB DDR4 | 8 HDD BTRFS RAID1
⌨️🎮: R9 3900X | RTX 2080 LC | Acer XF270HUA | 96GB @ 3200 | Prime B350-plus | Carbide 270R
🎞🎶: LG OLED55C8 | Epson TW3200 | Onkyo TX-NR646 | Infinity Reference 61/51 mk2 | Shield TV V2 | minhembio.com

Permalänk
Medlem
Skrivet av Yoshman:

Då även detta hål har en patch så är faktiskt Intel just nu säkrare än AMD då de helt sonika körde strutstaktiken på den enda sårbarhet som så här långt är unik för Zen, TakeAWay. AMD hävdar, mot forskarnas medgivande, att de fixar man har för de andra saker som påverkar deras CPUer är nog.

Kan inte svära att denna PoC fungerar för alla, "fungerar" på min 3900X i alla fall. Verkar som forskarna är de som har rätt här.

Den delen som aldrig kommer fram kring dessa sårbarheter är vad som faktiskt krävs för att man ska utnyttja sårbarheterna utanför en totalt kontrollerad labbmiljö. I princip alla PoC kräver att man är root/admin. "Men de är ju bara PoC!" kan man invända, något som är tekniskt sett korrekt men i praktiken blir det ofta större risk att träffas av en meteorit än att man skulle lyckas utnyttja dessa svagheter i en praktisk miljö.

Orsaken är att dessa svagheter oftast kräver att det som ska attackeras måste läsa/skriva data massor med gånger (något som faktiskt inte gäller i just detta fall!) samtidigt som CPU-frekvens bör hållas väldigt stabil (en sak som kräver root i PoC är så man kan stänga av alla former av turbo). I teorin krävs inget av detta, men det gör då också att mängden brus man som attackerare måste hantera ökar dramatiskt. Vidare fungerar många PoC bara på en viss mikroarkitektur och i vissa fall bara på en specifik modell, det just då timing är så kritiskt (så en fungerade attack måste ta höjd för allt detta).

Vi ser ju i detta fall att Crosstalk fungerar på Skylake S men inte på Skylake SP, det trots att de delar mikroarkitektur men har olika cache-designer och uncore-designer.

Undantaget är ihop med Intels SGX. Detta då hela poängen med SGX är att den ska kunna hålla saker separerade från alla andra delar, även från de som har root/admin och därmed kan köra valfri kod i kärnan.

Så SGX borde vid det här laget vara relativt meningslöst. Har för mig att något av sårbarheterna mot SGX går att hantera med programvara/firmware, men prestandapåverkan är brutal.

Det med råge värsta av alla dessa hål är det första man hittade, Spectre v1. Man har fortfarande ingen aning om hur detta hål kan fixas i HW på ett sätt som inte rejält dödar prestanda, det påverkar alla moderna out-of-order CPUer (vare sig de kör x86, ARM, PPC eller var det nu må vara) och enda sättet att fixa det i programvara är att patcha varje program (de flesta kan patchas central i OS-kärnan, Spectre v1 kan bara delvis patchas så).

Trots det finns det ändå exakt noll kända försök att utnyttja något av alla dessa hål i praktiken. Inte ens Spectre v1 som i teorin kan utnyttjas via JavaScript i webbläsaren (vilket är relativt unikt för dessa hål). Det kanske ger en vink om hur svårt det i praktiken är att använda hålen till något vettigt. Och en annan orsak är ju att det dyker upp åtskilliga CVE med CVSS poäng på >9 (denna har en poäng på 6,5 vilket ändå är rätt högt för en CPU-bugg) i de populära OS-kärnorna varje år, varför krångla med CPU-sårbarheter (kattluckan) när ytterdörren står på vid gavel?

Finns det en patch, för vilka modeller då?

Du skriver avslutningsvis "Trots det finns det ändå exakt noll kända försök att utnyttja något av alla dessa hål i praktiken", men det är väl så att de misslyckade försöken sker i labb-miljö, och de lyckade går därmed inte att registrera.

Permalänk
Medlem
Skrivet av Yoshman:

Då även detta hål har en patch så är faktiskt Intel just nu säkrare än AMD då de helt sonika körde strutstaktiken på den enda sårbarhet som så här långt är unik för Zen, TakeAWay. AMD hävdar, mot forskarnas medgivande, att de fixar man har för de andra saker som påverkar deras CPUer är nog.

Kan inte svära att denna PoC fungerar för alla, "fungerar" på min 3900X i alla fall. Verkar som forskarna är de som har rätt här.

Den delen som aldrig kommer fram kring dessa sårbarheter är vad som faktiskt krävs för att man ska utnyttja sårbarheterna utanför en totalt kontrollerad labbmiljö. I princip alla PoC kräver att man är root/admin. "Men de är ju bara PoC!" kan man invända, något som är tekniskt sett korrekt men i praktiken blir det ofta större risk att träffas av en meteorit än att man skulle lyckas utnyttja dessa svagheter i en praktisk miljö.

Orsaken är att dessa svagheter oftast kräver att det som ska attackeras måste läsa/skriva data massor med gånger (något som faktiskt inte gäller i just detta fall!) samtidigt som CPU-frekvens bör hållas väldigt stabil (en sak som kräver root i PoC är så man kan stänga av alla former av turbo). I teorin krävs inget av detta, men det gör då också att mängden brus man som attackerare måste hantera ökar dramatiskt. Vidare fungerar många PoC bara på en viss mikroarkitektur och i vissa fall bara på en specifik modell, det just då timing är så kritiskt (så en fungerade attack måste ta höjd för allt detta).

Vi ser ju i detta fall att Crosstalk fungerar på Skylake S men inte på Skylake SP, det trots att de delar mikroarkitektur men har olika cache-designer och uncore-designer.

Undantaget är ihop med Intels SGX. Detta då hela poängen med SGX är att den ska kunna hålla saker separerade från alla andra delar, även från de som har root/admin och därmed kan köra valfri kod i kärnan.

Så SGX borde vid det här laget vara relativt meningslöst. Har för mig att något av sårbarheterna mot SGX går att hantera med programvara/firmware, men prestandapåverkan är brutal.

Det med råge värsta av alla dessa hål är det första man hittade, Spectre v1. Man har fortfarande ingen aning om hur detta hål kan fixas i HW på ett sätt som inte rejält dödar prestanda, det påverkar alla moderna out-of-order CPUer (vare sig de kör x86, ARM, PPC eller var det nu må vara) och enda sättet att fixa det i programvara är att patcha varje program (de flesta kan patchas central i OS-kärnan, Spectre v1 kan bara delvis patchas så).

Trots det finns det ändå exakt noll kända försök att utnyttja något av alla dessa hål i praktiken. Inte ens Spectre v1 som i teorin kan utnyttjas via JavaScript i webbläsaren (vilket är relativt unikt för dessa hål). Det kanske ger en vink om hur svårt det i praktiken är att använda hålen till något vettigt. Och en annan orsak är ju att det dyker upp åtskilliga CVE med CVSS poäng på >9 (denna har en poäng på 6,5 vilket ändå är rätt högt för en CPU-bugg) i de populära OS-kärnorna varje år, varför krångla med CPU-sårbarheter (kattluckan) när ytterdörren står på vid gavel?

Stämmer bra med påståendet om OS-kärnor där mitigations/felaktiga implementationer kan komma att bli själva orsaken till att nya hål, potentiella sårbarheter introduceras:

https://phoronix.com/scan.php?page=news_item&px=June-2020-Spe...

Samtidigt kan man ju inte vara säker på att sårbarheter inte utnyttjas, lyckas dem är de guld värda för dem som vill använda sig av dem.
En stor del av poängen, för att sårbarheter/metoder för att utnyttja dem skall vara gångbara under en så lång tid som möjligt, är just att de hålls dolda från allmänheten.
Så antingen finns det inget att frukta ännu, eller så har de hittills lyckats bevara tillvägagångssätten hemligt.

Visa signatur

Tower: ace Battle IV | CPU AMD Phenom II X2 BE unlocked 4cores@3,2GHz | RAM 8GB DDR2@800MHz | MB ASUS M4A785-M | GFK AMD Radeon HD 6850 1GB | HDD Kingston SSD Now 60GB (/) Seagate 2TB(/home) | OS Ubuntu 20.04 LTS
-Numera titulerad: "dator-hipster" då jag har en AMD GPU och dessutom kör Linux.

Permalänk
Medlem

Som några redan har varit inne på så är detta egentligen bara ett problem för serverhallar där flera användare genom virtualisering delar samma hårdvara. Den enda lösningen som jag ser det är att man bygger in en FPGA i processorn så att man kan rekonfigurera processorn rent "fysiskt". Alltså låta FPGA routa trafiken mellan kärnor, cachar, minne och PCIE kanaler. Om jag inte missminner mig så har Intel börjat intressera sig för FPGA, så det kanske inte ligger allt för långt fram i tiden.

Däremot känns Intels mikrokod-fixar till desktopdatorer helt onödiga. Lite som att massvaccinera mot fågelinfluensan, om nu någon kommer ihåg den.

Permalänk
Medlem
Skrivet av tuomi:

Ja det är ju singeltråd som är viktigast, iaf om du frågar userbenchmark

Singelcore hjälper dock inte mot vissa av dessa problem och slå av HT räcker inte heller alltid...

Permalänk
Medlem

De senaste åren har en (hel) del sårbarheter upptäcks och åtgärdats i Intels CPUer.
Ofta har man sett kommentarer att åtgärderna påverkar prestanda
Är det någon som har gjort prestandatester "före och efter"?
Dvs hur presterar en Intel CPU helt utan åtgärder jämfört med en som har alla installerade?

Permalänk
Medlem

För gemene man är detta förmodligen inte så farligt. Men det smetar ju ner Intel's rykte i en tid när de sakta men säkert är på tillbakagång. Klart man gärna pratar om att "sluta fokusera på benchmarks" när patch efter patch gradvis sänker prestanda vilket såklart inte ställer dem i gott ljus.

Visa signatur

ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.
Vet du att du har fel? Signalera detta tydligt med Argumentationsfel och gärna Whataboutism.

Permalänk
Medlem

Risken finns att detta blir som med doping inom idrott. Där är det ett stort dilemma för vissa idrotter att de testar väldigt mycket. Testar man mycket hittar man mycket av dopingen. I idrotter med lite eller ingen testning får man, så klart, väldigt få dopingfall. Folk i allmänhet missar den första delen (att olika idrotter testar väldigt olika mycket), och ser bara vilka idrotter som får många dopingfall, och på så vis får den idrott som jobbar mer med dopingproblemet och förmodligen också är renare, mest skit och sämre rykte. Damned if you do, damned if you don't!

Visa signatur

Moderkort: Gigabyte X570 Aorus Master | CPU: AMD Ryzen R9 5900X | CPU-kylare: Noctua NH-D15 chromax.black | RAM: Corsair Vengeance LPX 64 GB (4x16) DDR4-3600 CL18 | GPU: Gigabyte RTX 4080 Eagle OC | SSD: 2 x Samsung 970 EVO Plus 1 TB NVMe + Kingston A400 480 GB + Samsung QVO860 1 TB | PSU: EVGA SuperNOVA G2 1000 W Gold | Chassi: Lian Li O11 Dynamic XL | Skärm: BenQ PD3200U @ 3840x2160 + ASUS ROG Strix XG32VQ @ 2560x1440 | Tangentbord: Corsair K68 RGB Cherry MX Red | Mus: Logitech MX Master 2S

Permalänk
Medlem

Phoronix har gjort test av RdRand med mitigation.

Länk: https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3-Percent

RdRand har nu bara 3% av sin forna prestanda med den nya mitigation, undrar ifall detta har nån påverkan på spelprestanda i spel likt Destiny 2 som använder sig av rdrand?
Kommer nog inta va kull för datacenter ock liknande, med ett så stort tapp i prestanda.

Permalänk
Datavetare
Skrivet av NutCracker:

Finns det en patch, för vilka modeller då?

Du skriver avslutningsvis "Trots det finns det ändå exakt noll kända försök att utnyttja något av alla dessa hål i praktiken", men det är väl så att de misslyckade försöken sker i labb-miljö, och de lyckade går därmed inte att registrera.

Angående patch, menar du Crosstalk eller Spectre v1? Crosstalk hade ju Intel redan skickat ut en patch för. Spectre variant 1 har ingen en patch i HW, utan där måste man patcha programvaran både i OS och program.

Självklart är det omöjligt att med 100,0 % säkerhet veta att ingen ens försökt, eller till och med lyckas. Men när de mer akuta hålen i OS-kärnorna patchas brukar det också komma med kommentarer om det redan finns lyckade/misslyckade försökt att utnyttja hålet. D.v.s. man är rätt bra på att detektera programvara som försöker utnyttja hål, man har inte hittat något sådan programvara för alla de CPU-buggar som hittats.

För att förstå hur hopplöst det är att utnyttja, testa t.ex. denna. Om du inte har exakt den CPU-modell de testat med + tillräckligt likvärdig OS-miljö kommer det inte fungera då timing är fel. D.v.s. för att kunna utnyttja dessa buggar får du endera rikta in dig på en specifik CPU-modell och ett visst OS (fast där går det rätt bra med "senaste Windows 10").

Så "problemet" med att försöka utnyttja dessa sårbarheter är att det skalar för illa, CPUerna har implicit "flockimmunitet" då det är för få av modeller med tillräckligt samma egenskaper. Jämför det med OS-hålen, de skalar långt bättre då dessa fungerar på alla system som kör "rätt" versionsspann.

Visst kan det tänkas att någon tar fram en supervariant som helt automagiskt autojusterar allt. Brutalt dyrt att utveckla, men kanske inte tekniskt omöjligt. Så nog ändå bäst att patcha system som har kontakt med omvärlden.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av NutCracker:

Ja för vem tusan behöver många kärnor... Min gamla 8088 hade bara en så.., men ändå, det var ju ändå en INTE L. För att inte tala om min Z80, samma med den, en kärna!

Vill man använda alla så kan man ju skifta kärna var dag eller vecka

Problemet löst

Visa signatur

Engineer who prefer thinking out of the box and isn't fishing likes, fishing likes is like fishing proudness for those without ;-)
If U don't like it, bite the dust :D
--
I can Explain it to you, but I can't Understand it for you!

Permalänk
Medlem
Skrivet av perost:

Förutom en enda mening i rapporten som kort nämner att AMD-processorer har samma instruktioner så nämner rapporten ingenting om andra tillverkare än Intel. Det hade varit intressant att veta om det beror på att det bara är Intel-processorer som är sårbara, eller om forskarna helt enkelt inte brytt sig om att undersöka andra processorer. De skriver att de fått betalt av Intel tack vare Intels Bug Bounty-program, men jag kan inte hitta något om att AMD skulle ha ett liknande program.

Skrivet av krigelkorren:

Jamen precis!

Ser att det är av stor vikt, ur säkehetssynpunkt, att man även undersöker och pekar på brister hos konkurrenterna också.
Framför allt då Spectre version ? ju var en av de sårbarheter som faktiskt påverkade CPU:er ur både x86_64 samt ARM plattformar.
Att bara i förbifarten lite löst nämna andra aktörer känns sloppy...

Är det fastställt om så är fallet?
-Och har i så fall andra aktörer också blivit kontaktade/informerade om potentiell sårbarhet, så arbetet med patch är igång hos dem?
Annars blir ju denna sårbarhet likt en "zero-day" för dem... om den är replikerbar men ingen patch finns tillgänglig.

Självfallet så ska alla testas!

Är någon nyfiken/intresserad så finns programmet för test på Github

Visa signatur

Engineer who prefer thinking out of the box and isn't fishing likes, fishing likes is like fishing proudness for those without ;-)
If U don't like it, bite the dust :D
--
I can Explain it to you, but I can't Understand it for you!

Permalänk
Medlem
Skrivet av Bengt-Arne:

Självfallet så ska alla testas!

Är någon nyfiken/intresserad så finns programmet för test på Github

Jag körde rdrand-testet på min 3900X men det segfaultade bara. Tyvärr säger inte det så mycket eftersom koden är skriven specifikt för Intel-processorer, andra processorer kan fortfarande vara sårbara även om inte just det specifika testet fungerar på dem.

Permalänk
Avstängd
Skrivet av ThomasLidstrom:

De senaste åren har en (hel) del sårbarheter upptäcks och åtgärdats i Intels CPUer.
Ofta har man sett kommentarer att åtgärderna påverkar prestanda
Är det någon som har gjort prestandatester "före och efter"?
Dvs hur presterar en Intel CPU helt utan åtgärder jämfört med en som har alla installerade?

Är också ruskigt intresserad av detta. Sitter på en 9600k som börjar kännas lite småseg även @4.9 så undrar vad man missar så att säga.

Permalänk
Medlem

Var det detta Intels VD syftade på tidigare när han gick ut och sade att man inte ska fokusera på benchmark-resultat?

För övrigt är listan över drabbade CPU:er nu tillgänglig här:
https://software.intel.com/security-software-guidance/insight...

Känns i alla fall skönt att min gamla Atom-processor inte kan bli långsammaren än den redan är

Permalänk
Medlem
Skrivet av medbor:

Är det verkligen stackars dom när så extremt många obesläktade hål upptäcks?

Obesläktade? 90% av alla säkerhetshål som rapprterats i Intels processorer på sistone är varianter av samma problem.

Permalänk
Datavetare
Skrivet av perost:

Jag körde rdrand-testet på min 3900X men det segfaultade bara. Tyvärr säger inte det så mycket eftersom koden är skriven specifikt för Intel-processorer, andra processorer kan fortfarande vara sårbara även om inte just det specifika testet fungerar på dem.

Fungerade för mig:

Xeon 2288G (i princip en 9900K)

System: * Operating System: Linux 4.15.0-1079-oem * Processor: Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz * Microarchitecture: Whiskey Lake * Microcode: 0xca * Memory: 31.25 GiB Direct Branch Speculation: * Status: Not Affected * __user pointer sanitization: Disabled Indirect Branch Speculation: * Status: Vulnerable * Retpoline: Disabled * IBPB: Disabled * IBRS: Disabled * STIBP: Disabled * SMEP: Enabled Speculative Store Bypass: * Status: Vulnerable * Speculative Store Bypass Disable: Available Meltdown: * Status: Not Affected * KPTI Present: Yes * KPTI Enabled: No * PCID Accelerated: Yes * PCID Invalidation: Yes L1 Terminal Fault: * Status: Not Affected * L1TF Present: Yes * PTE Inversion: No * SMT: Unaffected * L1d Flush Present: No * L1d Flush: Available Micro-architectural Data Sampling: * Line Fill Buffers (MFBDS): Not Affected * Store Buffers (MSBDS): Not Affected * Load Ports (MLPDS): Not Affected * Uncached Memory (MDSUM): Not Affected * SMT: Unaffected * MD_CLEAR: Not Required

3900X

System: * Operating System: Linux 4.15.0-99-generic * Processor: AMD Ryzen 9 3900X 12-Core Processor * Microarchitecture: Unknown * Microcode: 0x8701013 * Memory: 39.22 GiB Direct Branch Speculation: * Status: Vulnerable * __user pointer sanitization: Disabled Indirect Branch Speculation: * Status: Vulnerable * Retpoline: Disabled * IBPB: Disabled * IBRS: Not Available * STIBP: Disabled * SMEP: Enabled Speculative Store Bypass: * Status: Vulnerable * Speculative Store Bypass Disable: Available Meltdown: * Status: Not Affected * KPTI Present: Yes * KPTI Enabled: No * PCID Accelerated: No * PCID Invalidation: No L1 Terminal Fault: * Status: Not Affected * L1TF Present: Yes * PTE Inversion: No * SMT: Unaffected * L1d Flush Present: No * L1d Flush: Never Micro-architectural Data Sampling: * Line Fill Buffers (MFBDS): Not Affected * Store Buffers (MSBDS): Not Affected * Load Ports (MLPDS): Not Affected * Uncached Memory (MDSUM): Not Affected * SMT: Unaffected * MD_CLEAR: Not Required

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Inaktiv

Hur många är man uppe i idag? Känns som det måste vara iallafall 20+ sårbarheter iallafall. Ser fram emot den dagen Intel får ut något nytt som inte är en Skylake med smink och med säkerhet. Tills dess blir det köp av konkurrenterna, som dessutom erbjuder bättre produkter.

Permalänk
Medlem
Skrivet av Bengt-Arne:

Vill man använda alla så kan man ju skifta kärna var dag eller vecka

Problemet löst

Visst, och har man 8 så kör man 7 på varsin veckodag, bäst presterande på lördagar. Den åttonde får tjäna som reserv om någon av de övriga bränner ut sig. Gäller nu bara att man stänger av hyper-threading så det inte blir för modernt(och sårbart), samt väljer lämpliga spel, såsom exempelvis Tetris.

Permalänk
Medlem

@Yoshman: Det där är deras gamla testverkyg, det nya RDRAND-testet hittar du i pocs (kör make där, sen runme.sh i rdrand).

Permalänk
Medlem
Skrivet av Erik_T:

Obesläktade? 90% av alla säkerhetshål som rapprterats i Intels processorer på sistone är varianter av samma problem.

En hel del av dom är såklart baserat på ett stort kärn-problem, men det kan ju utnyttjas på så många sätt att jag nästan kan garantera att detta var något de visste om eller åtminstone fått flaggat av en ingengör i något stadium och avfärdat som icke-realistiskt eller något sånt.

Det är INTE synd om Intel dock, detta är helt deras eget fel och något som borde kunnat lösas långt innan det hann bli så här illa. Alla deras processorer från senaste decenniet är ju drabbade i någon utsträckning. Det är ingen annans fel än deras eget

Permalänk
Medlem
Skrivet av ronnylov:

Är AMD verkligen så mycket säkrare eller är det bara att man inte får höra så mycket om deras buggar?

Har väl gjorts försök med samma tillvägagångssätt mot AMDs processorer? Många av problemen har inte kunnat replikeras på AMD produkter så som "Meltdown" eller "Fallout" t.ex. Vill även minnas att vissa former av Spectre är AMD känsliga mot medan andra former är de säkrare än Intel.

Skrivet av superegg:

Nu igen den är lika vattentät som Titanic.

Och en fix för detta kommer säkert skänka prestanda som vanligt.

Titanic var ju vattensäkert.. fram tills ett ont isberg bestämde sig för att förstöra festen.

Skrivet av perost:

Intel har sitt Bug Bounty-program och ger ut belöningar på upp till $100 000 för kritiska säkerhetshål som hittas i deras hårdvara. Jag kan inte hitta någon information alls om att AMD har något liknande program. För sårbarheten som denna tråd handlar om så har t.ex. forskarna samarbetat med Intel, men nämner inte ens om de tror att AMD är sårbara eller ej.

Det är ett ganska enormt hopp mellan att Intel ger pengar till de som kan finna säkerhetshål hos deras processorer till att AMD på något sätt skulle ha samma problem men att det skulle "tystas ned". Framförallt när det inte är allt för sällan oberoende institut som finner dessa och publicerar dem efter god sed.

Skrivet av ronnylov:

Tror inte de lägger massor av pengar på att hjälpa konkurrenten att hitta deras buggar.
Om de har buggar är det bra att de hittas. Men så klart är det dåligt att de har många buggar.
Men visst det kan också vara så att AMD har färre buggar och det är därför de inte hittas.
Alternativt har de också många buggar men man har inte hittat dem.
Eller så löser man buggarna själva utan att hela världen får veta det.

Eller... Så har AMD den bästa produkten i mannaminne när det kommer till säkerhetshål. Det är många Om och men i din kommentar.

Skrivet av Woaini:

Ok.

Behöver jag som privat gamer göra något, eller tänka på något utifrån detta?

Med största sannolikhet ingenting.

Skrivet av Chrisj:

Att det finns stora pengar i att hitta buggar i Intels hårdvara medans motsvarande initiativ för att leta hål hos AMD inte finns, i alla fall inte i någon öppen kanal.

Jag gissar att det är två saker. AMD har en nyare arkitektur som de jobbar med som mycket väl kan vara säkrare, men i likhet med virus på Win vs Mac så är incitamentet att hitta hål hos Intel mycket större då de inte bara själva betalar för det utan även på grund av att deras produkter utgör en större marknadsandel.

Men detta "Intel är större och därför hittas fler säkerhetshål" är ju en klyscha som är oerhört utdaterad. Framförallt när AMD inom vissa segment har hela 40% av marknaden.

https://www.techradar.com/news/amd-now-has-40-of-processor-ma...

Detta kan jämföras med närmare 80% som använder windows.

https://gs.statcounter.com/os-market-share/desktop/worldwide

Visa signatur

Fractal Design Meshify 2 Compact w/ Dark Tint | Intel i5 12600K | Asus ROG Strix B660-F | 32 GB Corsair DDR5 5600 MHz CL36 | MSI Geforce RTX 3060 TI Ventus 2X OCV1 | 512 GB Samsung Pro 850 SSD + 2TB WD Black SN850 NVME PCI-E 4.0 | Corsair RM750X |

Permalänk
Datavetare
Skrivet av Ozzed:

För gemene man är detta förmodligen inte så farligt. Men det smetar ju ner Intel's rykte i en tid när de sakta men säkert är på tillbakagång. Klart man gärna pratar om att "sluta fokusera på benchmarks" när patch efter patch gradvis sänker prestanda vilket såklart inte ställer dem i gott ljus.

Vilket tycker du är värst:

Intel har ett program som gör att forskare som hittar buggar med något rimligt frekvens och kritikalitet får ett betydande tillskott till finansiering av sitt forskande. Majoriteten av alla buggar har ju inte hittats av Intel utan just av externa forskare. Alla buggar som så här långt hittats har någon form av patch.

AMD har inget motsvarande program, hur mycket resurser de lägger internt på detta vet vi inte. Det finns totalt 5 säkerhetshål som är unika för AMDs CPU-plattform just nu, av dessa finns så vitt jag vet patchar för en!

3 av dessa är de som CTS Labs hittade (eller om de nu blev mutade av Intel, på Reddit debatteras nog det ännu), där lovades en patch kort efter men kan inte hitta patchen någonsin släpptes.

Den sista är TakeAWay där AMD hävdar att det inte finns något problem, det trots att just detta problem är en av de enklaste att skriva en fungerade PoC. Förmildrande omständigheten här är att man (som attacker) har väldigt dålig kontroll på vad som läcks.

Vidare har Intel faktiskt patcha det mesta. Kolla i utskrifterna jag gjorde ovan från 3900X och E-2288G, Intel har patchat de flesta MDS (bl.a. genom att slå av saker som TSX och SGX), men även patchat Meltdown samt Direct Branch Speculation. AMD är också mottagliga för Direct Branch Speculation men har inte patchat än.

Vidare är båda mottagliga för Indirect Branch Speculation och Speculative Store Bypass, fast dessa kan båda patchas i OS.

Nu är jag fortfarande övertygad om att dessa sårbarheter är, i de flesta fall, inte praktiskt användbara. Så är inte precis nervös att köra vare sig 3900X eller E-2288G. Men skulle ändå säga att givet ovan skulle säga att AMD har en del att putsa på när det kommer till deras säkerhetsarbete, de som vara väldigt glad att ena mikroarkitekturspecifika man hittar där (så här långt) är TakeAWay. Vore faktiskt väldigt märkligt om inte AMD, Apple och ARM alla har sina egna motsvarigheter av MDS. De sårbarheterna är ju extremt bundna till mikroarkitektur, ofta fungerar de bara på en specifik modell (Sunny Cove verkar t.ex. inte mottaglig för de i dag kända MDS buggarna).

Skrivet av perost:

@Yoshman: Det där är deras gamla testverkyg, det nya RDRAND-testet hittar du i pocs (kör make där, sen runme.sh i rdrand).

I see!

Om du får seg-fault beror det på att du inte allokerade några "huge-pages" innan du startade programmet, står i README.md

echo 16 | sudo tee /proc/sys/vm/nr_hugepages

Men det hjälper inte speciellt mycket. Precis som alla andra MDS PoC kräver dessa stöd för TSX (Transactional Synchronization Extensions). Utan TSX är det i princip helt hopplöst att generera undantag med tillräckligt precision och frekvens för att göra något vettigt med MDS-buggarna.

TSX finns inte på Zen och det är i borttaget från de flesta (alla?) aktuella Intel-modeller. Hade för mig att att TSX instruktionerna är kodade så att de tolkas som "rep nop" (repetera nästkommande instruktion motsvarande värdet i cx, som i detta fall är "gör inget") vilket verkar stämma på E-2288G maskinen men får "Illegal instruction" på 3900X här

// STEP ONE: We write a value inside a TSX transaction, which aborts. => asm volatile("xbegin abort1\n":::"rax"); for (unsigned int n = 0; n < 1024; ++n) { // should ideally be >=56 I guess? *(volatile unsigned char *)(privatebuf + (0x40*n) + VICTIM_OFFSET) = SECRET_VALUE /*+ (n & 0x3f)*/; } // force abort

D.v.s. PoC är idag helt värdelös, även på Intel-maskiner då TSX i praktiken är borttaget.

Lite off-topic:
TSX är en sådan sak som såg riktigt bra ut i forskningspapper (man har forskat på detta i årtionden och forskar än), men det har aldrig används speciellt mycket då det i praktiken nästan alltid finns mer effektiva sätt att lösa synkronisering. I teorin finns ändå poänger med transactional memory, t.ex. i databashantering, så hoppas man får ordning på just den här tekniken tids nog! Att det knappt används gjorde det hyfsat enkelt val för Intel att bara slå av TSX när MDS blev känt.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av NutCracker:

Ja för vem tusan behöver många kärnor... Min gamla 8088 hade bara en så.., men ändå, det var ju ändå en INTE L. För att inte tala om min Z80, samma med den, en kärna!

Z80 - en processor som man verkligen får tänka efter vad man gör så att man inte skjuter ner systemet. Samma med 8088.

Lärde mig C-programmering på MS-DOS. Det var lärorikt. Gör man fel kraschar systemet.

Permalänk
Medlem
Skrivet av Xinpei:

Har väl gjorts försök med samma tillvägagångssätt mot AMDs processorer? Många av problemen har inte kunnat replikeras på AMD produkter så som "Meltdown" eller "Fallout" t.ex. Vill även minnas att vissa former av Spectre är AMD känsliga mot medan andra former är de säkrare än Intel.

Titanic var ju vattensäkert.. fram tills ett ont isberg bestämde sig för att förstöra festen.

Det är ett ganska enormt hopp mellan att Intel ger pengar till de som kan finna säkerhetshål hos deras processorer till att AMD på något sätt skulle ha samma problem men att det skulle "tystas ned". Framförallt när det inte är allt för sällan oberoende institut som finner dessa och publicerar dem efter god sed.

Eller... Så har AMD den bästa produkten i mannaminne när det kommer till säkerhetshål. Det är många Om och men i din kommentar.

Med största sannolikhet ingenting.

Men detta "Intel är större och därför hittas fler säkerhetshål" är ju en klyscha som är oerhört utdaterad. Framförallt när AMD inom vissa segment har hela 40% av marknaden.

https://www.techradar.com/news/amd-now-has-40-of-processor-ma...

Detta kan jämföras med närmare 80% som använder windows.

https://gs.statcounter.com/os-market-share/desktop/worldwide

Bland det jag skrev: "Men visst det kan också vara så att AMD har färre buggar och det är därför de inte hittas"

He he, jag tror jag hade med alternativet att AMD har bästa produkten bland alla om och men. Jag hoppas verkligen AMD har bästa produkten. Funderar på att uppgradera min Ryzen 7 1700 kanske till en 3700X då det funkar utan att byta moderkort.

Edit: Tänker lite som Yoshman att det är bättre att försöka hitta buggarna om de finns och misstänker intel har mera resurser för sådant. Men förhoppningsvis går AMD fortsatt bra ekonomiskt och kan få in pengar till att förbättra detta om det nu skulle behövas.

Permalänk
Medlem
Skrivet av Xinpei:

Men detta "Intel är större och därför hittas fler säkerhetshål" är ju en klyscha som är oerhört utdaterad. Framförallt när AMD inom vissa segment har hela 40% av marknaden.

https://www.techradar.com/news/amd-now-has-40-of-processor-ma...

Detta kan jämföras med närmare 80% som använder windows.

https://gs.statcounter.com/os-market-share/desktop/worldwide

Tittade du ens på Passmark kartorna som du själv länkade? Overall så har intel varit över 70% i mer än 10 år fram till Q3 2019, så det har inte ens gått ett år ännu där de varit under 70%. Tittar man sedan på Server där de flesta av dessa attacker faktiskt är användbara (du lär sällan sitta på en virtuell användare och dela cpu på någons desktopdator) så är Inteldominansen med 98.2% större än windowsdominansen du hävdar inte ens skulle vara jämförbar.

På laptopsidan har inte Intel varit under 80% sedan 2012 och är fortfarande över 80%. Som artikeln rentav anmärker i rubriken så har AMD nått 40% i vissa segment för första gången på 14 år. Det i kombination med faktumet att Intel faktiskt finansierar extern buggsökning vilket AMD inte gör bidrar självklart till att fler buggar hittas på Intels sida, precis som det skapas mer elakartad kod som riktar sig mot Windows än OSX. Det är helt enkelt större incitament.

Permalänk
Medlem
Skrivet av Yoshman:

Vilket tycker du är värst:

Intel har ett program som gör att forskare som hittar buggar med något rimligt frekvens och kritikalitet får ett betydande tillskott till finansiering av sitt forskande. Majoriteten av alla buggar har ju inte hittats av Intel utan just av externa forskare. Alla buggar som så här långt hittats har någon form av patch.

AMD har inget motsvarande program, hur mycket resurser de lägger internt på detta vet vi inte. Det finns totalt 5 säkerhetshål som är unika för AMDs CPU-plattform just nu, av dessa finns så vitt jag vet patchar för en!

3 av dessa är de som CTS Labs hittade (eller om de nu blev mutade av Intel, på Reddit debatteras nog det ännu), där lovades en patch kort efter men kan inte hitta patchen någonsin släpptes.

Den sista är TakeAWay där AMD hävdar att det inte finns något problem, det trots att just detta problem är en av de enklaste att skriva en fungerade PoC. Förmildrande omständigheten här är att man (som attacker) har väldigt dålig kontroll på vad som läcks.

Vidare har Intel faktiskt patcha det mesta. Kolla i utskrifterna jag gjorde ovan från 3900X och E-2288G, Intel har patchat de flesta MDS (bl.a. genom att slå av saker som TSX och SGX), men även patchat Meltdown samt Direct Branch Speculation. AMD är också mottagliga för Direct Branch Speculation men har inte patchat än.

Vidare är båda mottagliga för Indirect Branch Speculation och Speculative Store Bypass, fast dessa kan båda patchas i OS.

Nu är jag fortfarande övertygad om att dessa sårbarheter är, i de flesta fall, inte praktiskt användbara. Så är inte precis nervös att köra vare sig 3900X eller E-2288G. Men skulle ändå säga att givet ovan skulle säga att AMD har en del att putsa på när det kommer till deras säkerhetsarbete, de som vara väldigt glad att ena mikroarkitekturspecifika man hittar där (så här långt) är TakeAWay. Vore faktiskt väldigt märkligt om inte AMD, Apple och ARM alla har sina egna motsvarigheter av MDS. De sårbarheterna är ju extremt bundna till mikroarkitektur, ofta fungerar de bara på en specifik modell (Sunny Cove verkar t.ex. inte mottaglig för de i dag kända MDS buggarna).

Värst av vad? Att i praktiken betala forskare för att svärta ner ens rykte (eftersom ens PR-avdelning är så dålig på att kommunicera att det är man själv som sponsrat forskningen så praktiskt taget ingen vet om det), eller att inte betala forskare för att i praktiken svärta ner ens rykte

Nej men skämt åsido så hade det här kunnat vändas till Intel's fördel. Deras PR-avdelning har verkligen skött det katastrofdåligt. Klart det är jättebra om man har sådan tillit till sina produkter att man betalar forskare för att hitta säkerhetshål. Men affärsmässigt är det idioti att inte vara tydlig med det.

Jag tror inte Intel har mutat någon för att jaga säkerhetsbrister hos AMD. AMD är för små för att vara ett hot mot Intel just nu. Det är inte som det var på Paul Otellinis tid. Även om man tog bort hela Intel's desktop och laptop-division så skulle de fortfarande vara bra mycket större än AMD, så sådant där är bara trams. Men Reddit will be Reddut, antar jag

Visa signatur

ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.
Vet du att du har fel? Signalera detta tydligt med Argumentationsfel och gärna Whataboutism.

Permalänk
Avstängd
Skrivet av Xinpei:

Titanic var ju vattensäkert.. fram tills ett ont isberg bestämde sig för att förstöra festen.

Intel CPU var med säkert tills onda forskare hittade säkerhetshålen.

Visa signatur

Man är inte dum för att man har stavproblem.
Läs mer om min synfel Visual Snow
Om mig ----> #16970666

Permalänk
Medlem
Skrivet av ehsnils:

Z80 - en processor som man verkligen får tänka efter vad man gör så att man inte skjuter ner systemet. Samma med 8088.

Lärde mig C-programmering på MS-DOS. Det var lärorikt. Gör man fel kraschar systemet.

Vi i det gamla gardet, det har onekligen hänt en del;) För de flesta var det väl B(asic)-programmering eller maskinkod på Z80, C & assembler sen iom MS-DOS och intel-processorerna.