Intelin prosessoreista löytynyt bugi vaatii suorituskykyyn vaikuttavan käyttöjärjestelmätason

[Griffin]

Kannattaa muistaa että vaikka yksittäisen bitin lukemisessa on tietty epävarmuus, jo aika vähäisillä toistoilla saadaan siitä luvusta riittävän luotettavaa.

Tosin kun yhdelläkin yrityksellä korruptoidaan reippaasti dataa, niin eipäs se järjestelmä välttämättä edes toimi sen jälkeen. Ja käytännössä ei pystytä järjestämään tuollaista optimitilannetta vaan homma kusahtaa erittäin helposti useassa vaiheessa.

 

[pespoit]

Intel CPUs can be exploited unless you disable hyper-threading, Linux dev claims | TechRadar
Onko kotikäyttäjän järkeä kytkeä hyperthreadingia pois päältä, vai onko tuo haavoittuvuus tasoa "mahdollinen jos olet valtiontason vakoilun kohteena"?

 

[Lepakomäyrä]

Intel CPUs can be exploited unless you disable hyper-threading, Linux dev claims | TechRadar
Onko kotikäyttäjän järkeä kytkeä hyperthreadingia pois päältä, vai onko tuo haavoittuvuus tasoa "mahdollinen jos olet valtiontason vakoilun kohteena"?

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.

 

[hik]

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

Hölösuu vuodattaa koko elämänsä someen = 10 000
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.

 

[Kizmo]

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.

 

[hkultala]

Intel CPUs can be exploited unless you disable hyper-threading, Linux dev claims | TechRadar
Onko kotikäyttäjän järkeä kytkeä hyperthreadingia pois päältä, vai onko tuo haavoittuvuus tasoa "mahdollinen jos olet valtiontason vakoilun kohteena"?

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.

 

[Griffin]

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.

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ä..

 

[hik]

Tämä ei vaatisi raudalta mitään muutoksia, vaan vain käyttiksen skedulerilta

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.

 

[hkultala]

Mahtaako Linuxissa olla tuommoinen skeduleri käytössä jo?

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.

Ehkä Windowsiin muutos joskus aikanaan tehdään, kun riskitason arvellaan nousseen. Jolloin tulee ehkä pientä tarvetta päivittää nopeutetusti vanhoja koneita taas.

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.

 

[hik]

Ei.

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.

 

[pespoit]

Mahtaako Linuxissa olla tuommoinen skeduleri käytössä jo?

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.

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.

Näin lueskelin itsekin, mutta epävarmuutta aiheutti tieto että ainakin ChromeOSissa hyperthreadingi on kokonaan pakotettu pois päältä.

 

[hik]

Jos CPU scheduleria meinataan niin niitähän on saatavilla useampia

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.

 

[jive]

Huppista...
Benchmarks Of JCC Erratum: A New Intel CPU Bug With Performance Implications On Skylake Through Cascade Lake - Phoronix

Ei enää vaikuta vahingolta.

 

[Kizmo]

New ZombieLoad Side-Channel Attack Variant: TSX Asynchronous Abort - Phoronix

Ja uusi zombieload variantti myös

 

[hkultala]

Huppista...
Benchmarks Of JCC Erratum: A New Intel CPU Bug With Performance Implications On Skylake Through Cascade Lake - Phoronix

Ei enää vaikuta vahingolta.

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.

 

[jive]

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?

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?

 

[hkultala]

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ä.

The microcode update prevents jump instructions from being cached in the Decoded Icache when those instructions cross a 32-byte boundary or where they end on a 32-byte boundary. Due to that change there will be more misses from the Decoded ICache and switches back to the legacy decode pipeline -- resulting in a new performance penalty.

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.

 

[JaniKari]

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.

 

[hkultala]

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ä

 

[jive]

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.

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?

 

[hkultala]

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.

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.

Toisaalta miksi vain gas on korjattu eikä muita kääntäjiä mainita? ICC ja MSVC nyt lähinnä kiinnostaa.

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.

Olisiko valistunutta arvausta miksi bugi löytyi juuri nyt?

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.

 

[JaniKari]

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.

 

[hkultala]

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.

 

[JaniKari]

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.

 

[hkultala]

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.

 

[Teuras]

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

 

[jooseppi79]

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ä.

 

[Taneli-]

Menee varmaan siltikin tovi että AMDstä tulee ykkösvaihtoehto. Ei näytä tietoturva ongelmat haittaavan datacenter poikia jotka vieläkin sortuvat ostamaan Inteliä.

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.

 

[Lepakomäyrä]

Menee varmaan siltikin tovi että AMDstä tulee ykkösvaihtoehto. Ei näytä tietoturva ongelmat haittaavan datacenter poikia jotka vieläkin sortuvat ostamaan Inteliä.

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.

 

[Kizmo]

Ja jos taas mennään

Intel might want to reconsider the G part of SGX – because it's been plunderstruck

The SGX flaw has been dubbed Plundervolt by the computer scientists who found it – Kit Murdock, David Oswald, and Flavio Garcia from the UK's University of Birmingham, Daniel Gruss from Austria's Graz University of Technology, and Jo Van Bulckand and Frank Piessens from Belgium's KU Leuven.

In their research paper [PDF], "Plundervolt: Software-based Fault Injection Attacks against Intel SGX", the boffins explain how they were able "to reliably corrupt enclave computations by abusing privileged dynamic voltage scaling interfaces".

