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

[jive]

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.

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.

 

[Sami Riitaoja]

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

 

[copter]

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

 

[hkultala]

Ja mitähän tunnistuksia virheellisille laskutoimituksille on prosessoreihin ilmestynyt?

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.

Ihme puolustelua Intelille, nythän ei ihan oikeasti voi enää kuin nauraa niitten räpeltmiselle

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

 

[Sami Riitaoja]

Ollut jo todella kauan 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.

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.

 

[jive]

@copter käytän konetta konekaniinina työkoneelle. En ole toisaalta myöskään pahemmin tutkinut mahtaako Dell antaa koneen softia ruuvata taaksepäin.

 

[hkultala]

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,

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.

jostain syystä näet hirmu tarpeen puolustella isoa firmaa em. nolosta virheestä varsin ihmeellisillä perusteluilla.

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

 

[jsa]

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.

 

[plugg]

@copter käytän konetta konekaniinina työkoneelle. En ole toisaalta myöskään pahemmin tutkinut mahtaako Dell antaa koneen softia ruuvata taaksepäin.

Oman työdellin biosin pystyi ainakin päivittämään vanhempaan. Aiemmin asentamani tammikuussa julkaistu spectre-korjattu bios olikin poistunut lataussivulta.

 

[Stephen Elop]

Intel mokasi. Mutta ei niin pahasti kuin sinä yrität väittää.

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.

 

[copter]

@copter käytän konetta konekaniinina työkoneelle. En ole toisaalta myöskään pahemmin tutkinut mahtaako Dell antaa koneen softia ruuvata taaksepäin.

Oman työdellin biosin pystyi ainakin päivittämään vanhempaan. Aiemmin asentamani tammikuussa julkaistu spectre-korjattu bios olikin poistunut lataussivulta.

Itsellä kanssa Dellin business läppäri antoi rollata takaisin, mutta palvelimista en tiedä. Voisi kuvitella että onnistuu.

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.

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.

 

[jsa]

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.

 

[Sami Riitaoja]

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.

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.

 

[hkultala]

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.

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 haarautumisennustimen epäsuorien hyppyjen ennustimeen, koska BTBn olennaiset osat on aina flushattu välissä. Tällöin prosessoria ei epäsuorilla hypyillä saa suorittamaan spekulatiivisesti haluttua koodia kernel-tilassa, mihin perustui specren 2.variantti.



Tämä "korjaus", vaikka toimisi eikä sisältäisi tuota vakausbugia, olisi kuitenkin siitä huono, että se RSB:n data on hukattu aina kernel-kutsun jälkeen, jolloin kernel-kutsuissa ja niiden jälkeen haarautumisenennustin ennustaa huonosti. Kunnollinen korjaus olisi sellainen, että RSBn data tagattaisiin paremmin siten että user-tilassa sinne talletettu data ei vaikuttaisi kernel-tilassa tehtyihin haarautumisiin, mutta se data voitaisiin säilyttää.
Tätä tagaamista ei kuitenkaan mikrokoodipatchillä voi tehdä, koska se vaatii uusia bittejä tuonne RSB-tietorakenteeseen. Tämä "kunnollinen, hidastamaton" korjaus vaatii uuden version prosessorista valmistamisen.

Ja Linus on tästä haukkunut intelin, koska intelin tapa tuoda tuo mikrokoodi vaikuttaa siltä, että Intel on täysin tyytyväinen ratkaisuunsa ja pitää sitä jopa "hienona" eikä ole mahdollisimman nopeasti tuomassa tätä "oikeaa korjausta" RSB-tagibittien muodossa prosessoreihinsa vaan aikoisi jatkaa tuon hidastavan flushaus-workaroundinsa kanssa pitkään.



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, vaikka ajoitukset vähän heittäisikin.

 

[jsa]

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

 

[hkultala]

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.

 

[Sami Riitaoja]

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 haarautumisennustimen epäsuorien hyppyjen ennustimeen, koska BTBn olennaiset osat on aina flushattu välissä. Tällöin prosessoria ei epäsuorilla hypyillä saa suorittamaan spekulatiivisesti haluttua koodia kernel-tilassa, mihin perustui specren 2.variantti.



Tämä "korjaus", vaikka toimisi eikä sisältäisi tuota vakausbugia, olisi kuitenkin siitä huono, että se RSB:n data on hukattu aina kernel-kutsun jälkeen, jolloin kernel-kutsuissa ja niiden jälkeen haarautumisenennustin ennustaa huonosti. Kunnollinen korjaus olisi sellainen, että RSBn data tagattaisiin paremmin siten että user-tilassa sinne talletettu data ei vaikuttaisi kernel-tilassa tehtyihin haarautumisiin, mutta se data voitaisiin säilyttää.
Tätä tagaamista ei kuitenkaan mikrokoodipatchillä voi tehdä, koska se vaatii uusia bittejä tuonne RSB-tietorakenteeseen. Tämä "kunnollinen, hidastamaton" korjaus vaatii uuden version prosessorista valmistamisen.

