AMD: "Våra processorer påverkas inte av Intels MDS-sårbarheter"

Permalänk
Medlem
Skrivet av Yoshman:

Finns redan andra former av attacker mot SMT, som likt Spectre, går mot själva huvudpunkten med tekniken: vilket för SMT är att dela HW mellan trådar.

Med undantag för Bulldozer-serien (som även den rent tekniskt är en form av SMT) så delar alla SMT implementationer jag känner till ALUs mellan trådar -> ger en side-channel för någon som kan säkerställa att det man vill attackera går på ena CPU-tråden och programmet attacken utförs från går på den andra CPU-kärnan.

Denna rapport beskriver en sådan typ av attack

"Abstract—Simultaneous Multithreading (SMT) architecturesare attractive targets for side-channel enabled attackers, withtheir inherently broader attack surface that exposes more perphysical core microarchitecture components than cross-core at-tacks. In this work, we explore SMT execution engine sharingas a side-channel leakage source"

Tittar man i bilden över Zen i PDF-dokumentet länkat i denna artikel ser man att Zen, precis som Core-serien, har ALUs som "Competitively shared structures" utan någon form av taggning.

Om någon tvivlar kan de provköra PoC för PortSmash. På Zen är numreringen för trådar och processen att låsa frekvensen annorlunda jämfört med på Intel, så man måste fixa till de delarna manuellt i "freq.sh" skriptet för att matcha Zen.

Vidare är mappningen mellan vilka instruktioner som går till vilka pipelines annorlunda i Zen. För den som riktigt vill gräva ner sig finns mappningen här för aktuella x86 CPUer. Men fallet "PORTSMASH_P0156" (se spy.h samt spy.S filerna) råkar i praktiken ha identisk mappning på Zen och Haswell/Broadwell/Skylake.

Och kör man detta på ett Zen-system på två trådar men samma CPU ser man helt klart en signal -> fungerande side-channel.

I praktiken är detta ändå ett icke-problem. Kraven är som i princip alla dessa sårbarheter

  • den som attackerar måste redan vara inne i ditt system då attack-programmet har rätt specifika krav (dock räcker det att vara "vanlig" användare)

  • man måste få attack-programmet och programmet som attackeras att köra på samma CPU-kärna. Som "vanlig" användare kan man enkelt låsa attack-programmet på en specifik CPU-tråd, men Windows, Linux och MacOS kommer alla föredra att inte köra något på den andra CPU-tråden om det finns kärnor som är "idle". Som "vanlig" användare kan man bara låsa "sina" program till specifika kärnor -> rätt rejäl barriär (ungefär i nivå med att ta sig i på datorn till att börja med)

  • i dessa PoC är ju det program som ska attackeras rätt ordentligt tillrättalagt i att man vet exakt när det jobbar med den data man vill stjäla, det kan ibland vara möjligt även i praktiken, men ofta inte

Dessa attacker är ändå ett reellt i fallet där man kör virtuella maskiner på molntjänster där andra användare kan dela HW. Det är normalt sett INTE ett problem på desktop-maskiner eller ens på molntjänster där man enbart nyttjar en tjänst och inte har möjlighet att köra valfritt program på servern.

Har Intel en större attack-yta mot sin SMT implementation? Absolut (p.g.a. av att de helt fritt delar fler saker mellan trådar, Zen har hårdare separation av vissa delade resurser)!
Men SMT lider "by-design" av side-channel problem likt hur "out-of-order" CPUer "by-design" lider av Spectre. Så de som har åskikten att det måste vara 100 % säkert: köp en RPi3 och surfa därifrån. Är en av de få moderna CPU-designer som varken har SMT eller problem med Spectre (men lär garanterat finns hål även i Cortex A53...)

I många användarfall är dessa svagheter ett långt mindre problem jämfört med prestandaförlusten att inte använda teknikerna. I fall där svagheterna är allt för stora finns HW både utan SMT och utan "out-of-order execution". Rätt sak på rätt plats!

