Inteliä vastaan nostettu jo useita joukkokanteita

[FireFly Renaissance]

On kolmaskin vaihtehto. Kukaan ei ole huomannut koko asiaa.

Sinun logiikallasi jokaisessa maailman tuotteessa on suunniteluvirhe.

Virhe ei katoa vaikka sitä ei huomata. Mitä tällä semanttisella kikkailulla nyt kuvitellaan saavuttavan?

Todennäköisesti onkin. Harva ihminen osaa tehdä virheettömiä suunnitelmia. Yleensä yrityksissä nähdäänkin huomattava määrä vaivaa niiden virheiden havaitsemiseen.

 

[Cirrus]

Virhe ei katoa, vaikka sitä ei huomata.

Todennäköisesti onkin. Harva ihminen osaa tehdä virheettömiä suunnitelmia.

Nyt pääsimmekin maaliin.

Jokaisessa tuotteessa maailmassa on logiikkasi mukaan suunniteluvirhe. Tällöin termistä tulee arvoton, koska se ei tarkoita mitään. Se vain on.

Tästä seuraa että kaikki keskustelu siitä on hyödytöntä.

 

[FireFly Renaissance]

Tästä seuraa että kaikki keskustelu siitä on hyödytöntä.

Siitä voidaan toki aina keskustella kuinka vakava tämä kyseinen virhe on ja onko se sellainen, mitä ei olisi pitänyt olla mahdollista päästää tuotteeseen asti. Kaikkia virheitä ei suinkaan tarvi korjata, eivätkä kaikki virheet aiheuta vakavia tietoturvaongelmia.

 

[L2K2]

Virhe on helppo määritellä. Ohjelma pääsee käsiksi sellaiseen dataan, jolle sillä ei ole oikeuksia.

Nyt ongelmana on se, että täysin oikein toimivan prosessorin väärä toiminta mahdollistaa ei-luettavissa olevan datan arvojen päättelemisen.

Ohjelma ei pääse käsiksi dataan... se mahdollistaa datan päättelemisen... näiden välillä on hyvin iso ero. (Se dataan pääsy nyt esim. antaisi mahdollisuuden ajaa mielivaltaista koodia suoraan.)

Määrittele väärä toiminta... (vinkki: standardi ei sitä haluamallasi tavalla määrittele tässä kohtaa... se ei ota mitään kantaa suoritusaikoihin...) Nyt siis sen turvajärjestelmän itsensä voi ajatella toimivan eri nopeudella riippuen siitä mitä muuta samalla tehdään. Turvajärjestelmä kyllä aktivoituu ja estää lukemisen!

Mutta jos ohjelma ei oikeasti lukenutkaan... (Kuten mitä näissä tämänkertaisissa haavottuvuuksissa tehdään.)

Kunhan vaan huijasi prosessorin kuvittelemaan, että olisi ehkä voinut lukea... (Se ehtolause estää lukemisen mutta koodi toki kannattaa ajaa etukäteen ennen kuin vertailu oikeasti valmistuu – tässä oleellista on tehdä ehtolauseen vertailusta niin hidasta, että sisällön ehtii ajaa ja myös vaikka samalla huomata, että sitä koodia siellä sisällä ei sovi muutenkaan ajaa – näin tehdään ihan järjestään prosessoreissa kunhan vaan pitää huolen, että jos vertailu onkin ”epätosi” niin ajettu koodi ei saa tietenkaan tehdä mitään pysyviä muutoksia.)

Niin silti tämän jäljiltä jää kuitenkin mitattavissa oleva nopeusero seuraavaksi sen ei-ajetun ehdon jälkeen ajettavalle koodille... (Josta voi päätellä mitä muistissa on.)

Aika kuvaavaa, jos 2/3 isoa prosessorivalmistajaa ajaa samaan miinaan... vika on siinä, että prosessorien standardit eivät määrittele riittävän tarkasti miten pitäisi toimia... ns. ”oikein toimiva” prosessori ”vuotaa” epäsuorasti tietoa toiminnastaan. (Klassisesti tätä on mm. käytetty päättelemään salausavaimia, koska oikea toiminta johtaa joissain tapauksissa erisuureen laskenta-aikaan riippuen avaimen yksittäisten bittien arvoista. Näitä on sitten korjattu melko esoteerisillakin tavoilla...)

 

[FireFly Renaissance]

Clip

Siis ei nämä edelleenkään ole mitään standardeja vaan ihan yritysten itse omistamia ja itselleen suunnittelemia käskykantoja. Intel 64 on tasan sellainen kuin Intel sen on itse suunnitellut (ja mitä osia AMD:ltä lisensoinut). Myöskään haarautumisenennustus ja ehdollinen käskyjen suorittaminen ei perustu mihinkään ulkopuolisen organisaation standardiin.

Se siis on aivan sama onko se vika jo käskykannan suunnittelussa vai prosessorin suunnittelussa kun kummastakin vastaa sama yritys eikä sen taakse voi tässä mitenkään piiloutua.

 

[Hannibal]

Well... Ihmiset keksivät aina uusia tapoja rikkoa toisten tekemiä asioita.
Nyt firmat sitten sitten yrittävät uusin keinoin suojata käyttäjiä näistä uusista rikkomiskeinoilta.
Eli toimivat just niinkuin pitää. Se että nämä uudet suojauskeinit tekevät heidän tuotteistaan hitaampia, niin se on vähän voi, voi. Paljon pahempi olisi jos eivät yrittäisi pistää kapuloita ”pahojen poikien” rattaisiin. Siitä voisi sitten jo harkit syytettä. En tiedä mikä on lainmukainen pakollinen aika yrittää tukkia näitä uusi löydettyjä haavoittuvuuksia. Onko se vuosi, vai kaksi vai mitä?