Ja Linus on tästä haukkunut intelin, koska intelin tapa tuoda tuo mikrokoodi vaikuttaa siltä, että Intel on täysin tyytyväinen ratkaisuunsa ja pitää sitä jopa "hienona" eikä ole mahdollisimman nopeasti tuomassa tätä "oikeaa korjausta" RSB-tagibittien muodossa prosessoreihinsa vaan aikoisi jatkaa tuon hidastavan flushaus-workaroundinsa kanssa pitkään.



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, vaikka ajoitukset vähän heittäisikin.

No nyt kyllä voisit lukea omat sepustuksesi ajatuksella ja järjestyksessä ja katsoa peiliin

 

[hkultala]

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änyt? epäsuora haarautuminen? BTB? mikrokoodi? user- ja kernel-tilan ero ja niiden välillä siirtyminen?

 

[Sami Riitaoja]

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

 

[hkultala]

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ä(jotka sijaitsee myös n. 15. vaiheessa) on toki kytkennät BTB:hen, oikean haarautumistuloksen välittämiseksi sille.


Ja tietysti siellä on rajapinnat kaiken flushaamiseen ja pois päältä kytkemiseen mikrokoodista. Juuri sen takia, että jos jossain on bugi, se saadaan kierrettyä.

Phenomissakin oli rajapinta mikrokoodilla kieltää TLBn fillaaminen välimuistista, kun välimuistin koherenssiprotokollassa oli pieni bugi joka vaikutti TLBn fillaamiseen.



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:

"And Castro’s team figured out how to get around the flaw for testing, avoiding losing even just that month."

Eli piiristä onnistuttiin kytkemään pois päältä jotain hyvin fundamentaalista ja testausta jatkamaan heti, odottamatta edes sitä kuukautta.

 

[Sami Riitaoja]

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

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.

 

[hkultala]

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

 

[Sami Riitaoja]

Sinulla tuntuu olevan vaikeuksia ymmärtää, mitä "laskeminen" merkitsee, ja digitaalitekniikan perusteetkin 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.

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.

 

[hkultala]

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

Juuri selitin, bugien kiertämiseksi ja testaamisen helpottamiseksi KAIKESTA tehdään sellaista että sen saa pois päältä tai flushattua.
Yksi reset-signaali ja yksi disable-signaali per asia.

Ja SINÄ nimenomaan efektiivisesti 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ä

Eli ainoa keino tyhjentää BTB-taulukot lienee joko flushata prossun kaikki cachet tai ajaa prossun läpi koodinpätkä joka päivittää taulukot.

... juuri ylempänä selität, että sellaisia käskyjä 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 KONSISTENTTI siinä millaiseksi prosessorin rakenteen kuvittelet?

 

[El eks]

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

 

[Fenotype]

Meneekö haarautumisen ennustus pois päältä, jos ottaa hyperthreadingin pois käytöstä?

 

[Kaotik]

Meneekö haarautumisen ennustus pois päältä, jos ottaa hyperthreadingin pois käytöstä?

Ei.

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

Poistaa Intelin uuden mikrokoodin tueksi julkaistun Windows-päivityksen, koska Intelin mikrokoodissa on rebootteja aiheuttavia ongelmia

 

[Kaotik]

Microsoftin uusi päivitys poistaa Spectren kakkosvariantin paikan Intel-kokoonpanoilta - io-tech.fi

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

 

[aleksejjj]

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

 

[Kaotik]

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ä

 

[ANTI_L]

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?

 

[Zen_8400]

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??

 

[djtob]

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

• Aliuutiset + kommentit
• Aliuutiset 2 + kommentit
• Jne?

Helpottaisi kummasti lukemista.

 

[Griffin]

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?

Ekassa versiossa havaittiin ongelma. Ongelmaa tutkittiin ja syy ongelmaan ilmeisesti selvisi. Uusi versio paikkauksesta on valmistumassa.

Tällähetkellä ei ole tiedossa haitakkeita, 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.

 

[Griffin]

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??

Ko spektre paikka muodostuu sekä mikrokoodipätsistä, että käyttispuolen muutoksesta.

 

[Fenotype]

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

 

[hkultala]