Tack, Yohsman! Jag uppskattar verkligen hur du tar dig tid och förklarar grundligt men också pedagogiskt trots att det är väldigt invecklade saker det handlar om. Jag gissar på att du arbetar som lärare på universitet och är lite arbetsskadad?

Jag vet inte om du vare sig har tid eller lust, men jag tror det skulle vara väldigt uppskattat om du kunde skriva något som Swec gärna lyfter upp till förstasidan när det rapporteras om något sånt här. En artikel där du beskriver problemet på ett väldigt förenklat sätt och sedan översätter likt slutet i den här tråden - hur rimligt är det att kreti & pleti drabbas?

Du finns ofta i trådar, ofta när det gäller programmering och procesorarkitekturer och förklarar - men ibland blir det fyra-fem sidor och det är synd om din kunskap skulle gå förlorad känner jag.

/Yoshman-fan

Visa signatur

..:: trickeh2k ::..
Windows 11 Pro - Ryzen 7 7800X3D - ASUS TUF B650-PLUS - Kingston FURY Beast DDR5 64GB CL36 - MSI MAG A850GL - MSI RTX 4080 VENTUS 3X OC - Acer Predator XB271HU - ASUS VG248QE - QPAD MK-85 (MX-Brown)/Logitech G PRO Wireless - Samsung 960 EVO 250GB, Samsung EVO 860 500GB, SanDisk Ultra II 480GB, Crucial MX500 1TB, Kingston KC3000 2TB - Steelseries Arctic 5 - Cooler Master Masterbox TD500 Mesh V2

Permalänk
Medlem

@Yoshman: Här är en video jag tyckte var intressant om lite olika sätt man kan minska säkerhetsriskerna i olika scenarion:

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Permalänk
Medlem
Skrivet av anon159643:

Och vanliga användare använder molntjänster idag. ... Så vanliga tekniska användare drabbas och ytterst få sitter med rena AMD prylar.

Visst att många arbetar mot molntjänster, men attacken riktas bara mot klientens data (när den behandlas av servern i molnet) och inte mot klientens hårdvara.
Spelar i sammanhanget ingen roll alls vad du som klient använder för hårdvara!

Permalänk
Medlem

Skulle det gå att låsa flertrådad körning till ett program per fysisk kärna? I de flesta fall, undantaget på servernivå, lär ju bara ett fåtal program köras samtidigt. Om jag vill köra t ex blender med maximal prestanda från processorn föreligger ingen säkerhetsrisk om blender får dela fysisk processor i flera trådar. Men ett annat program, även om det bara kan använda en tråd, får bara använda en fysisk kärna i det fallet. Lite slösaktigt, men lär knappast påverka prestanda där behovet är störst.

Skickades från m.sweclockers.com

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
Skrivet av anon159643:

Du menar väl sluta använda datorer och gå tillbaka till skrivare och papper som man kan lita på?
Detta med att jobba lokalt fungerade förr när man jobbade med små saker som man bara hade för sig själv. När det blir fler personer som behöver dela på samma saker där alla inte ens sitter i samma land, så fungerar inte metoden att lagra allt lokalt så bra längre.

Ur datasäkerhetssynpunkt är ofta lagra lokalt lika med väldigt dåligt, för man kan bli utsatt för stöld eller olyckor.

Ge alla en lokal dator, lokal skrivare och lokal skanner med OCR
*Problem fixed*

Det går ju dock att begränsa hur "moln-baserad" man är. Allt måste inte vara papper, och allt måste inte vara en automagisk knapp där all din data bara magiskt "hamnar någonstans". Detta är ju felet Intel har gjort... man skulle ha max prestanda, oavsett kostnad. Och folks arbetssätt behöver faktiskt gå tillbaka ca 5 år i utveckling, nu när säkerhet är ett problem. I grunden är det samma fel-tänk som skapat dessa problem, och man behöver inse begränsningarna.