Mutta hyvin vaikea on nähdä mitään sellaista virhettä mistä prossien tekijöitä voisi tässä yhteydessä pistää syytteeseen, paitsi jos kyseinen tietoturva aukko on tahallaan tehty tuotteeseen asiakkaiden vakoilemist varten. Eli jos voidaan osoittaa, että Intell on kliseisen ominaisuuden avulla urkkinut itselleen salaista tietoa asiakkaista. Nyt ei kuitenkaan vaikuta siltä. Murtovarkaat ovat vain keksineet (eli tietoasiantuntijat) uuden tavan, jolla wanha Abloy lukko on murrettavissa. Lähinnähän se on vain osoitus kyseisten ihmisten ammattitaidosta, että onnistuvat keksimään uuden tavan murtautua sisään järjestelmään.
Jotenka jatkossa on vai kehiteltävä vielä parempia lukkoja, jotka joku sitten myöhemmin taas murtaa jollain uudella mielikuvituksellisella keinolla. Kilpajuoksuahan tämä on ja välillä systeemin suunnittelijat vain häviävät tässä kilvanjuoksussa.

 

[hkultala]

[offtopic]

Mitään todellista muistikusetusta ei edes ollut, kun käytännössä mitään eroa ei peleissä huomannut menipä muistin käyttö 3,4Gb->3,6 tai yli.

Se oli enemmänkin median luoma juttu.

nVidian www-sivuilla on EDELLEEN 970n specseissä muistikaistaksi ilmoitettuna lukema, mitä sillä ei voi edes teoriassa saavuttaa, koska kaikki muistikanavat eivät voi toimia yhtä aikaa. Laite ei toimi kuten specsit väittää.

nvidian kusetus siis jatkuu EDELLEEN.

[/offtopic]

Tässä meltdownissa sen sijaan ei ole kyse mistään kusetuksesta, ei mistään huijauksesta, eikä mistään bugista. Intelin prosessorit toimivat tämän suhten täysin niin kuin specsit sanoo.

Ongelma vaan on se, että minkään prosessorin specseissä ei ole otettu tällaista SCA-hyökkäystä huomioon. Ja intel sattui tekemään prosessorinsa sattumalta tavalla, että näiden SCA-hyökkäysten hyödyntäminen on hiukan helpompaa Intelillä kuin muilla.


Toivon todella, että nuo oikeusjutut nauretaan ulos lakituvasta ja niitä ajavat joutuvat itse makselemaan oikein kovat lakimieskorvaukset intelille.

Intel on tämän suhteen toiminut täysin esimerkillisesti. Ongelmia alettiin korjata kaikessa hiljaisuudessa, jotta kaikki kriittiset järjestelmät saataisiin korjattua ennen kuin kukaan ilkeämielinen hakkeri osaisi näitä hyödyntää.

Tyhmät ihmiset vaan sensaationhalussaan lietsoo paniikkia ja syyttää inteliä asiasta, joka on ihan yhtälailla käyttisvalmistajien kuin intelin vika.

Tekopyhin kaikista on ehkä Linus, jonka pitäis olla fiksu ja jonka pitäisi kyllä tietää, millaisesta asiasta tässä on kyse, mutta joka itse on hyväksynyt Linuxin kerneliin SCA:iden suhteen vaarallisen eBPF-ominaisuuden jonka kautta näitä pääsee hyödyntämään.



Sen sijaan se valmistaja joka tässä on toiminut ei-esimerkillisesti on AMD joka 27.12 julkaisemassaan kernel-päivityksessä selitti oleellisia asioita meltdownin toimintaperiaatteesta - ENNEN sitä hetkeä kun kaikki oli korjattu ja yhdessä julkistettaisiin tiedot näistä ongelmista.

AMD olisi voinut julkaista patchinsä vain tekstillä "AMD processors work differently than intel and are not vulnerable do not need this to be enabled" tjsp. sanomatta mitään siitä toimintaperiaatteesta.

 

[demu]

Se, että tehdään tietoturvapäivitys ei mitenkään vaadi, että siellä olisi oikea vika. Nyt siis vaan löydettiin ovela suoritusaikaan perustuva ”side-channel attack”, jonka avulla täysin oikein toimivan prosessorin toiminnasta on mahdollista päätellä sellaisen datan arvoja, joita sillä hetkellä ajettava ohjelmakoodi ei voi lukea.



Edelleen määrittele virhe... tuote toimii tuossa suhteessa täsmälleen niin kuin x86-64 (ja tähän se iso litania lisämääreitä) -prosessorin kuuluu toimia – se hyökkäyksessä käytettävä esimerkkikoodi laskee täysin oikein eikä missään vaiheessa anna ohjelmalle mitään dataa mihin sillä ohjelmalla ei ole oikeutta mennä. (Siellä prosessorissa on myös lista ihan oikeita virheitä, joissa se toimii väärin. Niitä on paljon – kaikissa prosessoreissa. Näitä on listattuna siellä erratassa, mutta tämä ei ole sellainen.)

Nyt ongelmana on se, että täysin oikein toimivan prosessorin toiminnan nopeus mahdollistaa ei-luettavissa olevan datan arvojen päättelemisen.

Jos vähintään sadoissa miljoonissa tietokoneissa toimivat BIOS/EFI:t, kymmenet eri käyttöjärjestelmät / käyttöjärjestelmäversiot, tuhannet eri valmistohjelmistot pitää päivittää kiireellisinä hätäpäivityksinä niin kyllä kyseessä on vakava prosessorin suunnitteluvirhe riippumatta siitä, mitä tällä palstalla tai tulevaisuudessa lakituvissa saivarrellaan tämän virheen laadusta.

 

[JiiPee]

Edelleen määrittele virhe... tuote toimii tuossa suhteessa täsmälleen niin kuin x86-64 (ja tähän se iso litania lisämääreitä) -prosessorin kuuluu toimia

Eli siis AMD:n prosessoreissa on sitten suunnitteluvirhe koska se on x86-64 eikä ole altis Meltdown exploitille?
Kaikkea sitä oppii kun tätä palstaa lukee.

 

[Seppo77]