Heh, löytyi "ajankohtainen" postaukseni murosta aiheesta melkein viiden vuoden takaa, tässä oleellinen kohta postausta

Ja spekulatiivisen lataamisen kanssa pitää olla hyvin varovainen, 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ää. Noissa prossuissa on aika monimutkainen logiikka tämänkin hanskaamiseen noiden spekulatiivisten latausten kohdalla.

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

 

[”diginatiivi”]

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.

 

[”diginatiivi”]

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

 

[hkultala]

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

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)

 

[”diginatiivi”]

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.

 

[”diginatiivi”]

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)

Haluan tämän jäävän muistiin

 

[demu]

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 tästä selvennyksestä. Vasta nyt ymmärsin oikeasti, mistä Meltdownissa on kyse. Hajua toki oli, mutta käsitystä Intelin ja AMD:n eroista ei ollut. Luulisi tämän kuitenkin olevan Intelille kohtuulisen helppoa korjata.

Mutta: Kun havaitaan lataus laittomalta muistialueelta, miksi sitä koodihaaraa ei saisi samantien keskeyttää?
Tuolloinhan koodi toimii väärin (joko vahingossa tai tahallisesti), joten eikö koko ohjelman suoritusta saisi samantien tappaa (tai kai siitä jotenkin käyttöjärjestelmälle pitäisi ilmoittaa, jotta ei tapahtuisi täysin hallitsemattomaksi)?

 

[hkultala]

Kiitos tästä selvennyksestä. Vasta nyt ymmärsin oikeasti, mistä Meltdownissa on kyse. Hajua toki oli, mutta käsitystä Intelin ja AMD:n eroista ei ollut. Luulisi tämän kuitenkin olevan Intelille kohtuulisen helppoa korjata.

Mutta: Kun havaitaan lataus laittomalta muistialueelta, miksi sitä koodihaaraa ei saisi samantien keskeyttää?
Tuolloinhan koodi toimii väärin (joko vahingossa tai tahallisesti), joten eikö koko ohjelman suoritusta saisi samantien tappaa (tai kai siitä jotenkin käyttöjärjestelmälle pitäisi ilmoittaa, jotta ei tapahtuisi täysin hallitsemattomaksi)?

Se poikkeus pitää heittää oikeassa kohdassa, oikean käskyn jälkeen, siten että kaikki sitä ennen tulleet käskyt suoritetaan loppuun asti.
Suoritusvaiheessa käskyt voi olla suorituksessa eri järjestyksessä kuin alkuperäisessä koodissa, joten sitä ei voi tehdä vielä siellä.

Ja laiton lataus (tai muu poikkeus) ei aina tarkoita ohjelman tappamista.

Ohjelmaa saatetaan erimerkiksi ajaa debuggerissa, ja halutaan tarkat tiedot siitä, mikä se laiton käsky on, ja mitä osoitetta se käsittelee, ja suoritusta saatetaan haluta tällöin jopa jatkaa virheen jälkeen virheen analysoimiseksi paremmin.

Vielä yleisempi tilanne on "copy on write"-tekniikka muistinhallinnassa:


Copy on writen idea on se, että muistia säästetään sillä, että kaikki saman datan (yleensä täyttä nollaa) sisältävät vrituaalimuistisivut ohjataan osoittamaan samaan fyysiseen muistisivuun. Niin kauan kun kaikki vain lukee sitä, kaikki nämä eri virtuaaliosoitteet voivat käyttää samaa fyysistä osoitetta.

Mutta sitten johonkin näistä osoitteista suoritetaankin kirjoitus. Tämä hanskataan siten, että nämä virtuaalimuistisivut on merkattu read-onlyksi, ja kirjoituksen tapahtuessa kirjoituksesta lentää muistisuojausvirhepoikkeus. Käyttöjärjestelmän poikkeuskäsittelijä huomaa, että tässä on nyt kyse kirjoituksesta copy-on-write-sivuun (eikä "oikeasti laittomasta" kirjoituksesta jonka seurauksena ohjelma pitäisi tappaa), ja tekee tuosta muistisivusta uuden kopion(vareten tässä vaiheessa uuden fyysisen muistisivun). Se asettaa tuon virtuaalimuistisivun osoittamaan siihen uuteen kopioon, ja sallii sinne myös kirjoitukset. Sen jälkeen poikkeuskäsittelijä lopettaa ja palataan ohjelmaan (kohtaan juuri ennen tuota kirjoituskäskyä). Ohjelma suorittaa tuon kirjoituksen nyt uudelle fyysisen muistin sivulle ja jatkaa toimintaansa normaalisti.