Sen om du hellre vill ringa Google/MS osv och be dem om en backup på de dokument du skickade i hemlighet till vårdcentralen är väl upp till dig. Men lite "tanke" bakom konsekvenserna behövs verkligen på moln-sidan också.

Permalänk
Medlem
Skrivet av Paddanx:

Ge alla en lokal dator, lokal skrivare och lokal skanner med OCR
*Problem fixed*

Det går ju dock att begränsa hur "moln-baserad" man är. Allt måste inte vara papper, och allt måste inte vara en automagisk knapp där all din data bara magiskt "hamnar någonstans". Detta är ju felet Intel har gjort... man skulle ha max prestanda, oavsett kostnad. Och folks arbetssätt behöver faktiskt gå tillbaka ca 5 år i utveckling, nu när säkerhet är ett problem. I grunden är det samma fel-tänk som skapat dessa problem, och man behöver inse begränsningarna.

Sen om du hellre vill ringa Google/MS osv och be dem om en backup på de dokument du skickade i hemlighet till vårdcentralen är väl upp till dig. Men lite "tanke" bakom konsekvenserna behövs verkligen på moln-sidan också.

Feltänket verkar främst vara att man utgått ifrån att processorn jobbar i en låst liten låda, vilket den i princip gör. Problemet är att om man knackar på lådan kan man avgöra om den är ihålig eller inte.

Det tycks, i ytterst förenklad form, vara grunden till problemet. Speculative prediction, SMT och vissa x86-anrop tycks vara vad som på lite olika vis gör detta möjligt.

Det är fortfarande lite för komplicerat för att jag ska ha en bra förståelse för det (jobbar på det) men narrativet att Intel försökt kompromissa säkerhet för prestanda finns det egentligen inget som tyder på.

Snarare verkar det som att Intels sätt att göra det på skapat fler attackytor. I princip är ju inte AMD och (vissa) ARM förskonade heller, men det har inte blivit lika illa för dem.

Jag tror ju då att när Intel blev varse om detta sket de närmast på sig.

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av DasIch:

Feltänket verkar främst vara att man utgått ifrån att processorn jobbar i en låst liten låda, vilket den i princip gör. Problemet är att om man knackar på lådan kan man avgöra om den är ihålig eller inte.

Med tanke på 17:e Maj, får vi väl jämföra det med att sänka en Norsk U-båt... genom att knacka på skjutdörren

Skrivet av DasIch:

Det tycks, i ytterst förenklad form, vara grunden till problemet. Speculative prediction, SMT och vissa x86-anrop tycks vara vad som på lite olika vis gör detta möjligt.

Det är fortfarande lite för komplicerat för att jag ska ha en bra förståelse för det (jobbar på det) men narrativet att Intel försökt kompromissa säkerhet för prestanda finns det egentligen inget som tyder på.

Mja, jag håller inte med.
Intel har valt att anta att koden som kommer är säkrad. De har valt att lägga till denna spekulativa gissning (som ger en stor del av hålen) för att få upp prestandan. Och de har valt att göra det utan att titta på hur och om detta kan missbrukas. Det är lite som att kassören gissar ditt kortnummer och pinkod högt ut i luften åt dig när du kommer fram i kassan från en lång lista av kortnummer. Ja, det kommer snabba upp det för lite då och då får de rätt gissning, men hur bra är detta tänkt ur säkerhet? I båda fallen är det som att totalt ignorera säkerheten, och anta att ingen förutom kassörskan får tag i dessa kortnummer, någonsin.

Och detta är inte första gången Intels genomtänkta system haft problem. Intels Management Engine har ju också haft rätt stora hål i sig. Deras Thunderbolt har i sig också buggar som är illa:
https://appleinsider.com/articles/19/02/27/thunderbolt-3-thun...
"Practically all hardware with some form of Thunderbolt connection is affected, including those with USB Type-C ports and those with older Mini DisplayPort connections." *suck*

