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

[Cirrus]

Jos turvatyynyt ei laukea kolarissa (tarvittaessa) niin kyllä se silloin on suunnitteluvirhe, vaikka ne jossain toisessa kolarissa laukeisivatkin.

Vain siinä tapauksessa että valmistaja on myynyt turvatyynyt autoon.

 

[FireFly Renaissance]

Vain siinä tapauksessa että valmistaja on myynyt turvatyynyt autoon.

Kyllä, mutta sellaista mikä ei ole rikki ei tarvi korjata

 

[-SD-]

Avg fps peleissä ei juurikaan mitään mitään kerro, mielenkiinnolla odotan mitä frametimet sanoo.

Toivottavasti joku sivusto mittaa nuo.

 

[Nutti]

Piti regata kun on sen verran mielenkiintoinen bugi.

Eli Intelin prossut vuotaa kuin seula, ongelmana on että spekulatiivinen luenta tehdään tarkistamatta oikeuksia, tästä on varmasti selvää nopeushyötyä/virransäästöä.

Eli homma tehdään antamalla prosessorille mahdollisuus tehdä spekulatiivinen luku kerneliosoitteesta(joka kait saadaan TLB:stä side-channel hyökkäyksellä) ja sen perään vaikka add:tään ko. spekulatiivisen käskyn tulos userspacessa olevaan osoitteeseen, ja tulos saadaan noilla side-channel luvuilla luettua userspacen cachesta vaikka tulos ei ikinä varsinaisesti mihinkään näykään. Eli koko kerneli on luettavissa. Korjaushan on pilkkoa kerneli satunnaisiin osoitteisiin ja tyhjennellä TLB usermoodin ohjelmia ajettaessa, ISO kysymys on että kun prosessorissa on noin rankka haavoittuvuus päästäänkö silti ketjussa takaisinpäin jollain keinolla, ja jos päästään niin Intelillä on todella paljon suurempi ongelma kuin pieni hidastuminen.

Eli Intel on ollut tietoinen asiasta, kun on tuollaisen toiminnan suunnitellutkin, että oikeudet jätetään tarkistamatta, jotain minkä AMD:n prossut tekee. AMD on siis ollut tietoinen tästä -> Intelin on täytynyt olla tietoinen myös. Vuosikymmenen tuottanut tällaista pazkaa tietoisesti. Toivoneet vain, ettei sitä väärinkäytettäisi. Kyllä siis prosessorissa on suunnitteluvirhe.

 

[hkultala]

No valmistusvika ei joo ole kyseessä, mutta suunnitteluvirhe on.

Jos turvatyynyt ei laukea kolarissa (tarvittaessa) niin kyllä se silloin on suunnitteluvirhe, vaikka ne jossain toisessa kolarissa laukeisivatkin.

Ei, vaan vertautuu siihen, että autossa ei alunperinkään ole niitä turvatyynyjä.

Ja sitten tulee uusi tutkimus jossa todetaan että turvatyynyt vähentää kuolemia törmäyksissä huomattavasti ja tämän johdosta tulee voimaan laki jonka mukaan kaikissa autoissa pitääkin olla turvatyynyt, mutta valtio kustantaa niiden asentamisen vanhoihin autoihin, ja niiden jälkiasennuksesta koituu jotain pientä haittaa, kun ne ei ole järkevästi integroitu auton rakenteisiin.

(linuxin + microsoftin kernelit yhdessä on asemassa että niitä voi pitää lakina)

 

[Cirrus]

Kyllä, mutta sellaista mikä ei ole rikki ei tarvi korjata

Kuka nyt on korjaamassa mitään? Kehitys kehittyy ja turvatyynyt on uusissa tulevissa autoissa.

 

[antero]

Ja se että AMD on tälle immuuni, kyse lienee enemmän siitä että AMDllä kävi hyvä tuuri, ettei AMD ehtinyt toteuttaa yhtä aggressiivista muistioperaatioiden uudelleenjärjestelyä tai spekulatiivista suoritusta, ei siitä että AMD olisi osannut ja Intel olisi mokannut; Tämä vaikuttaa jutulta johon KUKAAN ei tietoisesti osannut varautua.