Using undocumented interfaces for manipulating chip voltage, they demonstrated they could recover cryptographic keys based on RSA-CRT and AES-NI crypto libraries and create memory safety errors like out-of-bounds array accesses and heap corruption.

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

According to Intel, it is fixing 77 security flaws with this raft of patches. 67 of the flaws were found internally at Intel, while 10 were discovered by outside researchers. At least one of the CVE vulnerabilities, CVE-2019-0169, has a CVSS rating of 9.6 (ratings of 9 – 10 are considered critical, the highest severity). As of this writing, the webpage for CVE-2019-0169 is a placeholder, but we’ll have more to say as soon as we can tell what this vulnerability does. It appears to be located in the Intel Management Engine or one of its subcomponents.

 

[mRkukov]

CVE-2019-0169, has a CVSS rating of 9.6 (ratings of 9 – 10 are considered critical, the highest severity).

Melkein kuin avaimet käteen, varkaille.

 

[mRkukov]

Plundervolt


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.

 

[Kizmo]

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

 

[calysto]

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

Probably [affected], unless you happen to have a CPU released after Q4 2018.

For a select number of processors released after Q4 2018, Intel inadvertently managed to partially mitigate this issue while addressing a previous issue called TSX Asynchronous Abort (TAA). See Section 9 in our our paper.

A list of affected products can be found here.

AMD is not affected by CacheOut, as AMD does not offer any feature akin to Intel TSX on their current offering of CPUs.

Arm and IBM do have a feature similar to Intel TSX, but we are currently unaware of whether any of their products are affected. We are also unaware of any other attack vectors to exploit CacheOut.

CacheOut can leak information from other processes running on the same thread, or across threads on the same CPU core. As an example, we successfully leaked both the decrypted output and the AES key from another process performing AES decryptions.

CacheOut is related to, and inspired by, previous work in speculative execution, including Spectre and Meltdown. Moreover, CacheOut bypasses the hardware mitigations released by Intel in response to Meltdown, thereby necessitating additional software fixes.

 

[eternality]

Putoaakohan taas suorituskyky kun tämä fiksataan? Alkaa skylake oikeasti vanhenemaan käsiin.

 

[JiiPee]

Nyt ottaa rdrand inttelillä pahasti hittiä uuden paikan myötä

RdRand Performance As Bad As ~3% Original Speed With CrossTalk/SRBDS Mitigation - Phoronix

www.phoronix.com

 

[mRkukov]

Nyt ottaa rdrand inttelillä pahasti hittiä uuden paikan myötä

RdRand Performance As Bad As ~3% Original Speed With CrossTalk/SRBDS Mitigation - Phoronix

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.

 

[Kizmo]

Nyt sitten löytyi Spectre luokan haavoittuvuus sekä Intel että AMD leiristä. Enää ei ole spectren nopeus yksittäisiä bittejä silloin tällöin....


I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches

https://www.cs.virginia.edu/venkat/papers/isca2021a.pdf

Modern Intel, AMD, and ARM processors translate complex instructions into simpler internal micro-ops that are then cached in a dedicated on-chip structure called the microop cache. This work presents an in-depth characterization study of the micro-op cache, reverse-engineering many undocumented features, and further describes attacks that exploit the microop cache as a timing channel to transmit secret information. In particular, this paper describes three attacks – (1) a same thread cross-domain attack that leaks secrets across the userkernel boundary, (2) a cross-SMT thread attack that transmits secrets across two SMT threads via the micro-op cache, and (3) transient execution attacks that have the ability to leak an unauthorized secret accessed along a misspeculated path, even before the transient instruction is dispatched to execution, breaking several existing invisible speculation and fencing-based solutions that mitigate Spectre.

Tätä nyt ei ilmeisesti pysty korjaamaan ilman järkkyä perffihittiä ja demotut vuotonopeudet on melkoisia.

 

[KoneenKokoaja]

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.

 

[Griffin]

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.

 

[Agent_007]

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.

 

[user9999]

Virginian yliopiston tarina tuosta.

https://engineering.virginia.edu/news/2021/04/defenseless

 

[Kizmo]

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.

Useampikin(?) muu sivukanavahyökkäys on rikkonut SGX:n, en kyllä tiedä tai jaksa tarkastaa että moniko niistä on luotettavasti korjattu.

 

[Kaotik]

Jatkot tuosta uudesta:

AMD:n ja Intelin prosessoreista löytyi uusi Spectren kaltainen haavoittuvuus - io-tech.fi

Virginian yliopiston tutkijoiden löytämän haavoittuvuuden korjaaminen nykyisistä prosessoreista on käytännöllisesti katsoen mahdotonta heittämättä hyvästejä suorituskyvylle.

www.io-tech.fi

AMD:n ja Intelin prosessoreista löytyi uusi Spectren kaltainen haavoittuvuus

Kaotik kirjoitti uutisen/artikkelin: Prosessoreiden sivukanavahaavoittuvuuksien pandoran lipas aukesi toden teolla 2018 Spectre- ja Meltdown-haavoittuvuuksien myötä. Haavoittuvuudet koskivat vaihtelevasti niin AMD:n, Armin kuin Intelinkin suunnittelemia prosessoreita ja niitä on sittemmin...

bbs.io-tech.fi