Skrivet av DasIch:

Snarare verkar det som att Intels sätt att göra det på skapat fler attackytor. I princip är ju inte AMD och (vissa) ARM förskonade heller, men det har inte blivit lika illa för dem.

Helt säkra kan inget system vara. Men AMD gör trots allt kontroller på att se om du ska få tillgång till data utanför din nivå. Just detta tänket att man inte antar att lådans ytterkant är enda skyddet, utan har fler nivåer av skydd, som i sin tur själ prestanda så klart, är tydligt tecken på att de tänkte olika prioriteringar. Och jag är övertygad om att både AMD och ARM har pga deras designer är "nyare" än Intels, haft mer säkerhets tänk bakom designen än Intel. (De har lärt sig av marknadens problem med säkerhet mao)

Är eg inte så konstigt då oavsett hur fin 14nm noden är, så är allt som Intel säljer på den, idag, baserat på samma grundläggande SMT som första Nehalem kom med. Intel behöver mao, ny design.

Skrivet av DasIch:

Jag tror ju då att när Intel blev varse om detta sket de närmast på sig.

Skickades från m.sweclockers.com

Heh... mjo, tror det med.
Självklart ville de inte se detta... i grund o botten har det ju gjort deras HT närmast värdelös.

Permalänk
Medlem
Skrivet av Paddanx:

Med tanke på 17:e Maj, får vi väl jämföra det med att sänka en Norsk U-båt... genom att knacka på skjutdörren

Mja, jag håller inte med.
Intel har valt att anta att koden som kommer är säkrad. De har valt att lägga till denna spekulativa gissning (som ger en stor del av hålen) för att få upp prestandan. Och de har valt att göra det utan att titta på hur och om detta kan missbrukas. Det är lite som att kassören gissar ditt kortnummer och pinkod högt ut i luften åt dig när du kommer fram i kassan från en lång lista av kortnummer. Ja, det kommer snabba upp det för lite då och då får de rätt gissning, men hur bra är detta tänkt ur säkerhet? I båda fallen är det som att totalt ignorera säkerheten, och anta att ingen förutom kassörskan får tag i dessa kortnummer, någonsin.

Och detta är inte första gången Intels genomtänkta system haft problem. Intels Management Engine har ju också haft rätt stora hål i sig. Deras Thunderbolt har i sig också buggar som är illa:
https://appleinsider.com/articles/19/02/27/thunderbolt-3-thun...
"Practically all hardware with some form of Thunderbolt connection is affected, including those with USB Type-C ports and those with older Mini DisplayPort connections." *suck*

Helt säkra kan inget system vara. Men AMD gör trots allt kontroller på att se om du ska få tillgång till data utanför din nivå. Just detta tänket att man inte antar att lådans ytterkant är enda skyddet, utan har fler nivåer av skydd, som i sin tur själ prestanda så klart, är tydligt tecken på att de tänkte olika prioriteringar. Och jag är övertygad om att både AMD och ARM har pga deras designer är "nyare" än Intels, haft mer säkerhets tänk bakom designen än Intel. (De har lärt sig av marknadens problem med säkerhet mao)

Är eg inte så konstigt då oavsett hur fin 14nm noden är, så är allt som Intel säljer på den, idag, baserat på samma grundläggande SMT som första Nehalem kom med. Intel behöver mao, ny design.

Heh... mjo, tror det med.
Självklart ville de inte se detta... i grund o botten har det ju gjort deras HT närmast värdelös.

Det där låter som hittepå och en direkt vilseledande jämförelse.
Intel har definitivt gjort bort sig men inte genom att göra ett så uppenbart felaktigt antagande.

Jag tror något i den här stilen är en mer rättvis liknelse för den övergripande problemställningen:

Du har en telefonist i kundtjänst som behandlar flera samtal parallellt och hoppar lite fram och tillbaka mellan dessa, de olika samtalen är dock helt separerade så att inga andra hör varandras samtal och telefonisten säger ALDRIG vad de sagt/hört i något av sina andra samtal. Däremot svarar telefonisten av sin natur lite snabbare om de just funderat på samma sak, oavsett vilket samtal som fick dem att fundera på detta.

Misstaget Intel gjorde verkar ju ha varit att tänka att den faktiska konsekvensen av detta är minimal och knappast kan utnyttjas i praktiken.
Men sedan kom någon och sa att "jag har funnit att jag kan ta reda på vad som helst om vilket annat samtal som helst genom att analysera hur snabbt telefonisten svarar på mina frågor, hur tänkte ni nu?" och hela datorindustrin skrek till i panik, för alla tillverkarna av högpresterande processorer hade gått i samma fälla i någon utsträckning. Intel hade dock gått extra mycket i den fällan (alternativt har deras arkitektur bara blivit mest granskad).

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Datavetare
Skrivet av Paddanx:

Mja, jag håller inte med.
Intel har valt att anta att koden som kommer är säkrad. De har valt att lägga till denna spekulativa gissning (som ger en stor del av hålen) för att få upp prestandan

De har inte antagit att koden alltid är säkrad. Sett ur ett ISA-perspektiv är Intels CPUer helt korrekta, de säkerställer att CPUn aldrig ändrar arkitekturmässigt tillstånd på ett sätt som inte ska vara tillåtet.

Skrivet av Paddanx:

Och de har valt att göra det utan att titta på hur och om detta kan missbrukas.

Här är vad Intel av alla att döma har fler hål än t.ex. Zen och ARMs Cortex serie. Är i alla fall definitivt så att man så här långt hittat fler hål hos Intel här.

Men observera att båda de senare har även de just den här typen av problem. Spectre attackerar en extremt bred typ av designer, alla designer som bygger på Tomasulo algoritmen då denna är grunden för alla "out-of-order" designer vi har idag.

Så här långt har ingen kommit på ett sätt att fixa dessa hål på HW-nivå utan att få brutal negativ påverkan på prestanda (ARM tillverkar ju fortfarande "in-order" CPUer som är immuna mot Spectre då de inte använder spekulering). Kanske knäcker man den nöten, men om man inte gör det måste man väga värdet av högre prestanda mot risken att man kan utnyttja hålet

Som referens här kan nämna att vi fortfarande står på noll försök att utnyttja Spectre/Meltdown i malware. En av de mer önskade nyheterna i nästa Linux-kärnan är en global kill-switch för alla motmedel för dessa. Efter paniken har lagt sig har allt fler insett att kraven för att överhuvudtaget kunna utnyttja dessa defekter finns inte på en stor andel av systemen.

Man tar en risk varje gång man sätter sig i en bil eller ens går ut, vem vet var nästa meteorit eller blix slår ned? Men ändå utsätter vi oss för potentiellt dödliga risker, vi gör det för att vinst kontra potentiell risk väger över så brutalt mot vinsten!

SMT är precis som "out-of-order execution" ett annat exempel på teknik där det finns inbyggda säkerhetsrisker med tekniken (något som varit känt ända sedan teknikens vagga på slutet av 1960-talet). Men för en förkrossande majoritet överväger vinsten i prestanda ökning i risk.

I fallet HT har Intel gjort en miss i att inte tagga data man jobbar med i den spekulativa delen med tråd ID, det har AMD gjort. Det är absolut en miss och AMD ska ge sig själva en klapp på axeln för att de löst detta på ett korrekt sätt.

Men är inte så att AMD gjort den enda korrekt lösningen. Tror själv på en variant av fall två i videon @wowsers postade ovan. En lysande lösning både mot MDS och potentiellt även mot Spectre är att ta en snapshot av mikroarkitekturtillståndet när man börjar spekulering (börja köra den icke-äldsta instruktion out-of-order) och sedan bara uppdatera sin snapshot.