Mutta oliko että AMD silti ajaa saman korjatun koodin, vaikka ei olisi tarvis? Eli kärsii ikäänkuin syyttömänä asiasta.

 

[Sami Riitaoja]

Kyllä siis prosessorissa on suunnitteluvirhe.

Kernelidata vuotaa userpuolen softille, joo vois sitä suunnitteluvirheenä pitää

On siis sen luokan suunnitteluvirhe että ei ihan heti tule mieleen toista, ja hakkereille aukeaa ovet vaikka mihin kun tämä tiedetään. PTI-korjaus ei ole sataprosenttinen, ei voi olla kun prossu ei tarkista datan käyttöoikeuksia, tosin onhan tuo nyt 64-bittisessä avaruudessa suht hyvin turvassa, mutta suht hyvä ei välttämättä ole mitä tärkeälle datalle halutaan.

 

[Threadripper]

Kyseessä on valmistusvirhe, joka ei käytännössä vanhene koskaan, eikä prosessori täytä enää sille myydessä luvattuja arvoja. Periaatteessa voisi aivan hyvin vaatia hyvityksiä jostain 10v vanhoista prossuistakin.

Tuo on vähän sama, kuin autosta huollon yhteydessä poistettaisiin viides vaihde. Tuskin kovin moni sitä mukisematta nielisi.

Ei ole valmistusvirhe koska se hidastaa vain "huonosti toimivia" ohjelmistoja. Prosessori toimii juuri niin kuin pitääkin, mikäli ohjelmisto on kunnossa.

Autoesimerkkisi ei toimi koska siinä poistetaan rautatason ominaisuus poistamalla se kokonaan. Prosessorin tapauksessa muutetaan ohjelmistoja jotka toimivat päivityksen jälkeen hitaammin. Huono alkaa syyttämään prosessorivalmistajaa siitä ettei ohjelma toimi yhtä nopeasti kuin aiemmin.

Jos prossu hidastuu valmistusvian korvaavan paikkauksen takia, niin kyllähän se silloin on viallinen tuote ollut jo myydessä.

Edelleenkään prosessori ei hidastu yhtään. Tietyt ohjelmistot hidastuvat. Täysin eri asioita.

 

[demu]

Tämmöistä laittoivat Inteliltä: Intel Responds to Security Research Findings

Hoh hoijaa.
Ja tällä Intelin lausunnolla on ollut se vaikutus, että Intelin kurssi on lähtenyt selvään nousuun ja AMD:n kurssi vastaavasti selvään laskuun:

Jos Intelin lausunnon totuus tästä vielä muuttuu, on sijoittajilta tiedossa Intelille haasteita lakitupaan.

 

[Sampsa]

Piti regata kun on sen verran mielenkiintoinen bugi.

Eli Intelin prossut vuotaa kuin seula, ongelmana on että spekulatiivinen luenta tehdään tarkistamatta oikeuksia, tästä on varmasti selvää nopeushyötyä/virransäästöä.

Eli homma tehdään antamalla prosessorille mahdollisuus tehdä spekulatiivinen luku kerneliosoitteesta(joka kait saadaan TLB:stä side-channel hyökkäyksellä) ja sen perään vaikka add:tään ko. spekulatiivisen käskyn tulos userspacessa olevaan osoitteeseen, ja tulos saadaan noilla side-channel luvuilla luettua userspacen cachesta vaikka tulos ei ikinä varsinaisesti mihinkään näykään. Eli koko kerneli on luettavissa. Korjaushan on pilkkoa kerneli satunnaisiin osoitteisiin ja tyhjennellä TLB usermoodin ohjelmia ajettaessa, ISO kysymys on että kun prosessorissa on noin rankka haavoittuvuus päästäänkö silti ketjussa takaisinpäin jollain keinolla, ja jos päästään niin Intelillä on todella paljon suurempi ongelma kuin pieni hidastuminen.

