Meltdown- ja Spectre-haavoittuvuudet ovat olleet viime päivien kuumin puheenaihe. Nyt Intel on kertonut omasta edistymisestään haavoittuvuuksien paikkaamiseksi.
Intelin mukaan yhtiö on partnereidensa kanssa saanut valmiiksi haavoittuvuudet paikkaavia päivityksiä suurimmalle osalle yhtiön tuotteista. Mikäli aikataulut pitävät, lupaa yhtiö ensi viikon loppuun mennessä saada julkaistuksi päivitykset peräti 90 prosentille prosessoreista, joita se on julkaissut viimeisen viiden vuoden aikana.
Käyttäjät joutuvat kuitenkin odottamaan päivityksiä hieman pidempään, sillä Intel jakaa omat päivityksensä kumppaneillensa eikä loppukäyttäjille. Käyttäjät joutuvat siten odottamaan, että heidän tietokoneensa tai emolevynsä valmistaja julkaisee päivityksen, johon on sisällytetty Intelin korjaukset. Osa päivityksistä tulee luonnollisesti myös käyttöjärjestelmäpäivitysten mukana. Intel kehottaakin kaikkia käyttäjiä pitämään automaattiset päivitykset päällä niin käyttöjärjestelmän kuin muidenkin mahdollisten sovellusten kohdalla, jotta päivitykset asentuvat mahdollisimman nopeasti.
Lähde: Intel Kuva: Paul Pearce @ Twitter
Eikös applella ole ne rahat jossain veroparatiiseissä ja niiden "oikeaoppinen" kotiuttaminen aiheuttaisi kivat verot jonka takia se ei sitä tee?.Applella taitaa tarkoitus olla se että voitot kerätään osakkeita myymällä.
Oliko jo? Google julkaissut Chrome 64 missä vähän mitigationii näitä reikiä varten.
Google Chrome now lets you permanently mute annoying websites
Chrome Releases: Stable Channel Update for Desktop
EDIT: Niin, onhan tuosta jo peräti 3 päivää aikaa. Nyt vasta tuli vastaan. 😀
EDIT2: Onkohan nyt jotain lisähyötyä jos pitää päällä Chrome asetusta "Strict site isolation"? Googlehan ennen tätä v64 kirjoitti että sillä pysty jo silloin vaikeuttaa aukon hyödyntämistä.
Kellään tietoa?
Käsityksesi meni kyllä metsään: http://www.nasdaq.com/symbol/aapl/dividend-history
Mutta ei paljoa. Tuon mukaan Apple ei maksanut osinkoja 17 vuoteen yhdessä välissä.
Rupesivat maksamaan osinkoja siinä vaiheessa kun eivät enää keksineet rahalle muuta käyttöä.
Erään arvion mukaan tänä vuonna toimitetaan noin 26 miljoonaa serveriprosessoria.
Can EPYC Server Processors Boost AMD's Value By 25%?
Tuosta laskettuna, AMD saisi halutessaan tehtyä 42 miljoonaa Epycciä.
Jotta asia ei olisi niin yksinkertainen:
– AMD saa halutessaan käyttöön kaiken GlobalFoundriesin 14nm kapasiteetin, koska muita merkittäviä asiakkaita sille prosessille ei ole
– Samsungilla on vapaata kapasiteettia 14nm LPP:lle
– AMD valmistaa samalla prosessilla myös näytönohjainpiirejä
– GlobalFoundries tiettävästi laajensi tehdastaan
– Ei tiedä syökö 12nm valmistusprosessi 14nm kapasiteettia
– Tuossa 26 miljoonassa on luultavasti mukana myös muut kuin x86 palvelin CPU:t ja siinä on AMD:n osuus mukana
– 25% hukka on aika korkealle arvioitu
Nämä summattuna, tuotantopuolesta ei AMD:lla homma kovinkaan pahasti jää kiinni. Ja mikäli tavoitteena olisi esim. "vain" 25% palvelinmarkkinoista (6,5 miljoonaa Epycciä), valmistuskapasiteetti on ongelmista pienimmästä päästä.
Sillä ei ole AMD:n kannalta juuri mitään merkitystä elleivät käytä 14nm LPP:ta. 28nm APU piirien kysyntä on sen verran pientä ettei paljoa AMD:ta haittaa vaikka mainerit veisivät suuren osan 28nm kapasiteetista.
Kiitos hyvästä selvityksestä. Luin jonkun "asiantuntijan" kommenteista että tuo olisi tehnyt asiat selvästi yksinkertaisemmiksi. Taisi olla huuhaata se juttu.
Mikäli olen oikein käsittänyt, Athlon64 ei kärsi Meltdownista (paitsi rikkinäisen päivityksen muodossa) eikä myöskään FX. Bulldozer johdannaisten kanssahan Kellerillä ei ole mitään tekemistä. Athlon 64:a vanhemmista prosessoreista en jaksa hakea tietoa.
Vaikuttaa kuitenkin siltä että AMD on viimeistään Kellerin suunnitellessa Athlon64:a ottanut asian huomioon ja koska Bulldozerissa ja Ryzenissä on sama homma, tuo lienee asioita joita AMD on tehnyt tarkoituksella pidemmän aikaa. Vaikea sanoa kuka tajusi mutta ilmeisesti joku koska ainakin kolmessa peräkkäisessä täysin erilaisessa arkkitehtuurissa asia on otettu huomioon.
Monimutkaisempi huomioiden aikakauden. Ei Pentium Pro:ta voi absoluuttisessa monimutkaisuudessa kunnolla verrata. Toisaalta AMD kertoi Ryzenin kohdalla simulointityökalujen kehittyneen huomattavasti vanhoista ajoista, jolloin suunnilleen piti valmistaa prosessori jotta tiesi mitä sai. Siinä mielessä Pentium Pro oli suhteessa aikakauteen ja käytettävissä oleviin työkaluihin monimutkainen prosessori.
Kuullut että biospäivitykset ovat porukalla jumittaneet koneita ja/tai boottailleet.
En ollut asentamassa.
Olikos tämä jo täällä:
Intel promises Spectre- and Meltdown-proof chips this year
Saas nähdä pitääkö paikkaansa ja mitä sieltä lopulta tulee ja milloin.
@Kautium
Asiasta uutoisitiin jo perjantaina
Intel lupaa Spectre- ja Meltdown-korjatut prosessorit markkinoille vielä tänä vuonna – io-tech.fi
Pidetään kuitenkin se mielessä, että missään ei ole sanottu, että tänä vuonna luvatut prosessorit olisi Core-sarjaa tai että yritysasiakkaat saisi patchättyjä Xeon-prosessoreita oikeasti käyttöön. Se, mitä Google Project Zero on asiasta antanut ymmärtää, on aika paljon ristiriidassa tämän Intelin lausunnon kanssa tuoda patchätyt prosessorit ulos näin nopealla aikataululla.
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. Ei varmasti naurata serverien ylläpitäjiä eikä Intelin johtoa.
Siis miten hätäinen reaktio pitää olla että serveripuolelle julkaistaan epävakaa mikrokoodi prossulle, onko Intel säästänyt koko laadunvalvontapuolensa ulos vai mitä, ei tälläistä ihan oikeasti pitäisi voida sattua edes pienemmissä puljuissa.
: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älimuistin 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, vaan sama efekti kuin mikä tulee jos vaan panaa koneen reset-nappit tai tekee IVO-resetin.
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 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ä.
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".
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?
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 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 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
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??