Spectre ja Meltdown ovat olleet viimepäivien kuumin puheenaihe IT-maailmassa. Suurimman osan huomiosta on saanut Intel, vaikka haavoittuvuudet koskevat myös muita valmistajia.
Spectre- ja Meltdown-haavoittuvuuksien paikkaamisen tiedetään vaikuttavan tietokoneiden suorituskykyyn. Se, miten paljon paikat suorituskykyä laskevat, riippuu ennen kaikkea tietokoneella tehtävistä tehtävistä. Suurimman suorituskyvyn laskut tapahtuvatkin lähinnä datakeskuksissa, joissa palvelimiin kohdistuu raskasta I/O-rasitusta.
Intel on julkaissut omat suorituskykytestinsä koskien kotikäyttäjien tietokoneita Windows-alustoilla. Testit on ajettu yhtiön kolmen viimeisen sukupolven prosessoreilla käyttäen erilaisia synteettisiä testejä. 8. sukupolven Coffee Lake -prosessoreilla ja 8. ja 7. sukupolven Kaby Lake -mobiiliprosessoreilla testit on suoritettu Windows 10 -käyttöjärjestelmällä ja 6. sukupolven Skylake-prosessoreilla sekä Windows 10:llä käyttäen SSD-asemaa että Windows 7:llä käyttäen SSD-asemaa ja kiintolevyä. Testit ajettu SYSmark 2014 SE-, PCMark 10- 3DMark Sky Diver- ja WebXPRT 2015 -ohjelmilla.
Intelin omien testien mukaan suorituskyky on laskenut lähes jokaisessa testissä, mutta muutama poikkeuskin löytyy. Suorituskyvyn kerrotaan jopa parantuneen kiintolevyllä ja Windows 7:llä varustetulla Skylake-kokoonpanolla SYSMark 2014 SE:n Data/Finance Analysis- ja Responsiveness-testeissä sekä samalla prosessorilla, SSD-asemalla ja Windows 10 -käyttöjärjestemällä SYSMark 2014 SE:n Data/Finance Analysis -testissä, 3DMark Sky Diverin kokonaistuloksessa, grafikka-testissä ja grafiikka- ja fysiikkatestit yhdistävässä Combined-testissä.
Suurin negatiivinen vaikutus päivityksistä on saatu SYSMark 2014 SE:n Responsiveness-testissä Skylake-prosessorilla Windows 10 -alustalla ja Kaby Lake -mobiiliprosessoreilla. Skylaken tapauksessa suorituskyky oli vaivaiset 79 % alkuperäisestä, kun Kaby Lakejen suorituskyky riitti niin ikään erittäin heikkoon 86 %:iin alkuperäisestä. Myös Coffee Lake -kokoonpanoin ja Windows 7:lla ja SSD-asemalla varustetun Skylake-kokoonpanon tulokset laskivat alle 90 %:iin päivittämättömien verrokkien tuloksista samassa testissä.
Löydät kaikki suorituskykylukemat uutisen kuvasta, jonka voi avata täyteen kokoon klikkaamalla.
Lähde: Intel
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.
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. Voidaan tarvia muutama mikrokoodikäsky, koska voidaan haluta esim. varmistaa että joku ei lue sitä BTBtä samalla kellojaksolla, kun sitä resetoidaan.
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??
Kyllä tämä kommenttiosio on mennyt niin sekavaksi, ettei oikein pysy perässä.
Eikö näihin uutisaiheisiin olisi voinut olla niin, että foorumissa näkyisi:
Spectre- jne. uutiset
Helpottaisi kummasti lukemista.
Ekassa versiossa havaittiin ongelma. Ongelmaa tutkittiin ja syy ongelmaan ilmeisesti selvisi. Uusi versio paikkauksesta on valmistumassa.
Tällähetkellä ei ole tiedossa haitakeita, jotka käyttäisivät tuota. Tuo kun ei ole kovinkaan "hyödyllinen" ominaisuus, koska sen avulla ei voi esim suorittaa ohjelmia.
Parhaiten lisäät tietoturvaa pistämällä koneelle ohjelman, joka blokkaa kaikkien sivustojen kaikki ylimääräiset scriptit ja mainokset. Nopeuttaa muutenkin netin käyttöä huimasti ja pienentää selainten prossu ja muistikuormaa todella rajusti.
Ko spektre paikka muodostuu sekä mikrokoodipätsistä, että käyttispuolen muutoksesta.
Steve gibson suositteli meltdown paikkausta ja sanoi että spectre paikkausta ei tarvitse, sillä sen saa on/off.
Vaikka muutama käyttäjä täällä huutelee että meltdown patsia ei tarvita eikä ole ollenkaan haitallinen ja on hitaasti hyödynnettävissä. 😆
Heh, löytyi "ajankohtainen" postaukseni murosta aiheesta melkein viiden vuoden takaa, tässä oleellinen kohta postausta
Tuon jälkeen olen hiukan oppinut ymmärtämäään lisää noiden poikkeusten heittämisestä, mutta osoittautui tosiaankin vieläkin ongelmallisemmaksi kuin mitä tuolloin osasin ajatella siinä mielessä, että se intelin tapa tehdä tuo arkkitehtuurillisesti oikein ei kuitenkaan ollut ongelmaton 😉
Taas hätäisimmät menivät vanhaan ansaan (microsoftin päivitysten poistot).
Niin siinä sodassakin käy että vihreä innokas moku ottaa ekana osumaa.
koska lataus voi aina johtaa virtuaalimuistin läsnäolopoikkeukseen, ja jos latausta ei olisikaan pitänyt suorittaa, ei sitä poikkeusta olisi pitänytkään heittää
Todella mielenkiintoista. Voi ja jos? missä tilassa. Onko mitattavissa ja todennettavissa?
Meinaan vaan että se läsnäolopoikkeuskin voi olla todella kaukaa haettua spekula saavisuutta.
Asioiden heittelyä hurjalla menolla ja tietämystä toki on sen verran että voi nimetä asian sieltä täältä.
No
Ratkaisu tuohon on siis se, että poikkeukset heitetään vasta, kun käsky saapuu "retire"-vaiheeseen(joka on siis liukuhihnan viimeinen vaihe). Ja kaikki mitä käskyt tekee, voidaan perua kun käskyä ei ole vielä retiretty.
Ja retire siis tehdään kaikille käskyille taas alkuperäisessä ohjelmakoodin mukaisessa järjestyksessä. Eli haarautumisen jälkeinen käsky voi retirettää vai jos haarautuminen on onnistuneesti retiretty ensin.
Ja jos haarautumista tarkistettaessa haarautumisenennustus osoittautuu vääräksi ja on suoritettu käskyjä, joita ei olisi pitänyt suorittaa, tässä vaiheessa perutaan ne ja heitetään ne bittitaivaaseen liukuhihnalta ja aloitetaan tyhjältä hihnalta uusien suorittaminen oikeasti paikasta.
Eli se haarautuminen on tarkastettu aina ensin ennen kuin sen jälkeen tuleva käsky voi retirettää, eli käsky, joka suoritettiin spekulatiivisesti mutta jota ei koskaan pitänyt suorittaa, ei koskaan mene retire-vaiheeseen asti vaan perutaan ja heitetään bittitaivaaseen liukuhihnalta ennen retire-vaihetta.
Ja tämä juuri selittää tuon meltdownin toiminnan. Yksinkertaisin toteutus aloittaa sen latauksen normaalisti, mutta kun virtuaaliosoitetta muuntaessa huomataan käyttöoikeusvirhe, se merkkaa vaan siihen käskyyn tiedon, että "tämä on laiton lataus", eikä heti tee mitään muuta sen seurauksena, ja sitten retire-vaiheessa tämä "laiton lataus"-tieto huomioidaan ja sen sijaan että käsky retireisi normaalisti, se heittää sen poikkeuksen.
Latauskäskyn suorituksen peruminen (kun huomataan se virheellinen haatautumisennustus) ei kuitenkaan poista sen käskyn välimuistille tekemiä asioita, vaan peruu vain sen aiheuttamat arkkitehtuurilliset tilanmuutokset, joten side-channel-hyökkäyksellä pystään havaitsemaan, mitä osoitetta on yritetty ladata mittailemalla muiden latausten suoritusajalla sitä, mikä kohta välimuistista on muuttunut yms.
AMDllä taas on jo siellä itse latausvaiheessa tarkastus, että jos osoite on laiton, keskeytetään heti sen lataus (mutta sitä poikkeusta ei silti saa nostaa heti, vaan se pitää merkata samalla tavalla heitettäväksi vasta retire-vaiheessa)
Kiitos suhteellisen tyhjentävästä vastauksesta.
Meille jäi ilmiselvästi kysymyksiä auki.
Haluan tämän jäävän muistiin
Ei muuten win tai linux
Sitä virtuaaliosoitetta muuntaessamme vaikeutemme kasvavat.
Mutta koska me huomaamme kun aallot tulevat rantaan?
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ää musitisuojausvirhepoikkeus. 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.
Tack. Viimeksi olen tehnyt ammatikseni ohjelmointia n. 19v 10 kk sitten, joten en ole jaksanut pysytellä ajan tasalla…
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. 😉
Suoritinhaavoittuvuutta hyödyntävien haittaohjelmien määrä räjähti, ainakin 130 näytettä löydetty
Mukava tässä surffailla koneella, jossa tietää ongelman olevan. :/
Kummastahan spectre variantista on nyt kyse? Ilmeisesti ykkösvariantista?
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.
On kyllä taas melkonen clickbait otsikko Mikropiltillä! Mitään sen ihmeempää ei ole tullut, kunhan pelotellaan peruskäyttäjiä turhaan…
Jokos intel on julkaissut korjaukset kaatuiluihin kaikilla prossuilla?
Muutoinhan noita biosseja yms ei voi edes päivittää ja nyt ollaan sitten uhille alttiita..
Mikäs siinä on ongelmana, kunhan ei ajele mitään epämääräisiä softia koneella? … Pistää javan pois, jos epäilee sen vuotavan jotain..
Muutenkin tuollahan muistinluku on ainankin hidasta ja vie paljon prossutehoa, melko epäkätevää siis tonkia mitään…
Project Zero: Reading privileged memory with a side-channel
Javan? Kuka nyt Javaa mihinkään käyttäisi.
Javascriptiä taas huono disabloida kun puoli nettiä lopettaa toiminnan. Olihan youtubessakin jo mining scriptiä mainoksissa. Miksei tätä voisi olla? Vaikea suojautua ja kyllä esim nettisivujen passut kelpaa hakkereille.
Jotain lähdettä tälle?
Eikös selainten sciptienginet ole sabotoitu nykyisin ihan erikseen selainten päivityksissä s.e. ei tahdo ajastukset onnistua, eli lukeminen on muuttunut erittäin hitaasta mahdottomaksi tuota kautta.
Muutenkin, kun selaimen prosessi vie jotain 100 000K – 300 000 K, ja ei edes tiedä oikein, mitä sieltä etsiä, niin melko hidasta ja toivotonta sieltä on mitään oikeasti löytää, kuin lähinnä vahingossa.
Kyllä, mutta jos bittimikroon on uskominen niin:
Jos on proof-of-concept olemassa niin ei kauaa mene että siitä tehdään myös oikeita haitakkeita. Jos se kerran toimii, niin kyllä sitä tullaan käyttämään. Rikollisia ei kiinnosta joutuuko se käyttäjän kone jauhamaan 10min yhtä salasanaa. Jos se on ongittavissa, se on ongittavissa. Tehdään vaikka javascript joka aktivoituu vasta 5min jälkeen, eli silloin kun käyttäjä on jättänyt sivun auki ja lähtenyt hakemaan kahvia. Takaisin tullessa scripti on ehtinyt jautaa ne pari passua ja lähettänyt ne hökkääjälle. Käyttäjä refreshaa sivun ja "jumissa ollut" sivu alkoi taas toimia oikein ja koneen tuuletinkin rauhottui. Asia jää sikseen ja salasanat/tunnukset/muut vuotaneet maailmalle ilman mitään merkintöjä mihinkään logiin. Sehän näissä pelottaa, ettei noista jää mitään jälkeä koneelle.
Coinhive Cryptojacker Deployed on YouTube via Google Ads
Muistaakseni sanottiin jotain, että kalibrointiin menee ei javascriptiversiolla ensin se 10-30 minuuttia ja senjälkeen onnistuu "lukeminen" melko surkealla nopeudella. Joku variannti oli muistaakseni käytössä " heti, mutta jos etsittävä alue on esim 50 000 kt (puolet selaimen yleensä syömästä muistista) ja nopeus on 2 kt /s, niin aikaa vierähtää 12500s, ennen kuin puolet alueesta on tutkittu, joka on noin 3, 5 tuntia. Tiedä sitten sietääkö käyttäjä hirttävää konetta edes tuon aikaa..
Jos selain järjestelisi muistinsa uudestaan esim kerran /10 minuuttia, niin tuolla olisi melkoisen toivotonta etsiä tasan mitään sieltä… Tuo on vain ihan liian hidasta, nykyisillä tietomäärillä.
Lisäksi kun se muisti on täynnä kaikenlaista paskaa, niin mistä sen tietää, mikä siellä on se salasana? Ei siellä ole mitenkään välttämättä tiettyjä merkkejä edes ennen sitä salasanaa. Tietysti joku salasanavaulttisofta / selaimen salasanamuisti, jos sitä käyttää, voi olla tuolle altis.
Todennäköisesti paljon helpommin saa sen salasanan huijaamalla sitä käyttäjää esim oikeannäköisellä loginilla väärässä paikassa..
————————-
Oikea uhka tuo on järjestelmille, joissa asiakas pyörittää virtuaalikoneessa softaa, kun tuolla pääsee isännän ja muiden asiakkaiden dataan käsiksi.. Lisäksi voisi kuvitella, jotta tuolla voisi ehkä lukea softista suojattuja avaimia, ne kun voivat möhöttää sillä muistissa, kun vain se haluttu softa on päällä, jos suojaus on tehty laiskasti. Jos taas suojaus decryptaa itsensä vain välillä muutamaksi kymmeneksi nanosekunniksi, niin ei tuolla mitään suoraan käyttökelpoista irtoa irtoa, vaan joutuu debuggailemaan lisäksi mahdollisesti ankarastikin..
Mainoksethan tulee ihan oletuksena blokata, kun ne sisältävät milloin mitäkin haitaketta ym. Muutoinkin aiheuttavat nykyisin huomattavaa prossukuormaa ja netinkäyttöä VAIKKA sattuisivat olemaan "puhtaita". Valitettavasti on menty siihen, että haitallisuutensa takia mainoksien blokkauksesta on tullut tärkeämpi edellytys, kuin esim jostain viruskilleristä.
Puhumattakaan salasanoja mielenkiintoisemmista saaliista eli vaikka kohdennettu hyökkäys kryptolompakko ohjelmistoja vastaan.
Hiljaista ollut korjausten suhteen, mutta nyt ilmeisesti Skylake-prossuille saatu valmiiksi hiotumpi päivitys mikrokoodiin, joka on jaettu nyt laitevalmistajille. Muut arkkitehtuurit saavat vielä odotella omaansa.
Intel releases new Spectre microcode update for Skylake; other chips remain in beta
Noinkohan olen kertonut. Toki kaiken saa päältä ja pois, mutta prosessorin initissä, ei ajossa olevasta kivestä. BTB-taulu on vaan branch-prediction yksiköiden taulukkoja jotka nykyprosessoreissa ovat monitasoisisa ja suoria manipulointikäskyjä noihin ei ole, eli jos ne halutaan flushata ajetaan prosessorissa koodinpätkä joka muuttaa noiden taulujen arvot epäkuranteiksi.
Koodinpätkä on siis jotain ajettavaa koodia joka saa branc-predictorin arvot muuttumaan epäkuranteiksi mahdollisen haavoittuvuuden hyödyntämiseen. Sinun tulkintasi sanomisistani on jotain ihan muuta.
Ja itse aloit höpöttämään kiikuista yms, mikälie aivopieru, tähän asiaan liity millään tavalla.
Nythän on myös tutkittu mitä tuo Intelin buginen mikrokoodipätsi tekee, TDP ylittyy sitä käytettäessä yli 150%:llä josta seuraa epävakaus. Intelillä on erityisen raskaat kiikkujen resetointilinjat käytössä 😉
Spekulatiivisten käskyjen ajo ei näy millään tavalla debuggerissa. Ja spekulatiivinen laiton lataus ei ole mikään syy tappaa ohjelmaa, eikä mikään spekulatiivisen ajon poikkeus pitäisi näkyä ulospäin.
Jos siis puhutaan meltdownista niin prossulle riittää että kunnioitetaan muistisuojausta, prosessorit jotka eivät näin tee ovat "rikki". Suorastaan edesvastuutonta antaa ylemmän suojaustason lukea alemman dataa missään tilanteessa. Spectre on sitten ongelmallisempi, ensin pitäisi tietää että luetaan ei ohjelmalle kuuluvaa dataa, jos se tiedettäisiin niin prosessorit jotka eivät ole "rikki" eivät ko. ongelmasta kärsisi.
Olisi mielenkiintoista, jos tutkisi, miksi ohjelma on kaatunut ja selityksessä lukisi:
On mahdollista, että ohjelma olisi ehkä myöhemmin lukenut tietoja kielletystä muistiosoitteesta.