Hintojen nostaminen on aina mahdollista, mutta tällä hetkellä tilanne on aika paljon parempi kuin esimerkiksi aika ennen Ryzen/EPYC. Nyt markkinoilla on oikeasti hyviä vaihtoehtoja Intelille.

Intel aivan ylivoimainen pelaamiseen.

 

[hkultala]

Eli siis AMD:n prosessoreissa on sitten suunnitteluvirhe koska se on x86-64 eikä ole altis Meltdown exploitille?
Kaikkea sitä oppii kun tätä palstaa lukee.

Ei. kommenttisi on typerää olkiukkoilua.

Käskykannan speksi ei ota mitään kantaa siihen kuinka nopesti datan pitää välimuistista tulla missäkin tilanteessa tai millainen tarkkuus haarautumisenennustuksella pitää olla.

Jotta voidaan tehdä prosessoreita erilaisilla välimuisteilla ja erilaisilla haartautumisennustimilla.

 

[FireFly Renaissance]

Ei. kommenttisi on typerää olkiukkoilua.

Käskykannan speksi ei ota mitään kantaa siihen kuinka nopesti datan pitää välimuistista tulla missäkin tilanteessa tai millainen tarkkuus haarautumisenennustuksella pitää olla.

Jotta voidaan tehdä prosessoreita erilaisilla välimuisteilla ja erilaisilla haartautumisennustimilla.

Sarkasmia...

 

[Stephen Elop]

Määrittele ”vaarallinen koodi”. Kaikki prosessorit suostuvat ajamaan sen annetun koodin, koska se on määritelmällisesti aivan normaalia koodia. Koodi myös tekee täsmälleen sen mitä sen kuuluu tehdä – eikä siis koskaan oikeasti lue sitä arvoa.

Niille jotka eivät ole vielä tietoisia, niin se kikka on siis tehdä aivan normaalin näköinen ”out-of-bounds” tarkastus ehtolausekkeella – mutta tahallaan ihan väärälle muistiosoitteelle. Sitten vaan siellä ei-koskaan ajettavan ehtolausekkeen sisällä saadaan aikaan se, että siitä tutkittavan bitin* tilasta riippuen johonkin toiseen muuttujaan ladattaisiin jompikumpi kahdesta mahdollisesta arvosta (jotka sopivan kaukana toisistaan muistissa). Tämä arvo ei toki koskaan ilmesty siihen muuttujaan, koska koodia ei ”varsinaisesti” ajata (eli prosessori toimii teknisesti aivan oikein).

No, sitten vaan sen ehtolauseen jälkeen mitataan kauanko kestää oikeasti laskea sillä ykkösbitillä valittavalla arvolla jotain pientä. Jos kesto on ”pieni”**, niin bitti oli 1 jos ”suuri”*** niin 0. [Tässä kohtaa pitää myöntää, että en ole ihan 100 % varma ymmärsinkö oikein miten tuo tarkalleen toimii, mutta kuvittelisin niin tehneeni.] Tätä sitten toistetaan kunnes koko haluttu muistiavaruuden osa on ”luettu”.

* Bittimaskilla vaikka ”ja”-operaatio, sopiva ”shift-right” ja sitten vaikka kertolaskulla se valinta kahdesta muistiosoitteesta.

** Spekuloiva suorittaminen oli ehtinyt kuitenkin siirtää sen ohjelman oman datan välimuistiin. Joten lasku ei tarvitse pääsyä keskusmuistiin ja tapahtuu alle kymmenessä kellojaksossa (~10 ns).

*** Spekuloiva suorittaminen oli siirtänyt sen toisen datan välimuistiin, ja koska nämä datat olivat liian kaukana mahtuakseen molemmat samalla sinne, saatiin ”cache miss” joka maksaa sen joku 200 kellojaksoa (~100 ns).

Kiitos. Tämä oli hyvä selvennys tästä ongelmasta.

 

[El-Reino69]

Intel aivan ylivoimainen pelaamiseen.

Nämä väitteet voi jakaa virallisella Amd vs Intel väittelyketjussa

 

[Kosamiitti]

Eiköhän intelin inssit tasan tarkkaan tietäneet jo aikoinaan mitä tekivät.

Luotto oli vain siihen että ei tule julki.

 

[jive]

Melko surullista mikäli rauta jäisi serriksi ihan vain tietoturvasyistä koska ei enää bios-päivityksiä ym. tarjolla. Muutenhan tuo rauta wörkkisi aivan buenosti nettisurffailussa ja toimistokäytössä.

Tämä on myös oma huoli kun kalusto koostuu yrityslaitteistosta joka ei enää kuulu toimittajan aktiivisen tuen piiriin. Toisaalta kyllähän tästäkin voidaan jonkin sortin salaliittoteorioita kehitellä

 

[jive]

Sinun logiikallasi jokaisessa maailman tuotteessa on suunniteluvirhe, koska kukaan ei ole voinut ottaa huomioon ääretöntä määrää turvaskenaarioita.

Näin se tosin on, commercial < industrial < safety critical < mission critical. Kaksi jälkimmäistä on sitten sellaista maailmaa jossa ei tuntemattomia virheitä ole; -tunnettuja kylläkin.

 

[jive]

Tässä meltdownissa sen sijaan ei ole kyse mistään kusetuksesta, ei mistään huijauksesta, eikä mistään bugista. Intelin prosessorit toimivat tämän suhten täysin niin kuin specsit sanoo.

Totta, mutta tämä vain tekee entistä selvemmäksi sen että Intelillä on tiedetty mitä tehdään kun jätetään tarkistamatta suorituksen oikeustasot virhetilanteissa. Meltdown on pääsääntöisesti Intelin nopeusoptimoinneista johtuva. Spectren kohdalla olen samaa mieltä että se on sen verran teoriapohjaltaan monimutkainen, jotta voitaisiin väittää että kyse olisi tahallisuudesta.

Sinänsä vinkeätä että vanha kunnon IA64 taitaa olla immuuni näille kaikille pl. viimeisin iteraatio.

 

