Spectre- ja Meltdown-haavoittuvuuksia on paikattu eri järjestelmissä niin käyttöjärjestelmäpäivityksillä kuin prosessoreiden mikrokoodipäivityksilläkin. Aina kaikki ei mene kuitenkaan niin kuin on suunniteltu, kuten Intelin Spectre-mikrokoodipäivityksen kanssa on käynyt.
Nyt myös Microsoft on reagoinut Intelin ongelmiin Spectre-haavoittuvuuden kakkosvariantin (CVE-2017-5715) kanssa. Yhtiön tukisivuston mukaan se on päättänyt julkaista uuden päivityksen, joka poistaa aiemman käyttöjärjestelmätason paikan Spectren kakkosvariantille Intelin prosessoreilta. Yhtiön mukaan tällä pyritään ehkäisemään Intelin havaitsemia uudelleenkäynnistymisongelmia sillä välin, kun Intel työstää uusia, ongelmattomia mikrokoodiversioita. Päivitys on julkaistu Windows 7 SP1:lle, Windows 8.1:lle ja kaikille Windows 10 -versioille palvelinversiot mukaan lukien.
Tämän lisäksi Microsoft antaa käyttäjille mahdollisuuden ottaa Spectren kakkosvariantin käyttöjärjestelmätason paikka käyttöön tai poistaa se käytöstä rekisterin välityksellä. Microsoft on julkaissut asiasta erillisen ohjeen IT-ammattilaisille sekä palvelinten ylläpitäjille.
Lähde: Microsoft
Minulta menee nyt kyllä sinun pointtisi ohitse aivan tyystin.
Minun ainoa kommenttini tässä on ollut se, että mielestäni uutisesta puuttui selkeäsanainen maininta siitä että kyseessä ei ole pelkkä bugi, vaan suuri tietoturvauhka. Minusta sen sisällyttäminen uutiseen oli merkityksellistä sen sisällön kannalta.
@Sampsa tämän asian korjasi ja nyt minusta kyseessä on erittäin hyvä ja selkeä uutinen asiasta. Siitä tulee vähemmänkin kernelimuistista tietävälle välittömästi ja selväsanaisesti selkeäksi mistä on kyse. Ne jotka haluaa tietää enemmän voi availla sen sisältämät linkit.
Se onko tätä aukkoa kukaan, vielä, käyttänyt ei ole asian kannalta merkittävää. Sen laajuus, sen aiheuttama riski, sekä sen vaativat korjaustoimenpiteet sensijaan ovat.
En usko että ie:n käyttö on ongelmana datakeskusten koneissa. 😀
Mutta joo. Eiköhän me jossain kohtaa saada jotain selitystä siihen miten homma oikein meni. Voi kyllä olla että Intelin puolelta ei moista selitystä tulla koskaan saamaan
Nyt toki keskustellaan kotikoneista, täällä on varmaan aika vähän datakeskuksien ylläpitäjiä kysymässä neuvoa.
Laajuus ja vaaditut korjaustoimenpiteet ovat ainakin historiallisen suuria. Siihen nähden voisi riskienkin olettaa olevan aika isoja.
Toki ja korjaako jo valmiina olevat paikkaukset windowsissa ja linuxissa ongelmaa, vai tuleeko tästä loputon paikkauskohde.
Windowsiinha odotetaan korjausta seuraavaan päivitykseen ensi viikoksi.
Toki voit kertoa millainen "suuri tietoturvauhka" on, vai onko uhka yhtä suuri kuin siinä kun tietokoneen liittää internettiin.
itse en korosta uhkaa, koska korjaukset on valmiina. Suurin uhka on palvelinpuolella, koska sinne otetaan yhteyksiä jatkuvasti ja ei voi olla estettyjä. Kotikoneet on paljon suljetumman yhteyden takana.
FireStrike tuskin tekee system caleja sen jälkeen kun on ladannut tekstuurit ynnä muut levyltä (ennen benchmark runia) ja syöttänyt ne GPU:lle.
Eniten hittiä ottavat tuotantosoftat jotka käyttävät tietokantoja yms. Jos nyt jotain benchmarkkeja halutaan haeskella tällein enempi kuluttaja hömpötyksiin keskittyneellä foorumilla niin erilaiset filesystem/disk benchmarkit varmaan ottavat nokkaansa kohtuullisen kovasti. Tosin nekään ei välttämättä ota selkäänsä, jos niiden CPU käyttöaste testin aikana on hyvin matala, voi olla niin että CPU kuorma kasvaa hieman mutta luku/kirjoitus nopeudet pysyvät samana.
Nähtäväksi jää.. Jos osaisin ennustaa en toki koodi orjana duunia tekisi vaan ostelisin bittirahoja ja osakkeita kokopäivätyökseni. 😉
Siis miten tämä nyt vaikuttaa käytännössä? Jossain sanottiin että esim pelien pyörittäminen ei vaikeutuisi. Miten tämä on mahdollista?
Onhan noita CPU-intensiivisiä pelejä vaikka kuinka..
Mielenkiinnolla odotan millaiset vaikutukset käytännön suorituskyvyssä yleisimmissä tehtävissä. Kai @Sampsa ajaa ainakin suppeat testit ennen ja jälkeen päivityksen?:think:
Missä Windows insider käyttäjät? kokemuksia?
Ongelma ei ole se cpu:lla suoritettava koodi vaan muisti/levy accessit. Esimerkkinä tietokannat. Vaikuttaa toki peleihinkin, mutta niissä harvemmin I/O on pullonkaulana.
Riippuu ihan siitä kuinka useasti pitää vaihtaa suoritus kontekstia. Servereissä ja virtualisointi vehkeissä tätä tapahtuu huomattavasti useammin vs normi käyttäjän PC.
Pelkkä pelin CPU intensiivisyys ei vielä välttämättä vaikuta. Jos peli tekee system caleja tjsp jotka menevät "user space" käskyjen sijaan "kernel spaceen"vaikutusta tulee.
Kiitoksia, tämähän selvensi. Erittäin vittumaiselta kuullostaa mut onneksi kotikäyttäjää vähemmän haittaa.
Ois kyl ihan ehdoton artikkeli tämä 🙂
Vistassahan taisi näyttisajurit siirtyä userspacen puolelle, joten luulisi, ettei peleissä tule droppia.
Joko jenkeissä on joukkokanteet viriämässä? 😀
Toivottavasti saavat Kernel päivityksen fiksattua niin, ettei AMD kärsi päivityksestä.
Ajattelin että itsekin osallistun Suomessa joukkokanteeseen jos tiedot pitävät paikkaansa.
Johan amd julkaisi sen hauskan oneliner patchin. 😀
Njoo tuossa varmaankin kyse on siitä että on paljon helpompi(==nopeampi) lyödä kategorisesti liinat kiinni ja aukoa solmuja paremmalla ajalla alustakohtaisesti. Sanamuoto on myös että vanhemmat prossut kärsivät enemmän, ei että uudemmat kärsivät vähemmän. PCID pitää emuloida vanhemmilla raudoilla, jolloin kerroksien väliin tulee entistä enempi phläskiä.
Itse näkisin tämän (http://people.oregonstate.edu/~jangye/assets/papers/2016/jang:drk-bh.pdf) perusteella, että Intelin prosessorit Haswell-sukupolvesta eteenpäin kärsivät tästä ongelmasta. Tästä kielii sekin, että TSX-NI -laajennukset on joillain prosessoreilla otettu pois käytöstä mikrokoodipäivityksillä.
EDIT: Näkyykin olevan vain yksi hyökkäysvektori muiden joukossa. Syyllinen on koko pre-fetch -toiminto, jossa ei turhia tarkistella:
Attack vector.
Prefetch Side-Channel Attacks are novel and generic sidechannel attacks. We exploit the following two properties: Property 1 The execution time of prefetch instructions varies depending on the state of various CPU internal caches. Property 2 Prefetch instructions do not perform any privilege checks.
Lähde: https://gruss.cc/files/prefetch.pdf
AMD lappu vajaassa 10% nousussa ennen pörssin aukeamista 😀
Jeh ainakin E5 v2 Xeonista on mystisesti kyseinen ominaisuus kadonnut.
Intel's CEO Just Sold a Lot of Stock
Jos tää liittyy aiheeseen niin kova mylläys on tulossa.
JS ei ainakaan selaimessa mielestäni pääse suorittamaan sellaisia toimintoja joilla tätä voisi exploitata kun aika rajattu mitä siellä kuitenkin loppujen lopuksi voidaan suorittaa. Jossain node.js tms sitten voi olla eri asia, mutta se meneekin sitten server-siden puolelle.
Tietysti jos selaimen JS enginessa on joku remote code execution bugi joka antaa suorittaa jotain muuta koodia, niin sitten tilanne voi olla eri.
Eiköhän me tätä aktiivisesti tulla seuraamaan, uutisoimaan ja testaamaan :tup:
Jospa viimein saadaan jotain uusia tuulia x86 arkkitehtuuriin. Onhan tuo jo aikansa jäänne.
Insider buildeissa tosiaan ollut fixi jo sisällä jonkunaikaa. Itse ajelin pari peli benchmarkkia FCU:lla ja uusimmalla Insider buildilla, ja eroja ei juurikaan näkynyt. Alla arvot joita sain. Koneena i5-4670K (OC 4.2 GHz), 16GB DDR3 1600 MHz (OC 1866 MHz) ja Asus Geforce GTX 980. Testi ei välttämättä ole ihan 100% tarkka, koska FCU testit on ajettu pitkään käytetyllä asennuksella ja tuo Insider taas oli täysin puhdas asennus. Suljin kyllä FCU:n puolelta kaikki ylimääräiset ohjelmat.
Unohdin ottaa CPU fps arvon tuosta Insider versiosta, mutta score oli jopa korkeampi.
Intelin vastaus Opteronille? 🙂
Eli tuleeko vaikuttamaan myös nykyisiin ja tuleviin Amd-prossuihin?
Hyvä uutinen, saapahan punikit taas bensaa myllyynsä kuinka on maailman parhautta omistaa Ryzen/Vega.
Mutta eihän kukaan kerro että täällä Suomessakin kymmenet/sadat ja maailmalla varmaan kymmenet/sadat -tuhannet pelaajat ovat palanneet Intelin leiriin tuosta maailman mullistavasta prossusta josta vuosi sitten vauhkoivat he, sama ralli oli punikeilla Vegasta jo vuosi ennen julkkaria,ei vaan pärjää vihreelle/siniselle leirille mutta silti fanittavat…miljoonat olivat vaihtamassa vihreestä punaiseen leiriin kesällä koska vihree maksaa liikaa…pysykää nyt ***ke** siellä masteri-punaisessa leirissä ja vinkukaa kun en saa samoja fps lukuja kuin toisessa leirissä.
Joku järki nyt käteen, nyt puhutaan prosessoreista ja käytät termiä punikki?
Punikki – Wikipedia
Ketjun lukemallahan tuo selviää
Itselläni i5-4460 jolla toimii nykytilanteessa pelit vielä ihan hyvin mutta jos tuosta lähtee kunnolla suorityskykyä pois niin ei hyvä juttu. AMD:n kannalta taas äärimmäisen hyvä juttu.
Itse veikkaan ettei 99 % tavallisista käyttäjistä huomaa hidastumista ollenkaan,jollain sopivalla testillä varmaankin näkyy mutta ei käytännössä.Samoin veikkaan että pörssikurssit on muutaman viikon kuluttua suurin piirtein hässäkkää edeltävällä tasolla,ei AMD prossu muutu yhtään paremmaksi siitä mitä se oli viikko sitten.
Muuttuuhan AMD:n prossu selvästi paremmaksi ostokseksi tämän myötä.
Todellakin muuttuu. Riippuu tietysti täysin miten tuo nyt lopulta tulee vaikuttamaan suorituskykyyn.
Ongelmaa ei ole AMD:n prossuilla, mutta ainakin ensimmäinen versio Linux-pätsistä jostain syystä kohtelee AMD:n prosessoreita kuin niissä olisi sama ongelma. Eiköhän loppujen lopuksi päästä tilanteeseen että ei koske millään tasolla AMD:n prossuja.
Piti paikkaansa ehkä joskus IE6:n aikaan vielä :facepalm:
Skylakella olivat testejä tehneet ja siellä nähtiin 17-23% alentuneet tehot tietokanta toiminnoissa ja monessa muussa. Kyllä täytyy sanoa että itseäni uhkaa kun on alta vuoden vanha 7700k käsissä. Ketuttaisi kyllä lievästi jos siitä sattuisi oikeasti tehoja tipahtamaan tämän johdosta. Mitenköhän on, onkohan korvauksien paikkaa tai tuotepalautusten mahdollisuutta? Ryzeni alkoi näyttämään aika houkuttelevalta jos tommoinen pudotus tapahtuu hintaan nähden intelille.
Puhdasta teoriointiahan tämä vielä on. Mutta ajatellaan, että jos oikean elämän skenaarioissa ja peleissä se nyt sitten näkyisi vaikka 10%-20% pudotuksella. Se on tosi paljon siihen mitä se on ollut kun ostit kyseisen tuotteen. Itselle se ei ainakaan kuulosta hyväksyttävältä.
On selaimen sandboxista karkailevia javascript-exploitteja ollut ennenkin. Rowhammer.js tulee ensimmäisenä mieleen. Toinen julkaistu metodi on ASRL-muistiavaruuteen hyökkääminen välimuistin kautta: media.ccc.de – ASLR on the line
Kannattaa laittaa lähde mukaan niin voidaan vetää analyysi noista sun lukemista testeistä.:tup:
Jos tekkiläisillä on AMD-prossu ja uusi päivitetty Linux-kerneli käytössä, tuon hidastavan muutoksen saa pois käytöstä nopti kerneli parametrillä
Kernel parameters – ArchWiki
muok: koskee ilmeisesti 4.14.11 ja 4.15 versioita
Jännää myös kun Inteliähän on maailma täynnä jokaisessa serverihallissa ja vastaavassa ja jos niiden laskentakapasiteetista lähteekin pois 10-20% niin ei kuulosta hyvältä.
Väittivät, että AMD:n patch on hyväksytty RC7 versioon kernelistä.
Sinänsä AMD:n patch on kyllä hyvin tyly kuitti Intelin suuntaan: Jos ei ole AMD -> merkitse CPU turvattomaksi.
Tosiaan. Tulikohan lainaus oikein, en osaa vielä käyttää. Yritän tuossa katsoa uudestaan mistä noista luin, mutta tuota Registerin artikkelia ja siinä lainattuja Postgresql:n postauksia ja noita muita linkkejä luin ja kävin sitten katsomassa sql alan foorumeita. Siinähän itseasiassa onkin he lainanneet isolla tuossa twitter postauksessaan tuota 17-23% uhkakuvaa ja postauksessa olin lukevinani että 6000 sarjan skylakella oli ajettu. Itselle ei kuulosta kovin kivalta. En usko tosin, että oikean elämän skenaariossa iskee samalla tavalla, mutta kyllä näillä on kerrannaisvaikutuksia käyttäjiin ja varmasti myös osassa normaaleja operaatioita ja pelejä. Odotan kyllä innolla jos te pääsette jossain vaiheessa testailemaan ja selvittämään asiaa paremmin, ja toivon että ei olisi mitään näin vakavaa.
Kaikesta huolimatta, jos nyt kävisi niin huonosti, että se vaikuttaa jopa normaaliin käyttöön, mitä toivoisitte itse? Intelin maksavan osan arvosta takaisin, korvaavan jotain tai parhaimmassa tapauksessa haluaisitteko palauttaa prossun?
Tarkat yksityisikohdat tästä haavoittuvuuduesta on tarkoituksella jätetty julkaisematta, jotta järjestelmät saadaan päivitettyä, mutta jonkin verran tästä kuitenkin tiedetään.
Valitettavasti myös mutua ja FUDia on liikkeellä aika paljon.
Tämä IO-techin artikkeli onnistui nimenomaan kertomaan tiedossa olevat faktat aika hyvin, sen sijaan että olisi lähtenyt pelottelemaan ja suurentelemaan lukuja kuten esim. monet kommentoijat täällä.
Se jossain mainittu 30% luku oli yksittäinen "worst case real-world benchmark" joka teki todella paljon enemmän kernelkutsuja kuin esim. työpöytäsoftat tekee.
Peruskäyttäjän työpöytäsoftilla suorituskykyvaikutus jää hyvin pieneksi.
Sen sijaan palvelinsoftillla jotka tekee paljon IOta ollaan helposti 10% paremmalla puolella, mikä muuttaa selvästi EPYCin ja Xeonin välistä kilpailuasetelmaa.
Ongelma tässä patchissä vaan on se, että siinä on täysin unohdettu VIAn , Transmetan yms. suorittimet. Tuon ehdon pitäisi mennä siten, että jos valmistaja intel ja prosessorin mallisarja on tiettyä suurempi, sitten enabloidaan.
En minä näe tuossa ongelmaa. Muiden suoritinvalmistajien prosessorit edustavat pyöristykseen häviävää prosenttimäärää markkinoista eikä kukaan ole todistanut niitä turvalliseksi tuon bugin tai muidenkaan suhteen.
Tuossa koodissa on selvä virhe. Tyyppi luulee, että yhteenlaskun viive on 3 kellojaksoa, vaikka se on todellisuudessa yksi.
Lisäksi prosessorista loppuu ROBit ja/tai fyysiset rekisterit kesken kun näitä tehdään 300 peräkkäin.
Näiden syiden yhteisvaikutuksesta tuossa tulee vain ehkä n. 170 kellojakson viive paikkaan, jossa tarvittaisiin ~ >400 tai ~ >800 kellojakson viive, jotta exploit toimisi.
Tämä voi olla syy, miksei saanut exploittia toimimaan
spekulaatiota:
Eli, voi olla, että kyse on tuosta tuossa postauksessa esitetystä jutusta. Ja joku muu on tuon lukenut, huomannut koodissa olevan virheen, korjannut sen (vaihtanut esim. viiveenä yhteenlaskut jakolaksuiksi tms.), ja saanut sillä exploitin toimimaan. Ja jättänyt korjatun koodin julkaisematta, sen sijaan ottanut yhteyttä Inteliin, AMDhen, microsoftiin ja linux-kehittäjiin, että korjatkaa.
Tai sitten tyyppi itse on myöhemmin tajunnut virheensä, korjannut koodinsa, saanut exploitin toimimaan, ottanut inteliin, AMDhen, microsoftiin ja linux-kehittäjiin yhteyttä ja jättänyt postaamatta exploitin korjattua versiota ennen kuin patchit on ulkona.
Tässä on tuo AMD-kehittäjän alk.per. patch, jota ei tuollaisenaan syystä tai toisesta ole vielä hyväksytty.
Linux-Kernel Archive: [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors
Offtopic:
En usko tuon olevan mikään syy palautuksille. Prosessorihan on ihan yhtä nopea kuin aikaisemmin. Se etteivät päivitetyt ohjelmat toimi yhtä nopeasti kuin aiemmin on ihan normaalia.
Ihan oikeinhan tuo menee. Intel on tehnyt itse täysin samaa menneisyydessä. Eli prosessori = Intel, valitse tappiinsa optimoitu koodipolku. Prosessori ei Intel = laita paska ja optimoimaton koodipolku suoritukseen.