Alkuvuoden polttavimmat puheenaiheet tietoturvan saralla ovat olleet Meltdown- ja Spectre-haavoittuvuudet, niiden korjaukset ja niistä aiheutuneet komplikaatiot. Etenkin Intelillä on ollut ongelmia päivitystensä kanssa, sillä ne ovat aiheuttaneet paitsi suorituskykyhävikkiä, myös uusia suoraan käyttäjille näkyviä ongelmia.
Kotikäyttäjien kannalta Intelin päivitysten vaikutus suorituskykyyn on käytännössä olematon tai lähes olematon. Päivitysten myötä syntyneet satunnaiset uudelleenkäynnistymiset ovat kuitenkin ongelma, joka näkyy helposti kotikäyttäjänkin arjessa. Intelin mukaan ongelman piti alun perin koskea vain Haswell- ja Broadwell-arkkitehtuureja, mutta sittemmin yhtiö on päivittänyt lausuntoaan koskemaan kaikkia Core-arkkitehtuureita Sandy Bridgestä lähtien.
Intelin tuoreimman lausunnon mukaan yhtiön insinöörit uskovat nyt löytäneensä perimmäisen syyn Haswell- ja Broadwell-arkkitehtuurien uudelleenkäynnistymisongelmaan ja edistyneensä jo huomattavasti sen korjaamisessa. Yhtiö ei kuitenkaan kerro, onko myös muiden Core-arkkitehtuureiden uudelleenkäynnistysongelmat kiinni samasta seikasta tai miten niiden korjaus edistyy.
Lopullista korjausta odotellessa Intel suosittelee, että OEM-valmistajat ja muut yhtiön tuotteita käyttävät palveluntarjoajat lopettavat nykyisten päivitysten jakelun ehkäistäkseen uudelleenkäynnistysongelman leviämistä. Lisäksi Intel toivoo kumppaniensa keskittyvän Haswell- ja Broadwell-prosessoreiden tulevan päivityksen esiversioiden testaamiseen, jotta lopullinen versio saataisiin jakoon mahdollisimman nopeasti.
Lisäksi Intel pyrkii tarjoamaan käyttäjille, joille järjestelmän vakaus on ensisijainen seikka, mahdollisuutta palata käyttämään edellistä versiota prosessorin mikrokoodista siihen saakka, kunnes lopullinen ja ongelmaton mikrokoodiversio on valmis. Mikäli edellinen mikrokoodiversio tuodaan saataville, se tulee asentaa BIOS-päivityksen muodossa. Edelliseen mikrokoodiversioon paluu ei vaikuta Spectren ensimmäisen variantin tai Meltdownin korjauksiin, mutta poistaa suojauksen Spectren kakkosvariantilta.
Lähde: Intel
Microsoft Issues Windows Out-of-Band Update That Disables Spectre Mitigations
"data loss or corruption.". Tosta olisi kiva tietää onko aiheutunut noiden reboottien takia, vaiko kone kuitenkin toiminut normaalisti mutta silloin tällöin tallentanut dataa vähän väärin.
öö.. tuossahan se lukee:
Se että mitä tuo "other unpredictable system behavior" tarkoittaa, on oikea kysymys. 🙂
Tuo "higher than expected reboots" naurattaa, mikähän mahtaa olla intelin mielestä ei-toivottujen yllätysreboottien normaali määrä. Voihan sitä odotettua reboottien määrää pitää nollana, mutta silti minusta hölmö kommentti.
Itse toivoisin omistamani enterprise raudan kohdalla yllätysten määrän olevan nolla. Tällä hetkellä se tosin kaatuu ilman mitään näkyvää syytä vähintään kerran tunnissa. Saattaisin olla hivenen ärtynyt jos olisin koneen uutena hankkinut tai se olisi ihan oikeasti työkäytössä.
No rebootit tarkoittavat vain että systeemi on niin epävakaa että ei pysy edes pystyssä. Lähes sataprosenttinen varmuus on siis myös sille että laskee muutenkin päin persettä ja korruptoi dataa, tää on serveripuolelle aivan sairaan paljon suurempi ongelma kuin Spectre.
Intelillä ei nyt mene hommat ihan nappiin.
:facepalm:
Korrelaatiosta ei seuraa kausaliteetti, ja nyt on kausaliteetin suunta pahasti pieleen.
Järjestelmässä voi olla bugi, joka aiheuttaa virheellisen laskutoimituksen.
Järjestelmissä on myös tunnistuksia näille, ja suojamekanismeja, jotka sulkevat osan, joka meinaa tehdä jotain virheellistä. (tästä siis johtuu tyypillisesti segmentation fault, tai general protection failure, joka johtaa ohjelman kaatumiseen, käyttöjärjestelmä kaataa softan joka yrittää toimia väärin).
Virheellisessä laskutoimituksen ja tällaisen suojamekanismin laukeamisessa on usein selvä korrelaatio, ja kausaliteetti menee siihen suuntaan, että virheellinen laskutoimitus aiheuttaa suojamekanismin laukeamisen.
Mutta suojamekanismi voi myös bugata, ja aiheuttaa vääriä hälytyksiä, jotka johtavat järjestelmän osien virheelliseen sulkemiseen.
Tällä "väärä hälytys"-tilanteella ei ole mitään kausaliteettia niihin itse virheellisiin laskutoimituksiin, kumpaankaan suuntaan.
Nyt siis tilanne intelin spectre-pätchin suhteen vaikuttaa nimenomaan tältä. Järjestelmät, joiden tehtävä on tunnistaa laiton/virheellinen toiminto laukeaa virheellisesti ja (olemattomien) lisävirheiden vältämiseksi kaataa koneen, vaikka mitään laitonta/virheellistä ei ole oikeasti tehty.
Datan katoaminen johtunee näissä tapauksissa pelkästään siitä, että esim. levyvälimusitin likainen data jää kirjoittamatta, tai jollain ohjelmalla voi olla juuri joku tiedoston tallennus kesken ja alkuperäinen tiedosto on jo tuhottu ennen kuin uusi on kirjoitettu levylle. Ei mistään väärinlaskemisesta.
Katsotaan mitä tuolta tulee. Itsellä en nyt vielä ole kiirehtinyt näiden kanssa kunnes on joku oikeasti toimiva ratkaisu. Haluan tehdä päivityksen kerralla enkä siten että sitä joutuu sitten paikkailemaan. Näin siis rautapalvelimien jotka hoitaa virtualisointiympäristöjä.
Linux puolella ei muutenkaan kiinnosta pahemmin olla päivittelemässä vain sen päivittämisen ilon takia, joten seuraava päivitys näiden johdosta on sitten hyppäys 4.x kerneliin niin siinä tulee varmasti muutakin säätämistä ajureiden, asetusten, virtuaaliverkkojen jne kanssa.
Itselläni kone ei kyllä kaadu nätisti GSOD tai vastaavasti vaan tekee suorilta jaloilta IVO buutin. Toistaiseksi mitään ei ole kadonnut tai hajonnut. Ehkä sitä vain on käynyt tuuri. Toisaalta tapahtumilla on toistaiseksi vain ajallinen korrelaatio. Voi tuossa koneessa olla jokin muukin ongelma vaikkei rautadiagnostiiikka mitään ole havainnutkaan. Selvinnee kun joskus ilmestyy paikot joiden jälkeen kaiken pitäisi toimia, tai kaatuilulle ilmenee jokin muu juurisyy.
Ja mitähän tunnistuksia virheellisille laskutoimituksille on prosessoreihin ilmestynyt? Ihme puolustelua Intelille, nythän ei ihan oikeasti voi enää kuin nauraa niitten räpeltmiselle 😀
@jive Oletko kokeillut vain vetäistä takaisin aiempaa versiota, niin sittenhän sen näkisi onko tuosta vai jostain muusta kiinni?
Kerran tunnissa kuullostaa kyllä melkoiselta.
Ollut jo todella kauan mm. seuraavat:
Nollallajaosta seuraa poikkeus (jonka käsittelijä oletuksena kaataa ohjelman)
Laittomasta muistiaccessista seuraa poikkeus(jonka käsittelijä oletuksena kaataa ohjelman)
Välimuisteissa on pariteettitarkastus
Muisteissa voi olla pariteettitarkastus.
Puolustan mitä tahansa firmaa kun fanipojat postaa niistä mutupaskaa.
Intel on toki mokannut selvästi spectre-patchinsä kanssa, mutta se, jos joku vaikka selvänä kolaroi autolla aiheuttaen pienen peltivaurion, ei oikeuta syyttämään häntä vaikka rattijuopumuksesta sillä perusteella että usein kolarit tapahtuu kännissä.
Muistivirheille toki, ei laskutoimituksille. Ja tosiaan nyt kaatuu koko prosessori eikä ohjelma niinkuin virhetilanteen käsittelijällä tapahtuisi – Intel tosiaan laski epävakaan prosessorin firmwaren pihalle, jostain syystä näet hirmu tarpeen puolustella isoa firmaa em. nolosta virheestä varsin ihmeellisillä perusteluilla.
@copter käytän konetta konekaniinina työkoneelle. En ole toisaalta myöskään pahemmin tutkinut mahtaako Dell antaa koneen softia ruuvata taaksepäin.
Jos yhtään ymmärtää mitä asioita tässä patchissä on muutettu, niin pitäisi tajuta, että siinä ei ole muutettu mitään prosessorin datapolulla suoritettavia laskutoimituksia. Siinä on muutettu sitä, miten prosessorin haarautumisenennustus toimii epäsuorien hyppyjen kanssa, ja mistä osoitteista käskyjä voidaan spekulatiivisesti päätyä lataamaan.
Minä en ole missään väittänyt, että intel ei olisi mokannut.
Minä olen "puolustellut" inteliä ainoastaan virheellisiä syytöksiä kohtaan.
Vähän sama, kuin että sinä olisit ajanut sen pienen peltikolarin(jossa tulee pieniä peltivaurioita), mutta sinua syytettäisiinkin kuolemantuottamuksesta, koska naapurin mummo sai sydänkohtauksen kuultuaan kolarin aiheuttaman pamauksen.
Ja sitten kun joku yrittää puolustaa sinua, että "ei sen mummon kuolema nyt ollut sinun syytäsi, olet syyllinen ainoastaan auton lommoon" niin sitten valitetaan että puolustelijalla täytyy nyt olla jotain omaa piilotettua agendaa kun KEHTAA TUOLLAISTA KOLAROIJA-TAPPAJAA PUOLUSTAA!
Intel mokasi. Mutta ei niin pahasti kuin sinä yrität väittää.
No on se vähä meh että koko kone kippaa vs että prosessi kippais. Sanosin että ei nyt ihan pikku kävystä ole kuitenkaan kyse.
Oman työdellin biosin pystyi ainakin päivittämään vanhempaan. Aiemmin asentamani tammikuussa julkaistu spectre-korjattu bios olikin poistunut lataussivulta.
Tämä Riitaoja ei taida olla sen toisen foorumin Riitaoja?
No joka tapauksessa Intel tiesi SPECTRE haavoittuvuudesta 1. kesäkuuta. OEM:t saivat tietoa 30 lokakuuta. Luulisi että Intelillä olisi ollut aikaa testata korjaustaan. Tosin nyt kun tuohon lokakuun päivään ajoittuu tietty osakkeiden myyntiin laittaminen, niin foliohattu päässä voi alkaa epäilemään, että sitä ei pysty edes microkoodilla korjaamaankaan, vaan tämä korjaus on vain joku ihmisten(osakkeenomistajien) rauhoittelemis yritys.
Itsellä kanssa Dellin business läppäri antoi rollata takaisin, mutta palvelimista en tiedä. Voisi kuvitella että onnistuu.
Ei se prosessinkaan kippaus kyllä mitenkään tajuttomasti lämmitä. Tietysti riippuu että mikä prosessi, mutta joku *nix serveri jossa sshd ja management prosessi kippaa, niin mieluummin sit melkeen saa bootata koko kone kuin että jäis brickkinä sinne verkkonpainoksi. 🙂
Juu ei, mutta yleensä se on pienempi paha kuin se että vetäsee koko vehkeen boottiin. Onneksi kuitenkaan ei taida jättää jumiin laitetta.
Mitä sille haarautumisennustukselle voi mikroodilla tehdä? Ei yhtään mitään(no voidaan kytkeä kokonaan pois) vaan nimenomaan prosessorin laskutoimituksia muutetaan, tiettyjen käsky-yhdistelmien suoritusaikoja/järjestystä/ajoitusta muutetaan jotta side-channel hyökkäyksistä ei saada dataa pihalle ainakaan kernelistä, ainakaan jos kernelikin on pätsätty yhteensopivaksi.
:facepalm:
Yrittäisit edes ottaa asioista selvää.
Käyttöjärjestelmäkutsu(INT) on se mikrokoodilla suoritettava käsky, jonka toimintaa spectre-patch muuttaa. Tämän käskyn toimintaa muutettiin siten, että se muun toiminnan lisäksi flushaa osittain BTBn (ilmeisesti siitä osan RSB, return stack buffer)
Samoin ilmeisesti poikkeusten toimintaa muutettiin siten että aina (ennen) kun mennään käyttöjärjestelmän poikkeuskäsittelijään, tehdään sama osittainen BTB-flush. (poikkeuksen heittäminen on myös sen verran monimutkainen asia, että siihen joka tapauksessa myös aina liityy mikrokoodia)
Näiden yhteisvaikutus on se, että user-tilassa tehdyt ennustukset eivät vaikuta kernel-tilassa haarautumisennustimeen, koska BTBn olennaiset osat on aina flushattu välissä. Tällöin prosessoria ei saa suorittamaan spekulatiivisesti haluttua koodia kernel-tilassa, mihin perustui specren 2.variantti.
Näissä patcheissä ei missään yritetä heikentää minkään ajastimien toimintaa siten että side channel ei toimisi koska tarpeeksi tarkkoja ajastuksia ei saada. Se olisi aivan järjetön suo, eikä suojaisi kuitenkaan mitenkään, ellei käytännössä koko välimuistia poistaisi käytöstä, koska aina tekemällä tarpeeeksi monta lukemista ja laskemalla niiden keskiarvoja voisi kuitenkin päätellä jotain.
Pakkohan se flushaus fiksi on tuoda, sillä on erittäin epätodennäköistä että Intel vaihtaisi läjäpäin prossuja uusiin. Ja eipä nuo uudet prosessori revisiot ihan nopeasti kuitenkaan synny, jos hw-fiksi tulisi jo nyt nyt voisi olettaa että Intel olisi tietänyt ongelmasta hyvin paljon tiedossa olevaa ajankohtaa aiemmin. Siitäkin riemu voisi revetä.
Niin, pakko se oli tuoda.
Mutta Intelin tapa tuoda se oli monelta osin ongelmallinen, tuo vakausbugi ei ollut ainoa ongelma siinä. Muut ongelmat on siis enemmän "poliittisia" tai siis "ylläpidollisia", aiheuttaa päänvaivaa esim. Linusille.
No nyt kyllä voisit lukea omat sepustuksesi ajatuksella ja järjestyksessä ja katsoa peiliin 🙂
Luin kyllä tekstini itse useaan kertaan, eikä ole mitään tarvetta katsoa peiliin.
Sen sijaan, että sinä olisit yrittänyt ymmärtää, luovutit?
Mikä meni yli, mitä et ymmärtänänyt? epäsuora haarautuminen? BTB? mikrokoodi? user- ja kernel-tilan ero ja niiden välillä siirtyminen?
Alkaen ihan alusta : Intelin mikrokoodipäivitys on epävakaa. Tähänhän on ihan vahvistus Inteliltä itseltään, unexepted system behaviour….
Ei ole muutettu mitään prosessorin datapolulla suoritettavia laskutoimituksia….. Millähän se BTB-flush suoritetaan jos ei datapolulla suoritettavilla käskyillä? Intel osannut varautua ja tehnyt BTB-flush käskyn arkkitehtuuriinsa 😀
BTB-flushaus ei ole LASKUTOIMITUS. Sitä ei suoriteta missään ALUssa. BTB sijaitsee efektiivisesti liukuhihnan 0-vaiheessa. ALUt sijaitsee efektiivisesti liukuhihnalla n. 15. vaiheessa.
Haarautumisyksiköistä on toki kytkennät BTB:hen, mutta haarautumisyksikkö on eri asia kuin ALU.
Tietysti siellä on rajapinnat kaiken flushaamiseen ja pois päältä kytkemiseen mikrokoodista. Juuri sen takia, että jos jossain on bugi, se saadaan kierrettyä.
Sellaisetkin tietorakenteet saa pois päältä, joiden pois päältä ottaminen hidastaisi prosessorin vaikka kymmenesosaan normaalista, ihan sen takia, että kun prosessorista tehdään ensimmäinen prototyyppisarja, jos siinä on joku tällainen fataali bugi jonka kiertäminen hidastaa prossun vaikka kymmenesosan normaalista, voidaan se bugi kiertää ja jatkaa prosessorin testaamista ja muiden bugien etsimistä jotta voidaan löytää 20 muuta bugia ja korjata kaikki kerralla, että kun 2kk päästä saadaan korjattu versio piiristä ulos, siinä voidaan korjata 21 bugia kerralla eikä koko testaus jumita sen YHDEN ekana vastaan tulleen bugin takia. Aika iso ero, saadaanko 21 bugia korjattua 2 kuukaudessa vai 21*2 = 42 kuukaudessa.
AMDllähän oli Zenin kanssa juuri joku tällainen:
Chipmaker AMD Makes a Big Bet on Brand-New Tech
Eka zen-prototyyppisarja ei toiminut ollenkaan. Piirisuunnittelussa onnistuttiin tosin vähän oikomaan ja korjattu malli saatiin pihalle jopa kuukaudessa, mutta seuraava lause on se joka liittyy tähän:
Eli piiristä onnistuttiin kytkemään pois päältä jotain hyvin fundamentaalista ja testausta jatkamaan heti, odottamatta edes sitä kuukautta.
BTB flushaus nimenomaan on laskutoimitus. Suoraan softasta tehtynä useamman tuhannen käskyn laskutoimitus. Toki koko Brach-predictionin saa pois päältä mutta nopeusvaikutus on niin suuri että sitä ei voi edes harkita joten on käytettävä muita kiertoteitä. Mikrokoodilla em. flushaus saadaan optimoitua viimeisen päälle mutta mokoma mörkökoodi näyttääpi aiheuttavan monelle prosessoriyksilölle vakausongelmia.
Sinulla tuntuu olevan vaikeuksia ymmärtää, mitä "laskeminen" merkitsee, ja digitaalitekniikan perusteetkin (jotka opetetaan teknillisissä yliopistoissa ekana opiskeluvuonna) tuntuu olevan pahasti hakusessa.
BTB on tehty kiikuista, ja kiikuista löytyy reset-signaali.
Sen reset-signaalin nostamiseen ei tarvi laskea yhtään mitään. Ei tarvita tuhansia mikrokoodikäskyjä. Yksi mikrokoodikäsky asettaa yhden linjan ylös, ja se välittyy jokaiselle alkoille siinä osassa BTBtä mikä flushataan. Kaikki tyhjenee samalla kellojaksolla. Koko hommaan voidaan tarvia muutama mikrokoodikäsky, koska voidaan haluta esim. varmistaa että joku ei lue tai kirjoita sitä BTBtä samalla kellojaksolla, kun sitä resetoidaan, eli ensin voidaan joutua suorittamaan mikrokoodikäsky joka varmistaa, että mitään käskyä ei varmasti ladata sisään eikä mitään tulosta varmasti kirjoiteta TBThen seuraavalla kellojaksolla.
Tai voi olla että BTB on jaettu useampaan osaan joita ei kaikkia saa resetoitua samalla reset-signaalilla joten voidaan joutua suorittamaan muutama flushauskäsky. Ei tuhansia.
Ja nykypiireillä haarautumisenennustimia on vaikka kuinka monta ja joidenkin tehtävä on vain ennustaa, mikä ennustin on se tässä tilanteessa tarkempi. Käytännössä kaiki voi varmasti disabloida erikseen. Ja haarautumisia on kolmea eri tyyppiä (ehdoton suora, ehdollinen suora, ehdoton epäsuora) joiden suhteen BTB toimii melko eri tavalla.
Juuri missään tilanteessa ei olisi tarvetta disabloida haarautumisenennustinta kokonaan ellei sitten bugi olisi haarautumishudista toipumisessa (K5n ekassa mallissa tilanne oli ilmeisesti tämä).
Mitä paskaa taas horiset? Haarautumisenestoyksikkö on oma itsenäinen osansa ja miksi ihmeessä millään erillisellä käskyllä olisi tarvetta päästä sen sisäisiin taulukoihin käsiksi, saati sitten resetoimaan niitä? Eli ainoa keino tyhjentää BTB-taulukot lienee joko flushata prossun kaikki cachet tai ajaa prossun läpi koodinpätkä joka päivittää taulukot. Tätä jälkimmäistähän Intelin microkoodipäivitys harrastaa viimeisen päälle optimoituna siitä seuraavine ongelmineen.
Juuri selitin, bugien korjaamiseksi KAIKESTA tehdään sellaista että sen saa pois päältä tai flushattua.
Yksi reset-singaali, yksi disable-singaali.
Ja SINÄ nimenomaan väitit että sen sisäiseen taulukoihin voisi päästä käsiksi, kun rupesit höpöttämään mutupaskaa siitä että niitä flushattaiisiin yksi kerrallaan tuhansien käskyjen ajan. Sekä edellisessä viestissäsi että tuossa alla.
Hienoa logiikkaa, samassa viestissä sekä väität että jotain tehdään jollain tavalla että kiistät sen rajapinnan olemisen, millä sen voi tehdä 😀
… juuri ylempänä selität, että sellaisia ksäkyjä ei voi olla, joilla tämä koodinpätkä sen tekisi, koska haarautumisyksikkö on erillään datapolusta 😀
Niinkuin oikeasti. Ymmärrän, että et ole opiskellut digitaali- tai tietokonetekniikkaa, etkä oikeasti ymmärrä miten nykyaikaiset prosessorit toimivat, mutta voisitko edes YRITTÄÄ YMMÄRTÄÄ ja voisitko edes YRITTÄÄ OLLA LOOGINEN siinä millaiseksi prosessorin rakenteen kuvittelet?
Voisko tuon riitelyn välissä , joku , kuka vaan selittää , mitä tämä MS ohjelma tekee
https://support.microsoft.com/en-us…-disable-mitigation-against-spectre-variant-2
Mikä tällä kertaa sekoaa , entä aikaisemmat updatet Winukka työnsi noita väkisin kuun alussa
Meneekö haarautumisen ennustus pois päältä, jos ottaa hyperthreadingin pois käytöstä?
Ei.
Poistaa Intelin uuden mikrokoodin tueksi julkaistun Windows-päivityksen, koska Intelin mikrokoodissa on rebootteja aiheuttavia ongelmia
Microsoftin uusi päivitys poistaa Spectren kakkosvariantin paikan Intel-kokoonpanoilta – io-tech.fi
Pitäisiköhän tuolla etusivun oikeassa reunassa olla nostona KPTI-uutiset? Voisi vähän helpottaa uutisten löytämistä.
Löytyy painamalla KPTI-tagia uutisessa sekä tämän ketjun ensimmäisestä viestistä
Onko kukaan tietoinen siitä, että meinaako Intel tehdä spectretulpan vai ei? Jotenkin vaan soudetaan ja huovataan eikä mitään saada tehtyä asialle.
Onko tiedossa haittaohjelmia, jotka tuota hyödyntää ja voiko itse windowsin ominaisuuksia poistamalla tai rekisteriä puukottamalla estää mahdollisen spectrepöpön asettumista omalle koneelle?
Mielestäni tonne ensimmäiselle sivulle voisi jokaisen uutislinkin alle linkata myös että mistä viestinumerosta alkaen kyseistä uutista on täällä forumilla spekuloitu. Melkonen homma tässä kohtaa mutta tää ketju alkaa olla niin pitkä jo että noiden aiempien uutisten aikasia kommentteja löydä täältä enää kukaan.
Sen lisäksi ihmetyttää tää viimesin "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."
Että mikähän paikka, peittääkö ne bios päivityksissä tulleita juttuja vai omia paikkoja, mun tiedon mukaan Microsoft ei ole julkassu muuta ku meltdown paikkoja toistaiseksi??
Kyllä tämä kommenttiosio on mennyt niin sekavaksi, ettei oikein pysy perässä.
Eikö näihin uutisaiheisiin olisi voinut olla niin, että foorumissa näkyisi:
Spectre- jne. uutiset
Helpottaisi kummasti lukemista.
Ekassa versiossa havaittiin ongelma. Ongelmaa tutkittiin ja syy ongelmaan ilmeisesti selvisi. Uusi versio paikkauksesta on valmistumassa.
Tällähetkellä ei ole tiedossa haitakeita, jotka käyttäisivät tuota. Tuo kun ei ole kovinkaan "hyödyllinen" ominaisuus, koska sen avulla ei voi esim suorittaa ohjelmia.
Parhaiten lisäät tietoturvaa pistämällä koneelle ohjelman, joka blokkaa kaikkien sivustojen kaikki ylimääräiset scriptit ja mainokset. Nopeuttaa muutenkin netin käyttöä huimasti ja pienentää selainten prossu ja muistikuormaa todella rajusti.
Ko spektre paikka muodostuu sekä mikrokoodipätsistä, että käyttispuolen muutoksesta.
Steve gibson suositteli meltdown paikkausta ja sanoi että spectre paikkausta ei tarvitse, sillä sen saa on/off.
Vaikka muutama käyttäjä täällä huutelee että meltdown patsia ei tarvita eikä ole ollenkaan haitallinen ja on hitaasti hyödynnettävissä. 😆
Heh, löytyi "ajankohtainen" postaukseni murosta aiheesta melkein viiden vuoden takaa, tässä oleellinen kohta postausta
Tuon jälkeen olen hiukan oppinut ymmärtämäään lisää noiden poikkeusten heittämisestä, mutta osoittautui tosiaankin vieläkin ongelmallisemmaksi kuin mitä tuolloin osasin ajatella siinä mielessä, että se intelin tapa tehdä tuo arkkitehtuurillisesti oikein ei kuitenkaan ollut ongelmaton 😉
Taas hätäisimmät menivät vanhaan ansaan (microsoftin päivitysten poistot).
Niin siinä sodassakin käy että vihreä innokas moku ottaa ekana osumaa.
koska lataus voi aina johtaa virtuaalimuistin läsnäolopoikkeukseen, ja jos latausta ei olisikaan pitänyt suorittaa, ei sitä poikkeusta olisi pitänytkään heittää
Todella mielenkiintoista. Voi ja jos? missä tilassa. Onko mitattavissa ja todennettavissa?
Meinaan vaan että se läsnäolopoikkeuskin voi olla todella kaukaa haettua spekula saavisuutta.
Asioiden heittelyä hurjalla menolla ja tietämystä toki on sen verran että voi nimetä asian sieltä täältä.
No
Ratkaisu tuohon on siis se, että poikkeukset heitetään vasta, kun käsky saapuu "retire"-vaiheeseen(joka on siis liukuhihnan viimeinen vaihe). Ja kaikki mitä käskyt tekee, voidaan perua kun käskyä ei ole vielä retiretty.
Ja retire siis tehdään kaikille käskyille taas alkuperäisessä ohjelmakoodin mukaisessa järjestyksessä. Eli haarautumisen jälkeinen käsky voi retirettää vai jos haarautuminen on onnistuneesti retiretty ensin.
Ja jos haarautumista tarkistettaessa haarautumisenennustus osoittautuu vääräksi ja on suoritettu käskyjä, joita ei olisi pitänyt suorittaa, tässä vaiheessa perutaan ne ja heitetään ne bittitaivaaseen liukuhihnalta ja aloitetaan tyhjältä hihnalta uusien suorittaminen oikeasti paikasta.
Eli se haarautuminen on tarkastettu aina ensin ennen kuin sen jälkeen tuleva käsky voi retirettää, eli käsky, joka suoritettiin spekulatiivisesti mutta jota ei koskaan pitänyt suorittaa, ei koskaan mene retire-vaiheeseen asti vaan perutaan ja heitetään bittitaivaaseen liukuhihnalta ennen retire-vaihetta.
Ja tämä juuri selittää tuon meltdownin toiminnan. Yksinkertaisin toteutus aloittaa sen latauksen normaalisti, mutta kun virtuaaliosoitetta muuntaessa huomataan käyttöoikeusvirhe, se merkkaa vaan siihen käskyyn tiedon, että "tämä on laiton lataus", eikä heti tee mitään muuta sen seurauksena, ja sitten retire-vaiheessa tämä "laiton lataus"-tieto huomioidaan ja sen sijaan että käsky retireisi normaalisti, se heittää sen poikkeuksen.
Latauskäskyn suorituksen peruminen (kun huomataan se virheellinen haatautumisennustus) ei kuitenkaan poista sen käskyn välimuistille tekemiä asioita, vaan peruu vain sen aiheuttamat arkkitehtuurilliset tilanmuutokset, joten side-channel-hyökkäyksellä pystään havaitsemaan, mitä osoitetta on yritetty ladata mittailemalla muiden latausten suoritusajalla sitä, mikä kohta välimuistista on muuttunut yms.
AMDllä taas on jo siellä itse latausvaiheessa tarkastus, että jos osoite on laiton, keskeytetään heti sen lataus (mutta sitä poikkeusta ei silti saa nostaa heti, vaan se pitää merkata samalla tavalla heitettäväksi vasta retire-vaiheessa)
Kiitos suhteellisen tyhjentävästä vastauksesta.
Meille jäi ilmiselvästi kysymyksiä auki.
Haluan (vitsillä)että ylläpito tai sinä poistat tämän neuvoa antavan.