Meltdown- ja Spectre-haavoittuvuuksien paikkaaminen on parhaillaan käynnissä vaihtelevin tuloksin. Intel on julkaissut jo tarvittavat päivitykset useimmille alustoistaan, mutta jakelu OEM-valmistajilta loppukäyttäjille on takunnut keskustelupalstojen mukaan useammallakin valmistajalla. Päivitysten jakelun takkuaminen ei ole kuitenkaan ainut ongelma, vaan asennetut päivitykset ovat aiheuttaneet myös ongelmia.
Intel kertoi jo aiemmin, että kuluttajilta ja datakeskuksilta kuultujen raporttien myötä yhtiö on havainnut Haswell- ja Broadwell-arkkitehtuureihin perustuvien järjestelmien kärsivän odottamattomista uudelleenkäynnistyksistä. Tuoreessa tiedotteessaan Intel kertoo ongelman olevan aiemmin raportoitua laajempi ja koskevan myös muita yhtiön prosessoriarkkitehtuureja.
Intelin tiedotteen mukaan Haswell- ja Broadwell-arkkitehtuurien lisäksi uudelleenkäynnistysongelmasta kärsivät Sandy Bridge-, Ivy Bridge-, Skylake- ja Kaby Lake -arkkitehtuurit. Yhtiön mukaan se on kyennyt toistamaan ongelmat omissa testeissään. Intel tekee parhaillaan töitä selvittääkseen uudelleenkäynnistysten perimmäisen syyn ja kertoo tutkimusten edenneen jo siihen pisteeseen, että yhtiö uskoo voivansa toimittaa järjestelmien valmistajille beetatason mikrokoodipäivityksen ensi viikolla. Vaikka yhtiön listaus ei mainitse erikseen Coffee Lakea se koskee kaikella todennäköisyydellä myös niitä.
Lähde: Intel
Mikäli joku haluaa käyttää koneissa olevia haavoittuvuuksia hyväkseen niin väittäisin että niitä löytyy merkittävämpiäkin melkoisen monelta ilman intelin prossuja.
Voisi täysin ummikkona kuvitella, että riskien suuruus menisi suhteessa jotenkin näin (saa mielellään korjata):
Tiedot joita itse luovuttaa julkisille palveluille, yhdistyksille ja firmoille = 1000
Android-kännykän kautta luovutetut tiedot = 100
Hävinneet ja varastetut kännykät ja tietokoneet ja tietoturvapaperit = 10
Windows 10 PC = 1, josta HT/SME osuus 0, 000 001
Toivon että HT:n ongelmat korjattaisiin.
Kunnes paljastuu se eka viaton softa joka on miljoonilla koneilla ja joka sivukanavien kautta kaikessa rauhassa kerää telemetriaa vuosikaudet. Varmaan jutut kuten Bitcoin lompakkojen salausavaimet on ihan kiinnostavaa tavaraa kaivaa esille suojatusta muistista kun ei ole mikään kiire. Huomattavasti vähäriskisempää kuin keyloggerit ja tehoaa myös niihin kirjautumisen jotka ei käytä salasanaa.
Tuo on ongelma lähinnä palvelinkoneissa, joissa on monen eri käyttäjän prosesseja, ei ongelma kotikoneessa, tai kotikoneessa se on ongelma vain siinä että jos se kotikone on jo saatu korkattua niin tuolla hyökkääjä voi ehkä päästä hiukan eteenpäin.
Ja tuossa on kyse siitä että SMT noin yleisesti ottaen mahdollistaa monenlaisia sivukanavahyökkäyksiä, ei siitä että intelin implementaatiossa olisi jotain vikaa.
Järkevä tapa paikata nämä olisi rajoittaa SMT siihen mitä sen nimikin tarkoittaa, eli monisäikeistykseen, (yhden prosessin sisällä) kun nyt se tosiasiassa sallii monen prosessin ajamisen samalla ytimellä. Tämä ei vaatisi raudalta mitään muutoksia, vaan vain käyttiksen skedulerilta. Suorituskyky joissain tilantessa saattaisi jopa parantua kun TLBitä ei tarvisi flushailla ja välimuisteista ei kilpailisi monen eri prosessin data.
Nuo sivukanavahyökkäykset vain tahtovat olla senverran raskaita, että tuollainen softa kun käy leviämään,niin se jää lopulta melko nopeasti kiinni, kun joku käy vähän tutkimaan, että mitä se oikein tekee, kun prossutehoa kuluu mielettömästi, vaikka softa ei tee mitään.
Lisäksi nuo ei ole kovin tarkkoja. Sieltä tulee dataa, mitä sattuu tulemaan ja jonkun täytyy loppupelissä käsin sitten setviä, saatiinko jotain oikeasti hyödyllistä..
Mahtaako Linuxissa olla tuommoinen skeduleri käytössä jo?
Ehkä Windowsiin muutos joskus aikanaan tehdään, kun riskitason arvellaan nousseen. Jolloin tulee ehkä pientä tarvetta päivittää nopeutetusti vanhoja koneita taas.
Ei.
Tämä on sen verran suuren luokan muutos, että tästä käydään pitkä bolemiikki, ja tästä täytyy tehdä ominaisuus, jonka saa kytkettyä haluamaansa moodiin. Kaikki eivät todellakaan halua rajoittaa SMTtä tällä tavalla:
Erityisesti softankehittäjille itselleen tästä olisi selvä suorituskykyhaitta, koska softat tyypillisesti käännellään siten että jokainen lähdekooditiedosto käännetään omassa prosessissaan.
Ei, ei tämä näkyisi tavallisen windows-peruskäyttäjän käytössä juurikaan. Pelit saattaisivat välillä jopa nopeutua, kun pelin säikeen kanssa samalle ytimelle ei tunge mikään satunnainen taustasäie.
No, toivottavasti olisi sentään jollain tasolla aloitettu jo. Mitä myöhemmin aloittaa, sen myöhemmin valmistuu.
Luulisi että tuo ei olisi erityisen hankala toteuttaa. Vaikka niinhän sitä aina luulisi.
Jos CPU scheduleria meinataan niin niitähän on saatavilla useampia. Defaulttina on ilmeisesti käytössä CFS, mutta esimerkiksi pelikäyttöön hiotuissa tkg-buildeissa suositaan PDS:ää. Muita vaihtoehtoja on ainakin MuQSS ja BMQ.
Näin lueskelin itsekin, mutta epävarmuutta aiheutti tieto että ainakin ChromeOSissa hyperthreadingi on kokonaan pakotettu pois päältä.
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..
—————————————
Kokonaisuutena kehittyneet prossut ovat niin täynnä täysin välttämättömiä optimointeja, jotta näitä reikiä tullaan varmasti löytämään tasaiseen tahtiin lisää. Ja hyvin on ARMikin päätynyt ihan samaan läjään ja sama tulee jatkumaan.
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