Tervetuloa, toivottavasti löytyy jatkossakin mielenkiintoisia aiheita ja keskusteluita

 

[hkultala]

Eli Intel on ollut tietoinen asiasta, kun on tuollaisen toiminnan suunnitellutkin, että oikeudet jätetään tarkistamatta, jotain minkä AMD:n prossut tekee. AMD on siis ollut tietoinen tästä -> Intelin on täytynyt olla tietoinen myös. Vuosikymmenen tuottanut tällaista pazkaa tietoisesti. Toivoneet vain, ettei sitä väärinkäytettäisi. Kyllä siis prosessorissa on suunnitteluvirhe.

Ei niitä jätetä tarkastamatta. Ne tarkastetaan. Ja sen tarkastuksen seurauksena lentäisi poikkeus ennen kuin sitä laittomasti ladattua dataa voidaan tallettaa mihinkään arkkitehtuurillisesti näkyvään paikkaan.

Todella ovelalla side channel-hyökkäyksellä sen datan vaan saa (hyvin hitaasti ja hankalasti) luettua siinä välissä, ennen kuin se poikkeus lentää.

Ja tällaiseen todella ovelaan side channel-hyökkäykseen ei todellakaan osata varautua etukäteen.

 

[Sami Riitaoja]

Hoh hoijaa.
Ja tällä Intelin lausunnolla on ollut se vaikutus, että Intelin kurssi on lähtenyt selvään nousuun ja AMD:n kurssi vastaavasti selvään laskuun:

Jos Intelin lausunnon totuus tästä vielä muuttuu, on sijoittajilta tiedossa Intelille haasteita lakitupaan.

Niin intel kertoi että dataa ei voi muuttaa, poistaa tai korruptoida. Lukea voi suht vapaasti, osakemarkkinat on tyhmiä ja varmaan kurssi taas kääntyyy kun isommat saitit raportoi varsinaisesta ongelmasta.

 

[FireFly Renaissance]

Ei, vaan vertautuu siihen, että autossa ei alunperinkään ole niitä turvatyynyjä.

Ja sitten tulee uusi tutkimus jossa todetaan että turvatyynyt vähentää kuolemia törmäyksissä huomattavasti ja tämän johdosta tulee voimaan laki jonka mukaan kaikissa autoissa pitääkin olla turvatyynyt, mutta valtio kustantaa niiden asentamisen vanhoihin autoihin, ja niiden jälkiasennuksesta koituu jotain pientä haittaa, kun ne ei ole järkevästi integroitu auton rakenteisiin.

(linuxin + microsoftin kernelit yhdessä on asemassa että niitä voi pitää lakina)

Kuulostaa saatavissa olevien tietojen perusteella nyt valkopesulta.

Ymmärtääkseni, tuo Kerneli käyttää samaa muistialuetta, koska sen pitäisi olla arkitehtuurisesti turvassa. Nyt näin ei olekaan ja se joudutaan siirtämään hitaampaan paikkaan. Prosessori ei toimi siis kuten on suunniteltu. Jos se toimisi kuten on suunniteltu, ja dokumentointi olisi asianmukaista, kerneli olisi jo alunperin siirretty pois samalta näkyvyysalueelta.

En ymmärrä miksi tuota tarvii selitellä. Siitä voidaan sitten keskustella kuinka paha moka on kyseessä.

 

[FireFly Renaissance]

Kuka nyt on korjaamassa mitään? Kehitys kehittyy ja turvatyynyt on uusissa tulevissa autoissa.

Microsoft ja Linux yhteisö ainakin minun nähdäkseni on kovasti korjaamassa.

Toki voihan se olla, että koko uutinen oli ankka ja mitään korjauksia ei olla suunniteltuun toiminnallisuuteen tekemässä.

 

[hkultala]

Ei ole valmistusvirhe koska se hidastaa vain "huonosti toimivia" ohjelmistoja.