Tämä "copy on write"-tekniikka on hyvin oleellinen nykyaikaisten käyttöjärjestelmien muistinkulutuksen optimoinnissa.



Ja jos muistiaccess ei ole laittomaan muistiosoitteeseen vaan puuttuvaan muistiosoitteeseen, kyseessä voi olla vain se, että se data tarvii ladata swapfilestä kovalevyltä (tai memory-mapatystä fileestä kovalevyltä). Näissäkin tapauksessa pitää ensin suorittaa kaikki sitä ennen alkuperäisessä koodissa olevat käskyt loppuun, sitten käyttöjärjestelmän siellä poikkeuskäsittelijässä ladata se data levyltä, ja sitten sen jälkeen jatkaa ohjelman suorittamista juuri siitä "puuttuvan muistin" accessin tekevästä käskystä.


Eli on paljon tilanteita, jossa ohjelmaa ei haluta sulkea poikkeuksen tullessa, ja poikkeuksen jälkeen ohjelman pitää jatkaa toimintansa juuri sen käskyn kohdalta, joka poikkeuksen aiheutti. (noita tilanteita on varmasti enemmän kuin nuo 3, mitkä tässä nyt nopeasti tuli mieleen)



Mutta se mitä siis voisi tehdä on, että heti kun huomataan että nyt tapahtuu jotain laitonta, ei edes lasketa sitä, vaan merkataan sen tuottamalle tulokselle että "laiton arvo" ja jos mitään yritetään laskea siten että joku inputti sisältää tämän markkerin, sitten niidenkin tuloksiksi tulee "laiton arvo". Tämä voi kuitenkin vaatia yhden bitin lisää, joko itse rekisterihin jotka niitä arvoja tallettaa tai johonkin kirjanpitoon.

Liukuluvuillahan tämä on ihan speksattu ominaisuus, liukuluku voi sisältää arvon "NaN" ("Not a number") joka tarkoittaa että se on saatu esim. jakamalla nolla nollalla.

 

[demu]

Tack. Viimeksi olen tehnyt ammatikseni ohjelmointia n. 19v 10 kk sitten, joten en ole jaksanut pysytellä ajan tasalla...

 

[copter]

Joskaan mitään järkevää sanottavaa itse asian tiimoilta minulla ei tähän ole, mutta sen olen huomannut tässä ajan saatossa että @hkultala ei pahemmin tänne koskaan mitään väärää infoa ole suoltanut minkään piireihin liittyvän asian tiimoilta, vaan tuntuu tietävän asiat erittäin perusteellisesti. Nämä hyvin informatiiviset ja jopa melkein tyhjentävät vastaukset jälleen kerran todistavat sen. Ihailtavaa että hän niitä tänne jaksaa näinkin ahkerasti kirjoitella.

Sinällään välillä on kyllä ihan hauska seurata jonkun "ei niin asioista perillä olevan" väittelyä @hkultala kanssa, kun tietää ettei se voi päätyä kuin yhteen lopputulokseen.

 

[mRkukov]

Suoritinhaavoittuvuutta hyödyntävien haittaohjelmien määrä räjähti, ainakin 130 näytettä löydetty

Tammikuun loppuun mennessä tietoturvasovellusten testaaja Av-test oli tunnistanut 139 eri haittaohjelmavarianttia, joissa hyödynnettiin Spectre- ja Meltdown-haavoittuvuuksia. Toistaiseksi valtaosa havaituista haittaohjelmista hyödynsi samaa aiemmin julkaistua proof-of-concept-koodia , joka on yleisesti jaossa. Haittaohjelmat oli suunniteltu niin Windowsille, MacOS:lle kuin Linuxillekin.

Lisäksi Av-test havaitsi ensimmäisen JavaScript-pohjaisen proof-of-concept-hyökkäyskoodin Spectre-haavoittuvuuteen.

Mukava tässä surffailla koneella, jossa tietää ongelman olevan. :/

 

[SatanTwister]

Kummastahan spectre variantista on nyt kyse? Ilmeisesti ykkösvariantista?

 

[Kerosiini]

Olen tässä pitänyt jo pidempään uBlockia medium modessa joten kolmannen osapuolen skriptit estetään oletuksena, luulisi auttavan ainakin niin kauan kun ei tule jonkun luotetun sivuston kautta jossa olen ne päästänyt läpi tai on suoraan ensimmäisen osapuolen skriptissä.

Korjattua biosia odotellessa.

 

[=JP=]

On kyllä taas melkonen clickbait otsikko Mikropiltillä! Mitään sen ihmeempää ei ole tullut, kunhan pelotellaan peruskäyttäjiä turhaan...