Om spekulationen är korrekt -> commit på de ändringar man gjort, annars släng bort dem -> finns aldrig ens något mikroarkitekturtillstånd som någon annan kan se. En sådan lösning kommer tyvärr kosta en del transistorer, men man börjar ju ändå få slut på idéer som relevant påverkar IPC vid krympningar...

AMDs lösning i Zen är att verifiera mer innan man startar spekulering. Enklare att få rätt, men lämnar mer prestanda på bordet.

Intels metod, bortsett från MDS problemen med HT, är i sig inte "broken-by-design". Är helt OK att direkt börja spekulering för att göra rollback om någon verifiering går fel. Missen nu är att man spekulerar även över säkerhetsdomäner, fixen för MDS är att enbart stoppa den formen av spekulering. Är helt OK och utan säkerhetsproblem att köra deras mer aggressiva spekulering inom en säkerhetsdomän. Ett alternativ är också det som nämns ovan med snapshots, då kan man även spekulera över säkerhetsdomäner på ett säkert sätt.

Skrivet av Paddanx:

Det är lite som att kassören gissar ditt kortnummer och pinkod högt ut i luften åt dig när du kommer fram i kassan från en lång lista av kortnummer. Ja, det kommer snabba upp det för lite då och då får de rätt gissning, men hur bra är detta tänkt ur säkerhet? I båda fallen är det som att totalt ignorera säkerheten, och anta att ingen förutom kassörskan får tag i dessa kortnummer, någonsin.

Om ditt exempel på något sätt varit representativt för dessa svagheter hade de absolut varit ett katastrof. I det läget vore en konkursansökan enda rimliga nästa steg för Intel. Fast rätt mycket pekar på att dessa svagheter är mer i risknivå med att fortfarande våga sig utanför dörren fast det regnar och med muller långt bort i horisonten.

Skrivet av Paddanx:

Självklart ville de inte se detta... i grund o botten har det ju gjort deras HT närmast värdelös.

Förutsatt att du låter okända köra valfri kod på din dator med möjligheten att låsa både sitt och det program de attackerar till en specifik CPU-tråd. För det är bara under dessa förutsättning som de PoC man fått fram fungerar.

Finns absolut system där detta är uppfyllt, men det inkluderar inte en typisk skrivbordsdator... Själv vill jag nog ändå att JS-motorer patchas så långt som möjligt mot detta, detta då det i praktiken är den enda realistiska attackvektorn (men krävs fortfarande att man hittar något hål för att låsa ned trådarna då inte ens webassembly gör detta möjligt).

Visa signatur

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

Permalänk
Datavetare
Skrivet av cyklonen:

Skulle det gå att låsa flertrådad körning till ett program per fysisk kärna? I de flesta fall, undantaget på servernivå, lär ju bara ett fåtal program köras samtidigt. Om jag vill köra t ex blender med maximal prestanda från processorn föreligger ingen säkerhetsrisk om blender får dela fysisk processor i flera trådar. Men ett annat program, även om det bara kan använda en tråd, får bara använda en fysisk kärna i det fallet. Lite slösaktigt, men lär knappast påverka prestanda där behovet är störst.

Skickades från m.sweclockers.com

Du tänker helt rätt här. Det du nämner här är nog den lösning Intel kommer ta till för att helt täta MDS i kombination med HT (vad man patchat så här långt är att med HT avslaget är man helt säker).

Så i stället för detta

gör man detta

Även utan MDS-problem kan det finnas prestandamässiga orsaker varför man skulle vilja ha en policy där trådar från samma applikation hålls på samma fysiska CPU.