Ei kyse ole mistään "huonosti toimivista" ohjelmista.

Kyky tehdä kutsuja käyttöjärjestelmän ytimelle on ohjelmille hyvin oleellinen ominaisuus.

Ja riippuu täysin siitä, MITÄ se ohjelma tekee, että paljonko sen tarvii niitä tehdä. Ei yhtään siitä onko ohjelma "hyvä" vai "huono".

 

[Sampsa]

Mutta oliko että AMD silti ajaa saman korjatun koodin, vaikka ei olisi tarvis? Eli kärsii ikäänkuin syyttömänä asiasta.

Tällä hetkellä joo, koska alkuperäinen korjaus tehtiin oletuksella että vaikuttaa kaikkiin x86-prosessoreihin. Tämän AMD on kiistänyt ja tarjonnut vaihtoehtoisen koodin joka jättää tunkistuksessa AMD:n huomioimatta. Tätä ei ole vielä implementoitu, mutta näyttää siltä että tulee ennemmin tai myöhemmin:

Linux Will End Up Disabling x86 PTI For AMD Processors - Phoronix

 

[Sami Riitaoja]

Ja tällaiseen todella ovelaan side channel-hyökkäykseen ei todellakaan osata varautua etukäteen.

Osataan, ulompien rinkien ohjelmille ei näy sisempien data. Intel on vain tehnyt "optimoinnin" ja jättänyt tarkastuksen yhdestä välistä pois jonka ei pitäisi vaikuttaa mihinkään mutta kun kaikki ei aina mene suunnitellusti.

 

[Cirrus]

Microsoft ja Linux yhteisö ainakin minun nähdäkseni on kovasti korjaamassa.

Toki voihan se olla, että koko uutinen oli ankka ja mitään korjauksia ei olla suunniteltuun toiminnallisuuteen tekemässä.

Microsoft ja Linux ovat auton käyttäjiä. Jos auton käyttäjä hitsaa vahvistuksia pitkittäispalkkeihin paremman törmäysturvalisuuden toivossa siitä ei seuraa että turvatyynyyjen puute oli valmistusvirhe.

 

[hkultala]

Osataan, ulompien rinkien ohjelmille ei näy sisempien data. Intel on vain tehnyt "optimoinnin" ja jättänyt tarkastuksen yhdestä välistä pois jonka ei pitäisi vaikuttaa mihinkään mutta kun kaikki ei aina mene suunnitellusti.

Ei se näykään. Ja se tarkastus tehdään. Siihen tarkastuksen tulokseen vaan reagoidaan liian myöhään, että hyvin monimutkainen, hankala ja hidas SCA mahdollistaa sen datan lukemisen.

SCAt on oikeasti todella monimutkaisia ja hankalia juttuja joihin on äärimmäisen hankala varautua etukäteen.

Koska SCAt ei perustu mihinkään bugeihin.

 

[antero]

Tällä hetkellä joo, koska alkuperäinen korjaus tehtiin oletuksella että vaikuttaa kaikkiin x86-prosessoreihin. Tämän AMD on kiistänyt ja tarjonnut vaihtoehtoisen koodin joka jättää tunkistuksessa AMD:n huomioimatta. Tätä ei ole vielä implementoitu, mutta näyttää siltä että tulee ennemmin tai myöhemmin:

Linux Will End Up Disabling x86 PTI For AMD Processors - Phoronix

Siinä tapauksessa Intelin on pakko korjata asia rautatasolla, tosin vasta uusissa malleissa. Tulee taas ilmaisia teholisä prosentteja verrattuna edelliseen malliin.

 

[Sami Riitaoja]

Normikäyttäjällehän tää ei merkkaa mitään.

 

[FireFly Renaissance]

Ja tällaiseen todella ovelaan side channel-hyökkäykseen ei todellakaan osata varautua etukäteen.

Jos sen voi löytää siihen voi varautua. Ei toki tarkoita, ettäkö se varautuminen olisi helppoa.

 

