Spectre ja Meltdown ovat olleet viimepäivien kuumin puheenaihe IT-maailmassa. Suurimman osan huomiosta on saanut Intel, vaikka haavoittuvuudet koskevat myös muita valmistajia.
Spectre- ja Meltdown-haavoittuvuuksien paikkaamisen tiedetään vaikuttavan tietokoneiden suorituskykyyn. Se, miten paljon paikat suorituskykyä laskevat, riippuu ennen kaikkea tietokoneella tehtävistä tehtävistä. Suurimman suorituskyvyn laskut tapahtuvatkin lähinnä datakeskuksissa, joissa palvelimiin kohdistuu raskasta I/O-rasitusta.
Intel on julkaissut omat suorituskykytestinsä koskien kotikäyttäjien tietokoneita Windows-alustoilla. Testit on ajettu yhtiön kolmen viimeisen sukupolven prosessoreilla käyttäen erilaisia synteettisiä testejä. 8. sukupolven Coffee Lake -prosessoreilla ja 8. ja 7. sukupolven Kaby Lake -mobiiliprosessoreilla testit on suoritettu Windows 10 -käyttöjärjestelmällä ja 6. sukupolven Skylake-prosessoreilla sekä Windows 10:llä käyttäen SSD-asemaa että Windows 7:llä käyttäen SSD-asemaa ja kiintolevyä. Testit ajettu SYSmark 2014 SE-, PCMark 10- 3DMark Sky Diver- ja WebXPRT 2015 -ohjelmilla.
Intelin omien testien mukaan suorituskyky on laskenut lähes jokaisessa testissä, mutta muutama poikkeuskin löytyy. Suorituskyvyn kerrotaan jopa parantuneen kiintolevyllä ja Windows 7:llä varustetulla Skylake-kokoonpanolla SYSMark 2014 SE:n Data/Finance Analysis- ja Responsiveness-testeissä sekä samalla prosessorilla, SSD-asemalla ja Windows 10 -käyttöjärjestemällä SYSMark 2014 SE:n Data/Finance Analysis -testissä, 3DMark Sky Diverin kokonaistuloksessa, grafikka-testissä ja grafiikka- ja fysiikkatestit yhdistävässä Combined-testissä.
Suurin negatiivinen vaikutus päivityksistä on saatu SYSMark 2014 SE:n Responsiveness-testissä Skylake-prosessorilla Windows 10 -alustalla ja Kaby Lake -mobiiliprosessoreilla. Skylaken tapauksessa suorituskyky oli vaivaiset 79 % alkuperäisestä, kun Kaby Lakejen suorituskyky riitti niin ikään erittäin heikkoon 86 %:iin alkuperäisestä. Myös Coffee Lake -kokoonpanoin ja Windows 7:lla ja SSD-asemalla varustetun Skylake-kokoonpanon tulokset laskivat alle 90 %:iin päivittämättömien verrokkien tuloksista samassa testissä.
Löydät kaikki suorituskykylukemat uutisen kuvasta, jonka voi avata täyteen kokoon klikkaamalla.
Lähde: Intel
Hyvä juttu.
Ja näyttää tosiaan olevan jotain tekeillä HT/SMT turvallisuuden parantamiseksi.
Tämä oli Google-haun "linux kernel scheduler with safe smt" eka osuma.
Huppista…
Benchmarks Of JCC Erratum: A New Intel CPU Bug With Performance Implications On Skylake Through Cascade Lake – Phoronix
Ei enää vaikuta vahingolta.
New ZombieLoad Side-Channel Attack Variant: TSX Asynchronous Abort – Phoronix
Ja uusi zombieload variantti myös
Se, että hyvin monimutkaisessa logiikassa joka laskee hyppyosoitteita offsetteina suoritettavasta käskystä, joka ladataan puoliksi kahdesta eri ei-käskyosoitteella suoraan osoitettavasta välimuistilohkosta on jossain bugi, ei mielestäsi ole vahinko? Mikä se sitten mielestäsi on?
Vaatii nimittäin hyvin monimutkaista kirjanpitoa että tuo koko microcode cache edes saadaan toimimaan muulle kuin täysin lineaariselle koodille.
Se että haarautumiseen liittyviä ongelmia löytyy jatkuvalla syötöllä lisää, nostaa kulmakarvaa.
Itselleni ainakin tulee mieleen että on tietoisesti oikaistu suorituskyvyn ehdoilla. Tämä uusin errata on myös outo siinä mielessä että paikkaus on melko triviaali, mutta kukaan ei ole aikaisemmin törmännyt siihen. Skylake ei enää ole mitenkään uusi arkkitehtuuri. Olisi mielenkiintoista tietää miksi bugi löytyi juuri nyt ja vasta nyt.
Edit: ei tämä käsittääkseni uop cachea koske vaan ihan tavan icachea?
Tämä koskee nimenomaan uop-cacheä.
Ja ei, oikea korjaus ei nimenomaan ole triviaali vaan tässä on tehty suorituskykyä hidastava workaround, että tuollaisia hyppyjä ei ollenkaan cachetetä uop-cacheen, vaan ne ladataan aina normaalista icachestä (jolloin niiden pitää mennä normaalien käskydekooderien läpi mikä sekä lisää virrankultuusta hiukan että rajoittaa kellojaksossa fetchattavien käskyjen määrää)
Oikeaa korjausta tälle ei pystyne tekemään minään mikrokoodipäivityksenä.
Ja kun näitä hyppyjä ei cachetetä micro-op-cacheen niin samalla ilmeisesti pitää jättää myös koko välimuistilinjallinen verran niitä (edeltäviä) käskyjä cachettämästä sinne uop-cacheen.
Intelin uusimmassa bugissa ei kerrota mitä tapahtuu jos osoitteet menee cache linen yli , undefined behaviour. Intel kuitenkin yrittää saada muutoksia kääntäjiin jotta ei performance ei huononisi taas prosentteja.
Mielenkiintoista nähdä miten pelit reagoivat tähän korjaukseen. Java(Script) aplikaatiot ainakin näyttivät hidastuvan aika pahasti korjauksesta.
javascript- tulkeissa ja java-virtuaalikoneissa (kaksi täysin eri asiaa) on nykyään sisäänrakennetut jit- tai hotspot-kääntäjät. Tämä tällaisten hyppyjen välttäminen/alignoiminen oikein pitäisi saada niiden koodigeneraattoriin mukaan, ei riitä että pelkkä tulkki/virtuaalikone käännetään uudella kääntäjäversiolla.
Se, että lohkojen väliin menevät bugaa on hyvin ymmärrettävää, ja on ihan normaalia että siinä tapauksessa tulee joku pieni hidastuminen, mutta se että lohko loppuu hyppyyn on siinä mielessä "huolestuttavampi" tilanne että sen pitäisi olettaa olevan yleinen ja nopea tilanne ja usein olisi järkeä järjestellä koodi siten että seuraava lohko alkaa hypyn jälkeisestä käskystä, jolloin se hyppy on nimenomaan siellä ihan lohkon lopussa.
Ja sitten jos jossain muussa prossussa olisi jotain vastaavaa vähän eri tavalla pielessä että joku toinen prossu sattuisi hidastumaan siitä, että lohko alkaakin suoraan hypyllä, niin kohta niille hypyille ei ole yhtään kelpoa nopeaa paikkaa jäljellä 😉
Ok, luotetaan asiantuntijan sanaan. Triviaalilla tarkoitin kääntäjien muokkaamista välttämään bugin liipaisevaa tilannetta. Se että ongelma voidaan kiertää muokkaamalla assembleria kuulostaa uskomattomalta, koska luulisi että ongelmaan olisi törmätty paljon aikaisemmin. Toisaalta miksi vain gas on korjattu eikä muita kääntäjiä mainita? ICC ja MSVC nyt lähinnä kiinnostaa.
Olisiko valistunutta arvausta miksi bugi löytyi juuri nyt?
Ei se kääntäjänkään muokkaus ole mikään oikea korjaus. Se on vaan keino jolla tuon workaroundin tarvii aktivoitua harvemmin jolloin sen suorituskykyhaitta vähenee.
Maailma on täynnä softaa jotka on käännelty ikuisuus sitten, tai jotkut käänellään muilla kääntäjillä, esim. softan XXXX sisäisellä JIT-kääntäjällä. Prosessorin täytyy suorittaa tuo huonosti alignoitu hyppy oikein.
Eli tässä on vaan 1) mikrokoodiworkaround joka korjaa mutta hidastaa ja 2) kääntäjä-purkka joku vähentää sitä hidastumista niillä softalla, jotka käännellään uusiksi.
Oikea korjaus vaatinee että tuolta jostain uop-välimuistin kirjanpidosta muutetaan ihan kovakoodattuja transistoreita tai johtoja. Todennäköisesti ei ole särki sunny covessa, koska se on aivn eri mikroarkkitehtuuri, mutta mielenkiintoinen kysymys on, että onko korjattu myös jossain comet lakessa tms joka pohjaa hyvin suoraan skylakeen.
MSVC on microsoftin eikä intelin tuote. Ei Intel voi sen koodia muuttaa. Intelin pitää pyytää, että voisiko microsoft kiltisti muuttaa. Ja microsoftia ei niin paljoa kiinnosta lisätä purkkaa kääntäjäänsä intelin bugien kiertämiseksi, kun se mikrokoodipatchin kanssa kuitenkin toimii oikein, ja kun tämä purkka kuitenkin voi hiukan hidastaa suorituskykyä muilla, "ehjillä" alustoilla.
Tai voi olla, että MSVC-päivitys tulee sitten joskus myöhemmin, jos intel saa microsoftin sen lisäämään.
Ja ICC taitaa käyttää gas:ia siihen lopulliseen käännökseen assmblystä konekielelle, joten kun GNUn työkalut (gas ja linkkeri) purkataan tuon mukaiseksi, ICC tekee automaattisesti mitä halutaan.
Kyllähän se on varmaan löytynyt kuukausia sitten, mutta haluttiin varmaan julkaista samalla kertaa sekä mikrokoodi-patch että kääntäjä-patch jottei saada lukea niin suuria hidastus-benchmarkkeja kuin että jos olisi ensin julkaistu pelkkä mikrokoodikorjaus muttei kääntäjäpurkkaa.
Phoronix:
The erratum notice officially lists Amber Lake, Cascade Lake, Coffee Lake, Comet Lake, Kaby Lake, Skylake, and Whiskey Lake as affected generations for the JCC bug.
Ilmeisesti Intelin prosessoreita ei käytetä missään kriittisissä paikoissa kun tälläista informaatiota voidaan pantata kunnes korjaukset on valmiita.
Se "panttaaminen" käytännössä haittasi vain niitä, jotka miettivät että ostaako intelin prossu vai ei, ja jotka päätyivät tällä välillä ostamaan intelin prossun joka tämän takia hidastuukin pari prosenttia, mutta olisivat valinneet toisin jos olisivat tienneet tästä.
Ne, jotka prossunsa olivat jo hankkineet aiemmin, eivät voineet sille yhtään mitään. Aikaisesta informaatiosta ei olisi ollut mitään hyötyä.
Ja mikäli kyseessä oli tietoturvaongelma, että tuo tuollainen hyppy tekee jotain jota voi jotenkin exploitata, sitten oli nimenomaan asiakkaille parempi että siitä ei kerrottu ennen kuin patchi oli ulkona, jottei pahat pojat tee sille exploitteja ennen kuin patch on ulkona.
Tietoturva virheiden panttaaminen, kunnes korjaukset ovat valmiita on ihan ymmärrettävää toimintaa. Stabiilisuus infon panttaaminen on yksinkertaisesti vastuutonta toimintaa. Ihmisten henget voi olla kiinni siitä, että Intel CPU toimii.
Intelin työpöytä- tai palvelinprosessoreita ei käytetä missään lentokoneiden FBW-järjestelmissä.
Edelleenkään tuosta informaatiosta ei olisi ollut käytännössä kenellekään mitään arvoa. Ei ole mitään toimenpiteitä, mitä sen perusteella olisi järkevästi tehty.
Ja kun ei tiedetä että mitä se bugi tarkkaanottaen aiheutti
Intelin virhelistassa sanotaan ainoastaan että "system may behave unpredicatably".
Ja se vaatii monimutkaisen sekvenssin joka koostuu useammasta tuollaisesta haarautumisesta peräkkin.
Pari päivää sitten tuli vastaan nämä uudet zombieload attackit mitkä on ilmoitettu intelille jo 6kk sitten, en silloin huomannut että cascade lakekin on haavoittuva. (eikö ne siihen rautapaikkaa jo implementoinut?)
Intel CPUs Since Haswell Vulnerable to "Zombieload v2" Attacks, "Cascade Lake" Included
edit:ZombieLoad Attack
Menee varmaan siltikin tovi että AMDstä tulee ykkösvaihtoehto. Ei näytä tietoturva ongelmat haittaavan datacenter poikia jotka vieläkin sortuvat ostamaan Inteliä.
Minun käsityksen mukaan amd on nostanut myyntiä myös sillä puolella.
Hitaasti mutta varmasti, kyllä AMD on nostanut myyntiään sielläkin puolella mutta suuremmat yritykset eivät joka vuosi (eivät edes joka toinen) investoi tuotteisiin. Moni kaupunki esim. vasta nyt alkaa siirtymään pois Windows 7 järjestelmistä mikä antaa hieman kuvaa siitä miten hitaasti toimitaan.
Kyllä, olen tietoinen että palvelimissa ei yleensä windows ympäristössä pyöritä mutta noin ja esimerkin vuoksi.
Jos ikinä siihen asti edes pääsee.
Ei intel sormiaan pyörittele mutta ei Intelillä myöskään ole tuloksellisesti mitään hätää vaikka 10nm/7nm kehitys/julkaisu viivästyykin.
Ja jos taas mennään 😀
Intel might want to reconsider the G part of SGX – because it's been plunderstruck
Aika siistiä että SGX:n tapaista ominaisuutta ajavassa raudassa on tuollaisia dokumentoimattomia rajapintoja. Etenkin kun huomioi mihin luokkaan bisnesvehkeissä Intel sijoittuu
Ja tänään tuli julki myös 77(!) zombieload korjausta:
New Spectre-Related CPU Flaw Tops Intel's Latest Critical Security Fixes – ExtremeTech
Melkein kuin avaimet käteen, varkaille. 😀
Plundervolt
katso liitettä 318454
CVE-2019-11157
Pieni alivoltitus ohittaa kivasti esimerkiksi SGX suojatut muistit, jolloin voidaan lukea ja kirjoittaa asioita joita ei pitäisi. Korjautuu kunhan disabloi alijännite interfacen. Yet another Intel bug. 🙂
We present CacheOut, a new speculative execution attack that is capable of leaking data from Intel CPUs across many security boundaries.
CacheOut
IPAS: INTEL-SA-00329 – Technology@Intel
Tällä kertaa toimii kaikilla skylakesta uudemmilla 😀
https://cacheoutattack.com/CacheOut.pdf
Q&A valitut palat
Putoaakohan taas suorituskyky kun tämä fiksataan? Alkaa skylake oikeasti vanhenemaan käsiin.
RdRand Performance As Bad As ~3% Original Speed With CrossTalk/SRBDS Mitigation – Phoronix
http://www.phoronix.com
Nopeasti otsikon lukemalla olin että "eihän 3% droppi nyt niin paha ole". Mutta se olikin että 3% aikaisemmasta nopeudesta, eli noin 97% tehosta katosi.
I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches
https://www.cs.virginia.edu/venkat/papers/isca2021a.pdf
Tätä nyt ei ilmeisesti pysty korjaamaan ilman järkkyä perffihittiä ja demotut vuotonopeudet on melkoisia.
Tämä ongelma koskee lähinnä virtuaalipalvelimia ja pilvipalveluita, joissa ajetaan usean eri asiakkaan softaa samalla palvelimella jakaen samoja prosessoreita usealle asiakkaalle. Jos samalla palvelimella on hyökkääjä voi se ajaa siellä softaa joka urkkii muiden asiakkaiden salausavaimia. Suurinta turvallisuustasoa vaativat palvelvelut käyttävät lähtökohtaisesti kokonaan omia palvelimia, jossa ei samalla fyysisellä palvelimella ajeta kenenkään kolmannen osapuolen softaa.
Eikös tuon kautta voi urkkia eri salausjärjestelmien avaimia, esim nyt blueray ja videopalvelut jne..
Jos tuota salauksen purkua tehdään tehdään tavallisessa ohjelmakoodissa (esim. Widevine L3) niin kyllä. Käsittääkseni tuo hyökkäys ei kuitenkaan pure esim. Intel SGX:ään (Intel SGX already does this at enclave entry/exit points, and as a result both the enclave and the nonenclave code leave no trace in the micro-op cache for sidechannel inference.) tai ARM:in Trusted execution environment -toteutukseen, joten Widevine L1 on tuolta suojassa.
https://engineering.virginia.edu/news/2021/04/defenseless
Useampikin(?) muu sivukanavahyökkäys on rikkonut SGX:n, en kyllä tiedä tai jaksa tarkastaa että moniko niistä on luotettavasti korjattu.
AMD:n ja Intelin prosessoreista löytyi uusi Spectren kaltainen haavoittuvuus – io-tech.fi
http://www.io-tech.fi
AMD:n ja Intelin prosessoreista löytyi uusi Spectren kaltainen haavoittuvuus
bbs.io-tech.fi