Meltdown- ja Spectre-haavoittuvuudet ovat olleet viime päivien kuumin puheenaihe. Nyt Intel on kertonut omasta edistymisestään haavoittuvuuksien paikkaamiseksi.
Intelin mukaan yhtiö on partnereidensa kanssa saanut valmiiksi haavoittuvuudet paikkaavia päivityksiä suurimmalle osalle yhtiön tuotteista. Mikäli aikataulut pitävät, lupaa yhtiö ensi viikon loppuun mennessä saada julkaistuksi päivitykset peräti 90 prosentille prosessoreista, joita se on julkaissut viimeisen viiden vuoden aikana.
Käyttäjät joutuvat kuitenkin odottamaan päivityksiä hieman pidempään, sillä Intel jakaa omat päivityksensä kumppaneillensa eikä loppukäyttäjille. Käyttäjät joutuvat siten odottamaan, että heidän tietokoneensa tai emolevynsä valmistaja julkaisee päivityksen, johon on sisällytetty Intelin korjaukset. Osa päivityksistä tulee luonnollisesti myös käyttöjärjestelmäpäivitysten mukana. Intel kehottaakin kaikkia käyttäjiä pitämään automaattiset päivitykset päällä niin käyttöjärjestelmän kuin muidenkin mahdollisten sovellusten kohdalla, jotta päivitykset asentuvat mahdollisimman nopeasti.
Lähde: Intel Kuva: Paul Pearce @ Twitter
Intel clarified that it's not recommending everyone to disable Hyper-Threading, but that some of its customers should consider the option depending on their security needs:
"Once these updates are applied, it may be appropriate for some customers to consider additional steps. This includes customers who cannot guarantee that trusted software is running on their system(s) and are using Simultaneous Multi-Threading (SMT). In these cases, customers should consider how they utilize SMT for their particular workload(s), guidance from their OS and VMM software providers, and the security threat model for their particular environment. Because these factors will vary considerably by customer, Intel is not recommending that Intel® HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS."
Google seems to be one of those select customers which considers the risk of keeping HT enabled just too big. The company has published on the Chromium site that HT will be disabled in Chrome OS version 74:
"To protect users, Chrome OS 74 disables Hyper-Threading by default. For the majority of our users, whose workflows are primarily interactive, this mitigates the security risk of MDS without a noticeable loss of responsiveness. Chrome OS 75 will contain additional mitigations."
Jos käytän 7700k prosessoria vain pelaamiseen, pidänkö siis hyperthreadining päällä vai otanko pois käytöstä?
Mietityttää tuo 'it's not recommending everyone to disable Hyper-Threading' eli kenen kannattaa ottaa pois päältä ja kuka voi pitää sitä päällä kuten ennenkin.
Hyvä kun Ubuntulle myös korjaukset tulleet (Kernel, QEMU ja kumppanit), HT käytöstä poisto suositeltavaa "turvallisuuden parantamiseksi"
Moni uudempi peli hidastuu jos 4c 8t prosusta ottaa HT:n pois. 4c 4t on vähän mopo jo. 4c 8t vastaa lähes 6c 6t prosuja ja voi ilmeisesti olla jossain tietyssä tilanteessa jopa parempikin.
Katotaan rauhassa minkälaisia patcheja tulee. Spectre-hyökkäyksiä ei ole tullut kai tietoon vielä ainuttakaan.
Sääliksi käy kauniita kerneleitä joihin tulee turhaa spagettia, sekä Linusin pelihousuja.
Ihmettelin toisessa ketjussa syksyllä tutkijoita jotka käski kategorisesti tiputtamaan HT:n prosuista kokonaan pois. Ajattelin silloin, että riittävästi faktaa ei ole ja tutkijat meni politiikan puolelle. Nyt tulee mieleen että he saattoivat olla oikeassa. Jos he olikin oikeassa, silloin myös AMD-prosujen HT on huono ajatus pitkän päälle.
Hieman harhaanjohtavasti taas kirjoitettu. "Suositellaan SMT disabloimista", mutta "Intel ei suosittele HT disabloimista".
SMT yhdistetään monesti AMD vastaavaan toteutukseen, vaikka tuo uusinkaan ei tainnut sitä koskea. HT on taas intelin brändi/nimitys heidän SMT toteutuksesta. Suurin osa ei vain ymmärrä että HT = SMT.
Kuuluivatko ne haavoittuvuudet Meltdown- vai Spectre-perheeseen jotka vaativat korjauksena sekä BIOS- tason mikrokoodipäivityksen että käyttöjärjestelmätason päivityksen? Toimivaa mutta
vanhaa BIOSia en ole päivittämässä ellei ole pakko joten jos tuo kyseinen haavoittuvuus sattuu olemaan juuri se jonka korjaukset rampauttavat suorituskykyä eniten sen voisi poistaa
tilapäisesti käytöstä InSpectrellä koska ilman BIOS-päivitystä se hidastaa konetta turhaan.
CPU firmwaren eli mikrokoodin voi päivittää sekä BIOS, että käyttöjärjestelmän päivityksien kautta. Microsoft saa viralliset microkoodipäivitykset suoraan AMD tai INTELILTÄ laitettavaksi mukaan käyttöjärjestelmä päivityksiin varsinkin jos kyse on kriittisistä päivityksistä. Windows update sitten katsoo mikä CPU koneessa on ja päivättää cpu firmwaren oikealla versiolla. Molempiä päivityksiä ei tarvita eikä vanhempiin emolevyihin edes BIOS päivityksiä enää edes tule.
Suurin syy miksi BIOS päivityksiä tarvitaan on se, että Microsoft ei automaattisesti laita ei kriittisiä microkoodi päivityksiä jakeluun windows updaten kautta. BIOS päivitykset usein myös päivittelevät paljon muutakin kuin vain cpu firmwaren.
Windows update ei kyllä asentele mitään firmiksiä uusiksi. Se mitä tehdään on ajonaikaisen ohjauksen muuttaminen. Seuraavassa bootissa taas kadonneet, kunnes käyttis ne taas uudelleen asettaa. Bios päivitys asentaa ne pysyvästi.
Ei se bioskaan niitä pysyvästi prossuun asenna. Samalla tavalla ne katoavat, MUTTA ne nyt päivitetään vain ennen käyttiksen lataamisen aloittamista, jokakerta. Eli käyttiksen ei tarvitse tietää asiasta mitään, jos BIOS hoitaa..
Molemmat Win10 ja Linux osaavat ladata bootissa uusimman microkoodin CPU:lle sillä, että se latautuu vasta bootissa eikä BIOS vaiheessa ei ole mitään käytännön merkitystä. Mikrokoodin latautuminen tapahtuu nykyraudalla mikrosekunneissa, joten sitä ei voi edes havaita bootin hidastumisena.
Mitenkäs sellainen tilanne jossa dual boot, linux salattu, windows pelkästään pelaamiseen; kuinka saada kaikki hidastavat pätsit pois windows-puolella ja linuxissa päälle? Ilmeisesti ei mitenkään jos ymmärsin oikein näitä viestejä? EDIT: vedetääs heti takaisin, eli jos ei asenna uutta BIOS:ia (ei edes tarjolla) niin sitten ilmeisesti tuo aiempi haluttu kuvio olisi mahdollinen. Mutta saako windowsista kaikkia pätsejä pois päältä?
Bios POST (power-on-self-test) jälkeen käyttöjärjestelmän bootloader tiputtaa CPU:lle uusimman microkoodin, jota säilytetään salatussatiedostossa, jonka ainoastaan CPU pystyy tulkitsemaan konekieliseksi. Tällä estetään se, että mikrokoodia ei voi muutella hakkerointi tms. tarkoituksessa. Myöskään CPU ei osaa tulkita mikrokoodia jota ei ole salattu vain Intelin tai AMD tiedossa olevalla salausavaimella ennen lataamista prossulle.
Käsitykseni mukaan sekä Windowsin, että Linuxin Bootloaderit osaavat tarkistaa onko saatavilla (päivityksen mukana asennettuna) uudempaa mikrokoodia ja ladata sen jos on tarvetta. Yleensä ne laitetaan käyttöjärjestelmään virallisten päivitysten mukana jos kyse on kriittisestä mikrokoodi paikkauksesta.
En ole perehtynyt siihen onko jotain työkaluohjlemia millä prossuun voi hakseroida vanhemman mikrokoodi version. Noissa on tietty omat riskinsä varsinkin jos työkalu on kolmannenosapuolen koodailema eikä virallinen AMD tai Intelin tekemä. :O
Mielelläni lukisin lisää tästä salauksesta minkä avaimen tietää vain joku prosessori tms. ja mitä mikään muu taho ei voi ja kykene lukemaan. Toki menee nyt jo aiheesta ohitse, mutta oli sellainen väittämä tämä, että en nyt ole ihan varma miten tämä pitäisi ymmärtää.
Ihan s.e. kuka tahansa ei pysty syöttämään sinne prosessoriin mitään mikrokoodia. Ainoastaan valmistajilla on avaimet, joiden avulla sinne saadaan upatttua uusi mikrokoodi.
Tietysti jos se avain vuotaa tai keksitään, niin sitten voi syöttää esim haitaketta auttavan mikrokoodin sinne prossuun.
Se kyseinen haavoittuvuus taisi olla jokin Spectre- variantti joka vaatii BIOS- tason mikrokoodipäivityksen sekä käyttöjärjestelmän "pehmeän" päivityksen jotta haavoittuvuus poistuu. Tai ainakin niin luin, intelin virallisetkin ohjeistukset ovat liian ympäripyöreitä että niistä voisi päätellä mitään. Niissä suositellaan aina että käyttäjä päivittää BIOSin sekä käyttöjärjestelmän, tai ainakin vähintään BIOSin.
Asiaa voi ajatella vaikkapa matemaattisena lukkona johon käy vain miljardeista ratkaisuista vain oikea ratkaisu. Ei se CPU mitään tiedä se on vain rakennettu siten, että vain yksi ratkaisu miljardeista on se oikea. Samaan tapaan kun ei se abloyn lukko asunnon ovessa tiedä mitään se vain on rakennettu siten, että vain se juuri oikea avain kykenee sen avaamaan eli ratkaisemaan lukon. Se CPU salaustekniikalla luotu lukko, joka perustuu matematiikan ominaisuuksiin on vain miljardeja kertoja monimutkaisempi kuin Abloy lukko. Jos matemaattinen lukko ei aukea mikrokoodia ei oteta käyttöön.
Oikeasti sen ymmärtäminen miten tuo toimii ja miksi mikrokoodia on vaikea hakkeroida edellyttää vähintään matematiikan ymmärtämistä yliopiston kandi / diplomi-insinööri tasolle. Sen lisäksi pitää käydä 600 sivuinen materiaali läpi siitä miten yleisimmän salaustekniikat toimivat ja ymmärtää yleisimpiin salaustekniikoihin liittyvä matematiikka. Tämän lisäksi pitää käydä mikrotietokone tekniikan opinnot vähintään amk-insinööri tasoiset, jotta ymmärtää miten se toimii rautatasolla. Tämän lisäksi on hyvä olla vielä ymmärrystä fysiikasta, sähkötekniikasta ja elektroniikasta, jotta ymmärtää miten se toimii fyysisellä sähkötasolla. Tästä syystä en itsekään aio edes yrittää selittää asiaa tämän tarkemmin itselläni on vain amk-insinöörin opinnot ohjelmistotekniikasta ja osaan vain soveltaa noita juttuja, mutta en todellakaan 100% ymmärrä miten kaikki ne toimivat. Sorry vaan.
Mutta silti väität, että sinne prosessoreihin on piilotettu jotain takaovi ominaisuuksia mihin oikean koodin syöttämällä voi saada prosessorin suorittamaan ihan mitä tahansa käskyjä ennen kuin se lataa käyttöjärjestelmää ja tämä koodi löytyy kaikista prosessoreista. En tiedä, ihan vaan hieman ihmettelen.
Kyllähän jos intel itse tai joku, jolle intel on avaimen antanut haluaa tehdä uuden, todella pahan haitakkeen ja vakoilusoftan, niin mikrokoodipäivitykseen sen piilottaminen on todella hyvä paikka. Eli kannattaa miettiä esim onko jonkun maan vakoiluorganisaatioilla käytössä noita avaimia.
Cryptatusta / täysin dokumentoimattomasta mikrokoodipökäleestä kun ei pysty debukkaamaan yhtään, mitä se itseasiassa tekee.
Aina se on mennyt noin, että valmistajat voivat ajaa tuotteissaan ihan sellaista koodia firmwarena tai muuna koodina kuin haluavat jos se on allekirjoitettu virallisella salausavaimella silloin se on virallista koodia. Tämä sama pätee modeemeihin, älypuhelimiin, älytekkareihin, prosessoroihin, käyttöjärjestelmiin, ajureihin oikeastaan kaikkiin laitteisiin, jossa on netti yhteys ja mahdollisuus ladata päivityksiä etänä. Ei ne suojaukset takaa muuta kuin sen, että päivitys on virallisesta lähteestä tai lähteeltä jolla on hallussaan viralliset salausavaimet. Jos valmistaja haluaa upottaa tuotteisiinsa vakoilukoodia tai haittaohjelmia silloin valmastaja voi tehdä niin ja vielä saada sen näyttämään 100% viralliselta päivitykseltä halutessaan, jolloin virustorjunta ohjelmistotkaan eivät vakoilukoodia havaitse, koska ne ovat virallisen koodin sisältämiä virallisia toimintoja.
Samasta syystä jenkit ei halua Huaweita länsimaiden 5G verkkoihin, koska he eivät halua länsimaihin laajassa mitassa tekniikkaa johon voidaan koska tahansa asentaa Kiinasta etäyhteydellä virallisilla Huawein salausavaimilla allekirjoitettua haittaohjelmakoodia suoraan keskeisiä toimintoja ajaviin Huawein laitteisiin. Vaikka tätä ei koskaan tehtäisikään edes mahdollisuutta ja kykyä siihen ei haluta antaa.
Ei tavallinen ihminen voi asialle yhtään mitään eikä edes Suomi. Paras varmaan suomelle on ostaa osa laitteista Kiinasta ja osa länsimaista näin jos suhteet menee yhteen suuntaan ainakin osa verkoista ja laitteista vielä toimii. Jos CPU on haittaohjelmakoodia (tai jonkun muun laitteen ajureissa tai firmwaressa joka on allekirjoitettu virallisilla salausavaimilla), joka vuotaa salausavaimiasi tai salasanojasi NSA:lle tai CIA:lle. Et sitä voi mitenkään estää, koska ne voidaan ujuttaa sinne virallisina päivityksinä varsinkin jos AMD ja Intel antavat salausavaimensa ulkopuolisen toimijan käyttöön.
RAMBleed
Mahdollistaa esimerkiksi ssh avainten lukemisen ramista tai ilmeisesti melkein minkä vain datan.
Ensin tajuton kikkailu, että saadaan tavarat muistissa sopivasti.
Sitten "luetaan":
"successfully read the bits of an RSA-2048 key at a rate of 0.3 bits per second, with 82% accuracy." DDR4?
DDR3, single channelilla helpompi..
Ja koska lukeminen perustuu bittien muuttumiseen, niin korruptio aiheuttaa helposti ongelman.
Ja jos todennäköisyys OIKEIN lukemisen on 82% / bitti, niin:
1 bitti: 0,82
2 bittiä: 0,82^2 =06724
.
.
8 bittiä:0,204 (20% todennäköisyys saada oikein..)
Ja sitten muistikonfiguraatio voi muuttua oikeassa, ei optimoidussa tilanteessa milloin vain, käytännössä jolloin homma kusahtaa.
Ei kuulosta taas kovin olennaiselta ongelmalta, vaan melkoisen "periaatteessa toimii" väännökseltä..
Joo eihän tuo tosiaan ole kovin kummoinen ongelma. Lähinnä proof of concept tasolla. Siksi en tuosta uutta ketjuakaan tehnyt, vaan laitoin tänne vain fyi tietona. 🙂
Tosin kannattaa muista myös, että tämähän ei sitten ole mitenkään prosessorin ongelma, vaan muistien ominaisuus, eli toimii samalla tavalla kaikilla prossuilla. Ja mikäli tämä toiminsi kunnolla ihan oikeasti, niin kaikkien noiden edellisten aukkojen pätsäily olisi ollut täysin turhaa..
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.
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.
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ä.