[FireFly Renaissance]

Edelleenkään prosessori ei hidastu yhtään. Tietyt ohjelmistot hidastuvat. Täysin eri asioita.

Mitä se prosessori tekee? Minä olen aina luullut, että sen tarkoitus on ajaa ohjelmistoja. Harvialta saa kyllä kiukaita halvemmallakin.

 

[hkultala]

Jos sen voi löytää siihen voi varautua. Ei toki tarkoita, ettäkö se varautuminen olisi helppoa.

Käytin sanaa "osata", en "voida".

Nyt meni kymmenisen vuotta että joku koko maailmassa keksi tuon SCAn.

Mikä on todennäköisyys sille, että jonkun täysin uudentyyppisen SCAn sattuu keksimään prosessorifirman insinööri juuri sinä aikana kun uutta prosessoria (jolla se on mahdollinen) kehitetään, jolloin prosessorissa voidaan ottaa se huomioon ja estää sen toiminta? Todella pieni.



ps. macos X:stä on taas jälleen tänään löytynyt ihan oikea triviaalisti hyödynnettävä tietoturva-aukko-bugi.

 

[Sami Riitaoja]

Ei se näykään. Ja se tarkastus tehdään. Siihen tarkastuksen tulokseen vaan reagoidaan liian myöhään, että hyvin monimutkainen, hankala ja hidas SCA mahdollistaa sen datan lukemisen.

SCAt on oikeasti todella monimutkaisia ja hankalia juttuja joihin on äärimmäisen hankala varautua etukäteen.

Koska SCAt ei perustu mihinkään bugeihin.

Siis Intelin prosessoreiden ongelma on että spekulatiivinen luku tehdään tarkastamatta datan käyttöoikeuksia, ja em. luennan tulokset saadaan selville. Periaatteessa tuossa välissä oikeuksien tarkastus on turhaa mutta kun ei sitten kuitenkaan ole. Esimerkiksi AMD:n prosessoreissa ei em ongelmaa ole koska dataa ei lueta tarkastamatta oikeuksia siihen ensin. Ja Inteliltä ollut kyllä melkoinen riskiveto antaa luvun tapahtua oikeuksia tarkastamatta, kyllä tuossa on varmasti otettu tietoinen riski mahdollisesta haavoittuvuudesta.

 

[demu]

Offtopic: käväisin (ensimmäistä kertaa yli puoleen vuoteen) muron puolella katsomassa, mitä siellä asiasta keskustellaan (ei oikeastaan mitään).
Mutta melkein pärskähti kahvit näytölle kun huomasin vanhan tuttavamme sinsinin kommentin:

 

[user9999]

Intel Memory Access Design Flaw Already Addressed by Apple in macOS 10.13.2

 

[FireFly Renaissance]

Käytin sanaa "osata", ei "voi".

Nyt meni kymmenisen vuotta että joku koko maailmassa keksi tuon SCAn.

Mikä on todennäköisyys sille, että uudentyyppisen SCAn sattuu keksimään prosessorifirman insinööri juuri sinä aikana kun uutta prosessoria kehitetään, jolloin prosessorissa voidaan ottaa se huomioon ja esää sen toiminta? Todella pieni.

Ei se poista sitä tosiasiaa, että jos prossu toimisi kuten on suunniteltu niin sitä vikaa ei olisi löytynyt edes kymmenessä vuodessa. Jos taas ongelma on tiedetty, mutta se on silti jätetty noin, "koska ei sitä kukaan löydä", kyseessä on suurempi kupru.

Se, että suunnitteluvirhe on vaikea havaita ei muuta sitä tosiasiaa, että kyseessä on suunnitteluvirhe. Sinänsä minä en mitenkään ylläty siitä, että siellä on suunnitteluvirhe. Niitä on varmasti lisääkin, mutta kukaan ei ole löytänyt. Digitaalipiirit ovat äärimmäisen monimutkaisia järjestelmiä, eikä kenelläkään ole varaa tehdä täydellistä verifiointia.

 