[Nerkoon]

Tietoturvaa se parantaa.

Yhä vain naurettavampaa sontaa suollat. Virhe seuraa tästä yleisestyksestä vain siinä tapauksessa että joku on luvannut 100% turvallisuuden. Kukaan ei maailmassa lupaa sellaista mihinkään tuotteeseen. Vai onko intel luvannut?

Entäs jos ja kun sen tuotteen osto on päätetty sen luvatun nopeuden takia? Ja nyt suunnitteluvirheen takia se nopeus muuttuu niin olennaisesti, että kilpaileva tuote olisikin ollut parempi? Kyllä minulle ainakin tulisi kusetettu olo. Ja tässä pitää muistaa, että Intelillä on koko ajan ollut maailman parhaat resurssit sekä henkiseltä, että rahalliselta puolelta joten tuollainen bugi osoittaa vain täydellistä laiskuutta tuotetestauksessa ja suunnittelussa. Tälläistä sattuu kun lähes monopoliasemassa oleva firma keskittyy henkselien paukutukseen ja unohtaa tuotteensa.

 

[Cirrus]

Entäs jos ja kun sen tuotteen osto on päätetty sen luvatun nopeuden takia? Ja nyt suunnitteluvirheen takia se nopeus muuttuu niin olennaisesti, että kilpaileva tuote olisikin ollut parempi? Kyllä minulle ainakin tulisi kusetettu olo. Ja tässä pitää muistaa, että Intelillä on koko ajan ollut maailman parhaat resurssit sekä henkiseltä, että rahalliselta puolelta joten tuollainen bugi osoittaa vain täydellistä laiskuutta tuotetestauksessa ja suunnittelussa. Tälläistä sattuu kun lähes monopoliasemassa oleva firma keskittyy henkselien paukutukseen ja unohtaa tuotteensa.

Ja ensin varmaan todistat nyt sen suunnitteluvirheen? En jaksa kommentoida suunniteluvirheestä seuraavia asioita, koska ei olla päästy edes siihen vaiheeseen että sunnitteluvirhe on todistettu.

 

[Nerkoon]

Ja ensin varmaan todistat nyt sen suunnitteluvirheen? En jaksa kommentoida suunniteluvirheestä seuraavia asioita, koska ei olla päästy edes siihen vaiheeseen että sunnitteluvirhe on todistettu.

Jos prosessori ei tee riittäviä tarkistuksia tai tekee ne liian myöhään, niin se kuulostaa minusta varsin selvältä suunnitteluvirheeltä

 

[hkultala]

Totta, mutta tämä vain tekee entistä selvemmäksi sen että Intelillä on tiedetty mitä tehdään kun jätetään tarkistamatta suorituksen oikeustasot virhetilanteissa. Meltdown on pääsääntöisesti Intelin nopeusoptimoinneista johtuva. Spectren kohdalla olen samaa mieltä että se on sen verran teoriapohjaltaan monimutkainen, jotta voitaisiin väittää että kyse olisi tahallisuudesta.

Sinänsä vinkeätä että vanha kunnon IA64 taitaa olla immuuni näille kaikille pl. viimeisin iteraatio.

n. viidennen kerran: intel ei jätä tarkastamatta mitään, vaan vain reagoi sen tarkastuksen tulokseen myöhemmin kuin muut. Tämä myöhemminkin tulokseen reagoiminen on täysin käskykantaspeksin mukaista.

Ja kun tämä valinta on tehty, ei olla vaan osattu ottaa huomioon sitä että joku keksii täysin uudentyyppisen SCAn joka sitä hyödyntää.


Turvallisuutta uudentyyppistä SCAta vastaan verrata vaikka siihen, että ennnen toista maailmansotaa olisi tehty pommisuoja joka kestää kaikki perinteisiin räjähteisiin perustuvat pommit. ja sitten joku räjäyttääkin ydinpommin.

ei vaan voi olettaa että tällaiseen voitaisiin varautua.

 

[Cirrus]

Jos prosessori ei tee riittäviä tarkistuksia tai tekee ne liian myöhään, niin se kuulostaa minusta varsin selvältä suunnitteluvirheeltä

Tämän ketjun paskin todiste tuli juuri tässä. Sinusta kuulostaa siltä. Huoh.

Ja toisekseen et ole ymmärtänyt edes vikaa vaikka useampi henkilö on avannut sitä tässä tarkasti.

 

[jive]

n. viidennen kerran: intel ei jätä tarkastamatta mitään, vaan vain reagoi sen tarkastuksen tulokseen myöhemmin kuin muut. Tämä myöhemminkin tulokseen reagoiminen on täysin käskykantaspeksin mukaista.

Ja kun tämä valinta on tehty, ei olla vaan osattu ottaa huomioon sitä että joku keksii täysin uudentyyppisen SCAn joka sitä hyödyntää.

Höpöhöpö, DrK oli tiedossa jo ainakin kaksi vuotta sitten. Ei Meltdown niin uusi tekniikka ole kuin halutaan antaa ymmärtää.

GitHub - sslab-gatech/DrK: The DrK Attack - Proof of concept

 

[jar-fin]

taitaa olla niin ettei tuo virhe vaikuta mitenkään tai todella vähän tavis käyttäjään,ja aniharvaan muuhunkaan käyttäjään.

 

[Nerkoon]

taitaa olla niin ettei tuo virhe vaikuta mitenkään tai todella vähän tavis käyttäjään,ja aniharvaan muuhunkaan käyttäjään.

Kerropa tuo näkemyksesi yrityksille. Siellä siitä ollaan aika tavalla eri mieltä.

 

[hkultala]

Höpöhöpö, DrK oli tiedossa jo ainakin kaksi vuotta sitten. Ei Meltdown niin uusi tekniikka ole kuin halutaan antaa ymmärtää.

GitHub - sslab-gatech/DrK: The DrK Attack - Proof of concept

