
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
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.
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.
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. 🙂
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.
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.
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 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.
: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 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.
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ä.
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.
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 🙂
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?
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 😀
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ä(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:
Eli piiristä onnistuttiin kytkemään pois päältä jotain hyvin fundamentaalista ja testausta jatkamaan heti, odottamatta edes sitä kuukautta.
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:
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.
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ä).
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.
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 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ä 😀
… 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?
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ä 😀
… 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?
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
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ä?
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
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. Tu kun ei ole kovinkaan hyödyllinen reikä, 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 😉