[Teuras]

Edelleen: Ei siinä ole mitään valmistusvikaa. Se toimii täysin speksien mukaan.

Jos haluat vetää autovertauksen, niin pikemminkin kyse on siitä, että ilkivalta autoja kohtaan lisääntyy, teineille tulee muotiin heitellä autoja nyrkinkokoisilla kivillä, ja tämän johdosta autoihin päätetään jälkikäteen asentaa vahvemmat lasit jotta ne kestää sellaisten kivien osumat, joita auton laseja ei alunperin suunniteltu kestämään. Nämä vahvemmat lasit kuitenkin painavat enemmän minkä takia auton kiihtyvyys hidastuu parin prosentin verran, tehon ja huippunopeuden säilyessä ennallaan.

Eli sama kuin auton kansi tai lohko pettää, mutta auto toimii kuten pitää vaikka vähän nesteet ja öljyt sekoittuu, vieden vain vähän tehoa...

 

[antero]

Intel Memory Access Design Flaw Already Addressed by Apple in macOS 10.13.2

Oho taas Apple oli edelläkävijä jo viime vuonna. Alkaa olla yhä enemmän salaliittoteorioita että asiaa venytettiin joulun yli.

Eli sama kuin auton kansi tai lohko pettää, mutta auto toimii kuten pitää vaikka vähän nesteet ja öljyt sekoittuu, vieden vain vähän tehoa...

Ei se hajoa. Vain ettei täytä kaikkia turvanormia, heikkoa peltiä kolaritilanteessa.
Kaipaa vahvistusta.

 

[Threadripper]

Mitä se prosessori tekee? Minä olen aina luullut, että sen tarkoitus on ajaa ohjelmistoja. Harvialta saa kyllä kiukaita halvemmallakin.

Yksinkertaistettuna prosessori suorittaa sille annettuja laskutoimituksia. Laskutoimituksien teoreettisella määrällä/sekunti/prosessori on raja, joka riippuu prosessorin rakenteesta (ja monesta muusta ominaisuudesta). Käytännössä prosessorit eivät pääse lähellekään teoreettista maksimia. Riippuen siitä millaisia laskutoimituksia prosessorille annetaan, prosessori jää enemmän tai vähemmän kauas maksimista. Tässä tapauksessa ohjelmat syöttävät prosessorille sellaista laskettavaa jolla prosessori jää kauemmas teoreettisesta maksimista kuin aiemmin.

Asia jossa ei oikeasti ole yhtään mitään uutta.

 

[Prosumies]

Intelin vastaus:
Intel says processor bug isn’t unique to its chips and performance issues are ‘workload-dependent’

 

[FireFly Renaissance]

Yksinkertaistettuna prosessori suorittaa sille annettuja laskutoimituksia. Laskutoimituksien teoreettisella määrällä/sekunti/prosessori on raja, joka riippuu prosessorin rakenteesta (ja monesta muusta ominaisuudesta). Käytännössä prosessorit eivät pääse lähellekään teoreettista maksimia. Riippuen siitä millaisia laskutoimituksia prosessorille annetaan, prosessori jää enemmän tai vähemmän kauas maksimista. Tässä tapauksessa ohjelmat syöttävät prosessorille sellaista laskettavaa jolla prosessori jää kauemmas teoreettisesta maksimista kuin aiemmin.

Asia jossa ei oikeasti ole yhtään mitään uutta.

Tämä bugi ei taida vaikuttaa ketjun perusteella (en ole ehtinyt pidemmältä tutustua) yhdenkään laskuoperaation suoritusnopeuteen, joten silleen taisi nyt mennä ihan perseelleen.

ps. Tiedän sattuneesta syystä kyllä melko hyvin miten prosessori toimii.

 

[hkultala]

Siis Intelin prosessoreiden ongelma on että spekulatiivinen luku tehdään tarkastamatta datan käyttöoikeuksia, ja em. luennan tulokset saadaan selville.