lake-sarjan ytimien mikroarkkitehtuuri on suunniteltu selvästi yli kaksi vuotta sitten, eli ennen tuonkin keksimistä. Ainoa intelin ehkä tuon jälkeen suunniteltu mikroarkkitehtuuri on goldmont plus, mutta sekin pohjaa hyvin vahvasti ennen tuota suunniteltuun goldmontiin.

 

[jive]

lake-sarjan ytimien mikroarkkitehtuuri on suunniteltu selvästi yli kaksi vuotta sitten, eli ennen tuonkin keksimistä. Ainoa intelin ehkä tuon jälkeen suunniteltu mikroarkkitehtuuri on goldmont plus, mutta sekin pohjaa hyvin vahvasti ennen tuota suunniteltuun goldmontiin.

Tämän mukaan Inteliltä menee noin 24kk pyöräyttää uarch variantti, joten siinä ja siinä. http://seminarisempresa.fib.upc.edu...-documents/00/document/01 Microprocessors.pdf

 

[Cirrus]

Tämän mukaan Inteliltä menee noin 24kk pyöräyttää uarch variantti, joten siinä ja siinä. http://seminarisempresa.fib.upc.edu/aulesempresa/2011/programes/INTEL/Llista-documents/00/document/01 Microprocessors.pdf

Pystytkö avaamaan drk:n suhdetta meltdowniin ja sitä päättelyketjua että drk:sta olisi pitänyt seurata intellin arkkitehtuurin uudellen suunnittelu?

Googletus meltdown ja drk hakusanoilla ei äkkiseltään tuottanut oikein mitään.

 

[Stephen Elop]

En nyt tarkistanut ajankohtia, joten seuraavakin voi olla ihan turhaa kirjoittelua, mutta mites seuraava asia, onko edes etäisesti mahdollista saada jotain korvauksia?

Oletan että kahvijärvi julkistettiin vasta kun Inteliä oltiin tiedotettu ongelmasta. Nyt ongelman korjaamisen jälkeen kahvijärviprossut eivät ole tietyissä tehtävissä niin nopeita kuin julkaisun aikana väitettiin. Kahvijärvi prossuja kyllä valmistettiin jo keväällä iso määrä ja tulivat siis kesällä myyntiin. Tää on musta se ainoa skenaario jolla jotain korvauksia voisi kahvijärven ostaneet saada. Muiden prossujen omistajat ei kyllä kuulu saada yhtään mitään. Kysehän on nyt sellaisen ilmiön/haitan hyödyntämisestä mitä ei ole spesifioitu.

Ihan sama juttu vanhan ohjelmakoodin osalta. Buffer overrun tapauksia ei oltu speksattu ohjelmiin (API:iin kylläkin), jolloin sitä hyödyntäen pääsi tekemään haitakkeita.

 

[Griffin]

Ainoastaan silloin on olemassa virhe, jos asia X ei toimi, niin kuin se on speksattu.

Suojausjärjestelmiä (mm. mekaanisia, elektronisia ja ohjelmallisia) on tehty kautta aikain. Monia on pidetty aikanaan erinomaisina MUTTA sitten joku on keksinyt, miten ko järjestelmä ohitetaan ja on pitänyt tehdä uusi. Näissä ei ole mitään uutta tällä saralla, enkä näe miten joukkokanteet noista voisivat menestyä. Ainoastaan jos Intel on ilmoittanut järjestelmän olevan ehdottoman varmasti täysin murtamaton, ikinä.
---------------------------------------
Paremmin voisi menestyä joukkokanne jotakuta mainostajaa vastaan, jonka palvelun kautta on ujutettu koneelle haittascripti, kun mainostajan palvelu on murrettu tai siellä on muutoin hölmöilty.

Jos turvallisuutta haluaa lisätä, niin kaikki mahdolliset scriptit pitäisi aina ja poikkeuksetta estää.

 

[FireFly Renaissance]

Tämän ketjun paskin todiste tuli juuri tässä. Sinusta kuulostaa siltä. Huoh.

Ja toisekseen et ole ymmärtänyt edes vikaa vaikka useampi henkilö on avannut sitä tässä tarkasti.

Eiköhän me olla jo yhtä mieltä siitä, että sellaista asiaa kuin virhe ei sinun maailmassasi ole olemassa. Ainoastaan "ongelmia". Jos emme suostu puhumaan edes samaa äidinkieltä niin aika turha on vängätä.

(jotakuinkin) Kaikki muut onneksi tuntuvat ymmärtävän mistä puhutaan.

 

[FireFly Renaissance]

Ainoastaan silloin on olemassa virhe, jos asia X ei toimi, niin kuin se on speksattu.

Eli sellaista asiaa kuin virheellinen speksi ei voi olla olemassa. Tämä selvä. Pitää muistaa töissä jatkossa.

 

[Griffin]

Eli sellaista asiaa kuin virheellinen speksi ei voi olla olemassa. Tämä selvä. Pitää muistaa töissä jatkossa.

Ei ole olemassa speksiä, joka ottaisi kaikki mahdollisuudet huomioon. Lukitusjärjestelmä ja suojaukset on aina murrettu jossain vaiheessa, olipa ne speksattu kuinka hyvin tahansa. On todella naivia olettaa, että joku speksi olisi täydellinen, eikä sitä pitäisi muuttaa joskus tulevaisuudessa. Paskoja speksejä on voimassa ihan yhteiskunnallisellakin tasolla, mutta jostain syystä niitä ei edes haluta muuttaa, vaikka on täysin selvää, että monia, todella vakavia ongelmia johtaa juurensa niistä.

Nytkun tuo kaipaa päivittämistä, niin tuo epäilemättä päivitetään.