Ett exempel är algoritmer som inte skalar perfekt med CPU-kärnor, men ändå har viss skalning. Sådana fall kan ofta se relativt liten skillnad i prestanda mellan att köras på två trådar i samma CPU och på två trådar på olika CPUer. Problemet är att om man kör det på olika CPU-kärnor äter man ändå upp resurserna i hos två CPU-kärnor, d.v.s. är klart högre perf/W att hålla det till en fysisk kärna.

Just fallet du nämner, Blender, är inte ett sådan fall jag beskriver ovan då rendering är trivialt att skala över kärnor.

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 Paddanx:

Mja, jag håller inte med.
Intel har valt att anta att koden som kommer är säkrad. De har valt att lägga till denna spekulativa gissning (som ger en stor del av hålen) för att få upp prestandan. Och de har valt att göra det utan att titta på hur och om detta kan missbrukas. Det är lite som att kassören gissar ditt kortnummer och pinkod högt ut i luften åt dig när du kommer fram i kassan från en lång lista av kortnummer. Ja, det kommer snabba upp det för lite då och då får de rätt gissning, men hur bra är detta tänkt ur säkerhet? I båda fallen är det som att totalt ignorera säkerheten, och anta att ingen förutom kassörskan får tag i dessa kortnummer, någonsin.

Som Yoshman skrev har de inte alls gjort ett sådant antagande. Att göra spekulativa gissningar är inget konstigt det heller. Snarare ett utmärkt sätt att förbättra prestandan. Även AMD och ARM gör detta.

Citat:

Helt säkra kan inget system vara. Men AMD gör trots allt kontroller på att se om du ska få tillgång till data utanför din nivå. Just detta tänket att man inte antar att lådans ytterkant är enda skyddet, utan har fler nivåer av skydd, som i sin tur själ prestanda så klart, är tydligt tecken på att de tänkte olika prioriteringar. Och jag är övertygad om att både AMD och ARM har pga deras designer är "nyare" än Intels, haft mer säkerhets tänk bakom designen än Intel. (De har lärt sig av marknadens problem med säkerhet mao)

Intel gör kontroller. Med out of order execution kan dock data hämtas ur minnet, som applikationen inte har behörighet till, och sedan cacheas. Innan applikationen får datan görs en privilegiekontroll. Här har man alltså trott att det inte går att titta i boxen utan att låsa upp den först, vilket "typ" är sant. Det visar sig dock att man kan "knacka på boxen", eller boxarna (minnesadresserna) för att se om de är tomma eller inte och räkna ut vad som gömmer sig däri. Privilegiekontrollen är fortfarande på plats.

Citat:

Heh... mjo, tror det med.
Självklart ville de inte se detta... i grund o botten har det ju gjort deras HT närmast värdelös.

Mer som att de inte alls såg det här komma. Nu verkar också kaninhålet bara bli djupare.

Permalänk
Medlem
Skrivet av filbunke:

Skita på andra sidan säger du? Överdrifter?

Var inte orolig, din prestanda per tråd är fortfarande kvar... Eller... Per kärna blir det väl? Med HT avstängt... Som en 9700K alltså.

Mycket riktigt så är det jag som säger så! Menar du att jag har någon sida? Och i så fall, varför?

Åh tackar, men jag har ingenting att vara orolig över 😌

Om det är så att du får en liten kick av att snäsa av personer som inte har valt det märket av CPU som du tycker är bra, så är du på fel ställe och dummar dig 😊

Skickades från m.sweclockers.com

Visa signatur

Låda: Phanteks Eclipse P400S White TG | Mobo: ASUS ROG Strix Z390-F | CPU: Intel i9 9900K @ 5,0 GHz | GPU: ASUS ROG Strix GTX 1080 Ti | RAM: Crucial Ballistix Sport LT 32GB (4x8GB) DDR4 @ 2400 MHz | Corsair RM750x | Lagring: Samsung SSD 850 EVO 120GB | Crucial MX300 275GB | WD Caviar Blue 1TB | Hitachi Deskstar 500GB | OS: Windows 10 Professional - https://valid.x86.fr/4m66jq