Kyllä se tarkastus tehdään heti, siihen tarkastuksen tulokseen vaan reagoidaan vasta sen lukemisen jälkeen, mutta ennen kuin sen lukemisen tulosta tallennetaan mihinkään arkkitehtuurillisesti näkyvään paikkaan.

Tämä vertaituu siihen, että urheilukilpailussa kilpailija tekee rikkeen, joka johtaa hänen kilpailusuorituksensa hylkäämiseen. Kilpailija voidaan joko liputtaa heti kesken kisan ulos radalta, tai hänen voidaan antaa edetä maaliin asti, ja kertoa hänelle maalissa, että suoritus on hylätty. Kummassakaan tapauksessa kilpailija ei pysty voittamaan kilpailua, eikä hänen aikansa koskaan päädy viralliselle tuloslistalle.

No, sitten joku keksiikin todella nerokkaan keinon sotkea koko kilpailun ajanotto- ja tietojärjestelmän (vaikka niistä oli moninkertaiset turvajärjestelmät), ja samalla katoaa myös virallinen tieto siitä, keiden tulos oli hylätty, myös paperikopiot, ja tuomari on lyönyt päänsä ettei muista kenen suorituksen hylkäsi. Kukaan ei osannut varautua tähän. Palkinnot päädytään antamaan sen perusteella, kuka saapui maaliin ensimmäisenä. Tällaisessa tilanteessa olisi ollut parempi liputtaa vaan heti ulos radalta hylätyt suoritukset.

Intel on se, joka otti strategian että annetaan kilpailijan juosta maaliin ja ilmoitetaan siellä hylkäämisestä, AMD se, joka otti strategian, että liputetaan heti ulos radalta rikkeen sattuessa.

 

[Kaotik]

Intelin vastaus:
Intel says processor bug isn’t unique to its chips and performance issues are ‘workload-dependent’

Tuokin taisi tulla jo jossain kohtaa esiin. En sitten tiedä löytyykö bugi ehkä myös VIAn prossuista tai jostain, AMD:lla sitä ei ole. Tai sitten jostain ihan muusta kuin x86-prossusta?
Se on kyllä totta että suorituskykyhävikki riippuu kuormasta, mikä on ihan luonnollistakin. Esimerkiksi kovaa I/O:ta vaativat kuormat hidastuvat reilusti, monet muut eivät.

 

[JaniKari]

MS julkaisee korjauksen:
Microsoft issues emergency Windows update for processor security bugs
Kai tässä jotain on takana jos MS ja Apple on korjaamassa pika pikaa. Väärä NSA on keksinyt miten hyödybtää tätä?

 

[Sami Riitaoja]

Siis tää on kaikkien tietoturvaongelmien äiti, kyllä varsinkin serveripuolelle pitää tulla korjaukset nopeasti. Linuxissa esimerkiksi prossut on merkitty insecureksi.

 

[Sampsa]

AMD:lta on ilmeisesti tulossa vielä myöhemmin tänään virallisempi lausunto/selvitys asiasta, mutta tässä lausunto ennen sitä tuohon Intelin tiedotteeseen:

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.

AMD rebukes Intel, says flaw poses 'near-zero risk' to its chips

 

[Sampsa]

Samassa jutussa lisäksi:

Google first informed Intel about the issue and that to Intel's knowledge the flaw had not been exploited

 

[Sampsa]

Ja Google aikoo julkaista tänään yksityiskohdat tuosta bugista:

Google is planning to document and disclose the security flaws in processors at 5PM ET today. The exact bug appears to be related to the way that regular apps and programs can discover the contents of protect kernel memory areas. Kernels in operating systems have complete control over the entire system, and connect applications to the processor, memory, and other hardware inside a computer. There appears to be a flaw in modern processors that let attackers bypass kernel access protections so that regular apps can read the contents of kernel memory.

 

[RageDaddy]

 

[Graag]