SITÄPAITSI
Perusprosessorissa ei ole mitään järkeä satsata etupäässä turvallisuuteen. Kyllä ainakin itse otan mieluummin suorituskykyisen prossun, jossa saattaa paljastua turvallisuusongelmia, kuin etananhitaan prossun, joka takaa, että JOS ohjelmissa ei ole virheitä (ja niissähän on aina), niin kone on tietoturvallinen.
-----------------
Speksi on virheetön, niin pitkään, kun joku ei keksi jotain tapaa esim kiertää tuollaista tietoturvaominaisuutta.
Jos Intel valmistaisi esim 2 vuoden päästä prossuja tuolla speksillä ja VÄITTÄISI niitä turvallisiksi tuon ongelman osalta, niin sitten joukkokanteella olisi jopa pohjaa, ei aikaisemmin.

Eiköhän tuossa mene 2-5 vuotta, että tuo ongelma on korjattu enemmän ja vähemmän, myös prossutasolla.
Ehkä nuo tieturva-asiat pitäisi ajaa omilla, dedikoiduilla coreilla, järjestelmäkutsuina.

 

[FireFly Renaissance]

Ei ole olemassa speksiä, joka ottaisi kaikki mahdollisuudet huomioon. Lukitusjärjestelmä ja suojaukset on aina murrettu jossain vaiheessa, olipa ne speksattu kuinka hyvin tahansa. On todella naivia olettaa, että joku speksi olisi täydellinen, eikä sitä pitäisi muuttaa joskus tulevaisuudessa. Paskoja speksejä on voimassa ihan yhteiskunnallisellakin tasolla, mutta jostain syystä niitä ei edes haluta muuttaa, vaikka on täysin selvää, että monia, todella vakavia ongelmia johtaa juurensa niistä.

Näinpä, mutta mitähän tekemistä tällä nyt on minkään kanssa?

Ei se onko joku virhe vaikea vai helppo havaita muuta millään tavalla sitä onko kyse virheestä.

Speksi on virheetön, niin pitkään, kun joku ei keksi jotain tapaa esim kiertää tuollaista tietoturvaominaisuutta.
Jos Intel valmistaisi esim 2 vuoden päästä prossuja tuolla speksillä ja VÄITTÄISI niitä turvallisiksi tuon ongelman osalta, niin sitten joukkokanteella olisi jopa pohjaa, ei aikaisemmin.

Virheen löytyminen ei millään tavalla määritä sitä onko kyseessä virhe vai ei. Virhe jota ei ole löydetty on vain piilossa oleva virhe.

Onko se äidin(?)kielen puhuminen oikeasti näin vaikeaa, että pitää yrittää keksiä väkisin jotain ihan omia määritelmiä? Ei pitäisi olla mitään epäselvää siitä, mitä virhe suomen kielessä tarkoittaa.

Perusprosessorissa ei ole mitään järkeä satsata etupäässä turvallisuuteen. Kyllä ainakin itse otan mieluummin suorituskykyisen prossun, jossa saattaa paljastua turvallisuusongelmia, kuin etananhitaan prossun, joka takaa, että JOS ohjelmissa ei ole virheitä (ja niissähän on aina), niin kone on tietoturvallinen.

Valitettavasti samaa arkkitehtuuria myydään myös Xenonina konesaleihin, ja siellä on vähän eri vaatimukset kuin pelikoneessa. Myös softan puolella.

 

[Griffin]

Näinpä, mutta mitähän tekemistä tällä nyt on minkään kanssa?

Ei se onko joku virhe vaikea vai helppo havaita muuta millään tavalla sitä onko kyse virheestä.


Virheen löytyminen ei millään tavalla määritä sitä onko kyseessä virhe vai ei. Virhe jota ei ole löydetty on vain piilossa oleva virhe.

Onko se äidin(?)kielen puhuminen oikeasti näin vaikeaa, että pitää yrittää keksiä väkisin jotain ihan omia määritelmiä? Ei pitäisi olla mitään epäselvää siitä, mitä virhe suomen kielessä tarkoittaa.



Valitettavasti samaa arkkitehtuuria myydään myös Xenonina konesaleihin, ja siellä on vähän eri vaatimukset kuin pelikoneessa. Myös softan puolella.

Speksi tehtiin tietyllä tavalla, jonka katsottiin olevan HYVÄ. Kukaan ei osoittanut aikaisemmin speksissä olevan PUUTTEITA. näinollen valmistetuissa prossuissa, sikäli, kun ne tuota speksiä noudattivat EI OLE VIRHETTÄ, joten noilla joukkohaasteilla ei ole siinä mielessä mitään pohjaa, ja on täysin turhaa mässyttää, että prossuissa olisi "virhe".

Intel on tehnyt korjaustoimenpiteet ja jos ne estävät tuon ei halutun ominaisuuden hyödyntämisen, niin tietoturvan kannalta kaikki on ok. Lisäksi tietokoneen ollessa kyseessä on täysin sama, onko se konesalissa tai olohuoneessa, niin tullaisia puutteita voi paljastua erittäin helposti. Ei tämä ole mitenkään ainutkertaista, eikä varmasti tule myöskään ainutkertaiseksi jäämään. Samaan kuoppaan kun astui ARM valmistajiakin.

 

[FireFly Renaissance]

Speksi tehtiin tietyllä tavalla, jonka katsottiin olevan HYVÄ. Kukaan ei osoittanut aikaisemmin speksissä olevan PUUTTEITA. näinollen valmistetuissa prossuissa, sikäli, kun ne tuota speksiä noudattivat EI OLE VIRHETTÄ, joten noilla joukkohaasteilla ei ole siinä mielessä mitään pohjaa, ja on täysin turhaa mässyttää, että prossuissa olisi "virhe".

Intel on tehnyt korjaustoimenpiteet ja jos ne estävät tuon ei halutun ominaisuuden hyödyntämisen, niin tietoturvan kannalta kaikki on ok. Lisäksi tietokoneen ollessa kyseessä on täysin sama, onko se konesalissa tai olohuoneessa, niin tullaisia puutteita voi paljastua erittäin helposti. Ei tämä ole mitenkään ainutkertaista, eikä varmasti tule myöskään ainutkertaiseksi jäämään. Samaan kuoppaan kun astui ARM valmistajiakin.