Ei ole vielä kahta kuukautta siitä kun Management Enginestä löytyi edellinen vakava haavoittuvuus Intelin raudasta. Koska se korjataan BIOS-päivityksillä, niin kaikkia haavoittuvia järjestelmiä tuskin koskaan päivitetään. Ainakin tällä kertaa vian voi korjata käyttöjärjestelmän automaattisella päivityksellä, jolloin se saadaan valtaosasta laitteita tukittua. Onhan se tietenkin hyvä että Intel nämä paikkaa, mutta jos tämän laajuuden haavoittuvuuksia tällä tahdilla löytyy, niin kyllä luottamus Inteliin kärsii.

 

[Sampsa]

Cannon Lakessa korjattu?

 

[user9999]

Google Online Security Blog: Today's CPU vulnerability: what you need to know

 

[Jho]

Tässä ilmeisesti lisää Googlelta
Google Online Security Blog: Today's CPU vulnerability: what you need to know

Intelin dioja tapauksesta (edit: ilmeisesti intelin tällä hetkellä menevän conference callin yhteydessä julkaistu):
https://redirect.viglink.com/?format=go&jsonp=vglnk_151501928049211&key=08a8dcb30b28eed5c1da2bd64b4ca559&libId=jbzn69ph0101045l000MAcvyjju1knaur&loc=https://forums.anandtech.com/threads/massive-security-hole-in-xeons-incoming.2532563/page-8&v=1&out=https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf&title=Page 8 - Massive security hole in Xeons incoming?&txt=https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf


Lievästi off-topic: ilmeisesti jokin lakifirma tutkii Intelin CEO:n osakkeiden myyntiä
Bronstein, Gewirtz & Grossman - Class Action New York

 

[JiiPee]

Itse veikkaan ettei 99 % tavallisista käyttäjistä huomaa hidastumista ollenkaan,jollain sopivalla testillä varmaankin näkyy mutta ei käytännössä.Samoin veikkaan että pörssikurssit on muutaman viikon kuluttua suurin piirtein hässäkkää edeltävällä tasolla,ei AMD prossu muutu yhtään paremmaksi siitä mitä se oli viikko sitten.

Ei se AMD:n prossu muutukaan paremmaksi. Intelin prossu sen sijaan muuttuu huonommaksi.

 

[hkultala]

Cannon Lakessa korjattu?

Aika oudolta kuulostava tweetti, koska ei vihjaa siihen, että ongelmaa olisi korjattu, vaan vain puhuu siitä että workaroundin suorituskykyhaitta vähenee.

Luulisi, että ennemmin haluaisivat poistaa koko ongelman kuin vähentää workaroundin hittiä, mutta Cannon Laken kehitys lienee niin pitkällä, että LSUita on liian myöhäistä muuttaa, mutta jotain muuta osaa piiristä pystytään vielä viilaamaan. Tulee mieleen esim. jotain sivutaulujen cachettämiseen liittyvää, jotain prefetchiä niille kernel-kutsun yhteydessä tms.

 

[user9999]

Google Online Security Blog: Today's CPU vulnerability: what you need to know

Jotain muutakin tuosta:
Project Zero: Reading privileged memory with a side-channel

 

[Hannibal]

No mutta, hyvää syy päivittää 8700k tulevaan 8-core malliin ja z390 alustaan, sinä lienee korjattu ns. rautatasolla! Olin jo pähkäilly et millä sen oikeuttas itselleen, ei tartte enää murehtia, kätevää!

Well ei ole vielä Intelin tulevissa prossissa päivitystä tämän suhteen. Ehkä ensivuoden malleissa tai sitä seuraavissa. Jos korjaus nykyisin markkinoilla oleviin ei onnistu mikrokoodilla, niin ei se onnistu nyt markkinoille tuleviinkaan.
Ne, jotka eivät ole vielä ollenkaan tuotannossa, vaatinevat pientä prosessijumppaa, joka viivästyttää prossan markkinoilletuloa ihan kohtuullisesti. Kultakala voinee paremmin arvioida kuinka kauan. Itsellä ei aavistustakaan...