Onko tällä turhanpäiväsellä lässytyksellä joku tarkoitus? Yllä olevassa ei ole mitään uutta sisältöä eikä se siten myöskään muuta tosiasioita millään tavalla. Ihan turhaa floodaamista.

Prossuissa on virhe. Piste. Sillä kuinka paljon sinä jaksat täällä asiasta itkeä ei nyt muuta sitä millään tavalla.

Virheen olemassaolo ei tarkoita sitä, että joukkokanne olisi automaattisesti pätevä, toisin kuin tunnut kuvittelevan.

Kielitoimiston sanakirja

Työväenopisto varmaan tarjoaa avuksi suomen kielen kursseja, mikäli on noin suuria vaikeuksia ymmärtää samaa kieltä mitä me muut puhumme.

 

[L2K2]

Onko se äidin(?)kielen puhuminen oikeasti näin vaikeaa, että pitää yrittää keksiä väkisin jotain ihan omia määritelmiä? Ei pitäisi olla mitään epäselvää siitä, mitä virhe suomen kielessä tarkoittaa.

– – Xenonina (heh) konesaleihin – –

Työväenopisto varmaan tarjoaa avuksi suomen kielen kursseja, mikäli on noin suuria vaikeuksia ymmärtää samaa kieltä mitä me muut puhumme.

Loppuiko asia-argumentit kesken kun piti ruveta haukkumaan lähes kaikkia muita ketjuun vastanneita?

PS. Se on Xeon ja niitä on myös ihan työpöydällekin.. ;-)

 

[FireFly Renaissance]

Loppuiko asia-argumentit kesken kun piti ruveta haukkumaan lähes kaikkia muita ketjuun vastanneita?

PS. Se on Xeon ja niitä on myös ihan työpöydällekin.. ;-)

Kaikkia? Ymmärtääkseni täällä suurin osa ei harrasta mitään lapsellista vänkäämistä itsestäänselvästä asiasta jossa ei pitäisi olla mitään epäselvää kenellekään.

 

[L2K2]

Kaikkia? Ymmärtääkseni täällä suurin osa ei harrasta mitään lapsellista vänkäämistä itsestäänselvästä asiasta jossa ei pitäisi olla mitään epäselvää kenellekään.

Vaikka totuus ei olekaan demokratia, niin suosittelen silti vielä laskemaan montako eri ihmistä vastaan vänkäsit. Itse poistun tästä Mark Twainin ohjeistamana takavasemmalle (ja tällä kertaa muistan myös poistaa ketjun seuratuista)..

 

[JiiPee]

Ja ensin varmaan todistat nyt sen suunnitteluvirheen? En jaksa kommentoida suunniteluvirheestä seuraavia asioita, koska ei olla päästy edes siihen vaiheeseen että sunnitteluvirhe on todistettu.

Suunnitteluvirhe on tullut todistetuksia kun korjaavia toimenpiteitä on tarvinnut tehdä.
Lisäksi voi suunnitteluvirheestä lukea lisää täältä
https://meltdownattack.com/meltdown.pdf

 

[JaniKari]

Ei kait missään x86 speksissä käsketä ajamaan if-käskyn molempia valintoja? Jos intel näin tekee niin sehän on selvästi speksin vastaista toimintaa. Eihän tässä ole mitään epäselvää...

 

[hkultala]

Ei kait missään x86 speksissä käsketä ajamaan if-käskyn molempia valintoja? Jos intel näin tekee niin sehän on selvästi speksin vastaista toimintaa. Eihän tässä ole mitään epäselvää...

Arkkitehtuurispeksi ottaa kantaa vain arkkitehtuurissa näkyviin asioihin.

Arkkitehtuurillisesti näkyvään rekisteriin arvoa ei koskaan kirjoteta, ellei sitä oikeastikin olisi siihen pitänyt kirjoittaa. Se arkkitehtuurispeksi ei ota YHTÄÄN kantaa siihen MITEN se käsky suoritetaan, ja mitä kaikkia temppuja siinä tehdään, kunhan vain arkkitehtuurillisesti näkyvään tulosrekisteriin päätyy oikeat arvot oikeassa järjestyksessä.

Ja jos prosessorilta vaadittaisiin, että kaikki pitää suorittaa täsmälleen samalla tavalla kuin alkuperäisessä prosessorissa, sitten meillä olisi 4 Ghz skylaken sijasta 2 GHz "8064"(*) jossa jokaisen käskyn suorittamiseen menisi useita kellojaksoja(efektiivisesti yhden sijasta), ja jossa montaa käskyä ei voitaisi suorittaa rinnakkain, ja lopputuloksena suorituskyky olisi alle kymmenestosa siitä 4 GHz skylaken suorituskyvystä

Sama kuin että jos sinä tilaat paketillesi kirjoituksen Oulusta Helsinkiin. Siinä kuljetussopimuksessa sovitaan vain, että paketti kulkee Oulusta Helsinkiin, tietystä osoitteesta tiettyyn osoitteeseen. Se saa ihan vapaasti kulkea Oulusta Helsinkiin joko lentokoneella, junalla, rekalla tai laivalla, ja se saa kiertää vaikka Uumajan kautta, tai kulkea välillä matkalla saman välin edestakaisin, kunhan se vain päätyy helsingissä oikeaan osoitteeseen, ja saapuu perille luvatussa ajassa.



(*) hypoteettinen 8086n suora laajennos 64-bittiseksi jossa vain rekisterit levennetty yms. muttei edes mitään liukuhihnoitusta tms.

 

[hkultala]

Suunnitteluvirhe on tullut todistetuksia kun korjaavia toimenpiteitä on tarvinnut tehdä.
Lisäksi voi suunnitteluvirheestä lukea lisää täältä
https://meltdownattack.com/meltdown.pdf

Tuossa paperissakaan ei missään väitetä että intelin prosessorissa olisi mitään vikaa. Tuon paperin kirjoittajilla jos keillä olisi se auktoriteetti sen sanomiseen, jos se pitäisi paikkaansa.

Paperissa hyvin selvästi todetaan vain intelin suorittimien bugisuuteen liittyen:

The processor ensures correct program execution, by simply discarding the results of the memory lookups (e.g., the modified register states), if it turns out that an instruction should not have been executed. Hence, on the architectural level (e.g., the abstract definition of how the processor should perform computations), no security problem arises.

Sen sijaan inteliä syyttää "virheestä" ja "bugista" lähinnä ihmiset joilla ei ole siitä mitään ymmärrystä. (ja linus, joka muuten tykkää flamettaa kaikkia)

 

[Marti77]

AMD:llä oli samantapaiset ongelmat phenom ja opteron prossessoreissa eikä nekään hirveästi myyntinumeroita pudottaneet vaikka bios päivityksen jälkeen suorituskyky laski tietyissä ohjelmissa.
Tietysti Amd oli pohjamudissa silloin niin vaikutus oli pienempi myös sen takia.
Toivottasti nähdään hieman hinnanalennuksia ongelmien takia kun nuo joukkokanteet harvoin menevät läpi ja usein toinen osapuoli joutuu korvamaan kulut tai sovitaan oikeuden ulkopuolella.

 

[FireFly Renaissance]

Sen sijaan inteliä syyttää "virheestä" ja "bugista" lähinnä ihmiset joilla ei ole siitä mitään ymmärrystä. (ja linus, joka muuten tykkää flamettaa kaikkia)

Jos prosessori ei toimi oikein (odotetusti) kyseessä on virhe. Saa olla melkoinen fanipoika, jos väittää muuta.

Sinun pitäisi tutkijana ymmärtää miten tieteellinen kirjoitus strukturoidaan ja mikä on tieteellisen kirjoituksen tyyli. Tuossa lainauksessa ei missään vaiheessa sanota, että kyseessä ei ole virhe, siinä sanotaan, että arkkitehtuurin tasolla turvauhkaa ei ole. Tätähän kukaan ei ole väittänytkään virhe on prosessorin suunnittelussa. Tieteellisessä kirjoittamisessa on yleensä tapana vain kylmästi todeta miten asiat ovat.

Jos nyt jollakin on edelleen vaikeuksia hahmottaa mitä sana virhe tarkoittaa, tämä kielitoimiston sanakirjan määritelmä auttaa:

virhe48 hyväksyttävästä t. normaalista poikkeava seikka, vika.
1. erheellinen, väärä, viallinen suoritus, erehdys, hairahdus, lapsus; sellaisen tulos. Pieni, paha, vähäinen virhe. Arviointi-, muistivirhe. Mittausvirhe. Kirjoitus-, käännös-, ääntämisvirhe. Virkavirhe. Tehdä virhe, virheitä. Teki sen virheen, ettei kysynyt, mihin lapset tarvitsivat moottorisahaa. Oli paha virhe vaihtaa työpaikkaa. Hoidossatapahtunut virhe. Selostukseen pujahti asiavirheitä. Korjata, oikaista virhe.
Ark. Pilkun pois jättämisestä otettu [= arvosanaan vaikuttavaksi merkitty] virhe. Pelaaja otti [= teki tahallaan] virheen.
2. vajavuutta, vajaalaatuisuutta, -kuntoisuutta tms. aiheuttava seikka, vika. Maku-, pintavirhe. Virhe tuotteen värissä. Koiran rakenteen virheet. Kaikilla meillä on omat virheemme.

Haluaisin edelleen kuulla näiltä "ei se virhe ole" sepustelijoilta, että mikä se sitten on? Tarjottuna on jo "ongelma". Mikä tosiasiassa on virheen seuraus. Aina kun asiat eivät toimi, kuten niiden pitäisi, esiintyy virhe.

 

[JiiPee]

Ei. kommenttisi on typerää olkiukkoilua.

Käskykannan speksi ei ota mitään kantaa siihen kuinka nopesti datan pitää välimuistista tulla missäkin tilanteessa tai millainen tarkkuus haarautumisenennustuksella pitää olla.

Jotta voidaan tehdä prosessoreita erilaisilla välimuisteilla ja erilaisilla haartautumisennustimilla.

Jos tuotteessa on virhe niin silloin on se ja sama että miten mikäkin asia haarautuu. Se ei tuotteesta virhettä poista.

 

[JiiPee]

Tuossa paperissakaan ei missään väitetä että intelin prosessorissa olisi mitään vikaa. Tuon paperin kirjoittajilla jos keillä olisi se auktoriteetti sen sanomiseen, jos se pitäisi paikkaansa.

Niinhän nuo teknisjargon paperit on aina kirjoitettu, se on sitten lukijasta kiinni että ymmärtääkö lukemaansa vai ei.
Intelin prosessoreissa on suunnitteluvirhe, jos ei olisi niin ei myöskään olisi mitään Meltdown paskamyrskyä nyt.
Pitäisi olla hyvin helposti ymmärrettävä asia ihan jokaiselle.

 

[Cirrus]

Suunnitellaan silta kestämään 60 tonnia.
Trafi alkaa jakamaan erikoislupia jopa 100 tonnin rekoille.
Siltaa päivitetään kestämään 100 tonnia.

Oliko sillassa suunniteluvirhe?

 

[JiiPee]

Suunnitellaan silta kestämään 60 tonnia.
Trafi alkaa jakamaan erikoislupia jopa 100 tonnin rekoille.
Siltaa päivitetään kestämään 100 tonnia.

Oliko sillassa suunniteluvirhe?

Pikemminkin suunnitellaan silta nelikaistaiseksi ja myöhemmin huomataan että se ei kestäkkään liikennettä kaikilla 4 kaistalla jolloin yksi kaistoista suljetaan joka taas aiheuttaa sen että sillan suorituskyky kärsii ruuhkaaikoina.

Kyllä suunnitteluvirhe.