AMD:n ja Intelin prosessoreista löytyi uusi Spectren kaltainen haavoittuvuus

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Prosessoreiden sivukanavahaavoittuvuuksien pandoran lipas aukesi toden teolla 2018 Spectre- ja Meltdown-haavoittuvuuksien myötä. Haavoittuvuudet koskivat vaihtelevasti niin AMD:n, Armin kuin Intelinkin suunnittelemia prosessoreita ja niitä on sittemmin korjailtu sekä rautatasolla itse prosessoriarkkitehtuurien osalta että ohjelmistopuolella.

Nyt arkkitehdit joutuvat palaamaan jälleen suunnittelupöydän ääreen, sillä Virginian yliopiston (University of Virginia School of Engineering and Applied Science) tutkijat ovat löytäneet uuden hyökkäyksen, joka vähät välittää Spectre-suojauksista. Ashish Venkatin johtaman tutkijaryhmän kertoo löytäneensä uuden tavan hyväksikäyttää AMD:n ja Intelin prosessoreiden mikrokäskyvälimuistia (micro-op cache) tiedon varastamiseksi.

Tutkijoiden julkaiseman paperin mukaan tietoa voidaan varastaa, kun prosessori hakee mikrokäskyvälimuistista käskyjä spekulatiivista suoritusta varten. Venkat vertaa tilannetta lentokenttään, jossa turvatarkastuksessa jätettäisiin tarkistamatta lentoliput, koska ne tarkistetaan kuitenkin myöhemmin. Vaikka turhaan läpi päästetyt käskyt hylätään myöhemmin, niitä ehditään siinä välissä hyödyntämään datan varastamisessa.

Venkatin johtamien tutkijoiden mukaan heidän löytämäänsä hyökkäystä ei voida paikata ainakaan yhtä helposti, kuin alkuperäiset Spectre-hyökkäykset. Käytännössä korjausta pidetään jopa mahdottomana jo julkaistujen ja valmiiksi suunniteltujen prosessoreiden osalta, sillä mikrokäskyvälimuisti ja spekulatiivinen suoritus ovat liian merkittäviä tekijöitä nykypäivän prosessoreiden suorituskyvyn takana.

Lähde: University of Virginia, I See Dead μops: Leaking Secrets via Intel/AMD Micro-Op Caches (PDF)

Linkki alkuperäiseen juttuun

 

[Virittäjä]

Tällä ei taida olla väliä tietokoneen peruskäytössä? Siis minerit, pedarit ja suomalaisen musan warettajat voi huolestua? Vai voiko tällä "tiedon varastamisella" rikkoa rautaa tai sotkea käyttistä/softia?

 

[zepi]

Tällä ei taida olla väliä tietokoneen peruskäytössä? Siis minerit, pedarit ja suomalaisen musan warettajat voi huolestua? Vai voiko tällä "tiedon varastamisella" rikkoa rautaa tai sotkea käyttistä/softia?

No jos menet huonolle nettisivulle jossa on pahaa javascriptiä, niin se voi käsittääkseni lukea toisesta prosessista salausavaimet jolla siellä pyörivä nettipankki on auki. Onko se sitten paha?

Ja kun monet modernit softat ovat vain nettisivuja ja niissä on vaikka mitä javascript-mainoksia yms. Niin ongelmat ovat hankalia...

Joku asiaan paremmin perehtynyt voisi arvioida riskejä tosielämässä.

 

[joghe]

Takaportteja jotka paljastumisen jälkeen ovat haavoittuvuksia.
Enpä usko että linjalta koskaan tulee prosessoria jossa ei olisi jokin piilotettu takaportti.

 

[embedded]

Luulisi että ei nyt ihan selaimen js:llä pääse suorittamaan noin tarkkoja komentoja...

 

[Luckyo]

No jos menet huonolle nettisivulle jossa on pahaa javascriptiä, niin se voi käsittääkseni lukea toisesta prosessista salausavaimet jolla siellä pyörivä nettipankki on auki. Onko se sitten paha?

Ja kun monet modernit softat ovat vain nettisivuja ja niissä on vaikka mitä javascript-mainoksia yms. Niin ongelmat ovat hankalia...

Joku asiaan paremmin perehtynyt voisi arvioida riskejä tosielämässä.

Tämä riski oli vain Meltdown-haavoittuvuuden kohdalla, oli täysin teoreettinen ja vain kesti muutaman viikon ennen kuin käytännössä kaikki käytössä olevat selaimet laskivat tarvittavien JS prosessien tarkuuden niin että haavoittuvuus ei ollut enää toimiva edes teoreettisesti.

Spectre on palvelinmaailman asioita, eli "voin lukea toisen samalla fyysisella palvelimella olevan virtuaalikoneen alueella olevaa tietoa". Kotikäyttäjälle sen riskit ovat olemattomia.

 

[Romi]

Prosessorien toiminnassahan on ajettu tehokkuutta, joten aika varmasti tarkoituksella on jätetty joitakin tunnistus kutsuja pois, kuten artikkelissa vihjataankin. Lähinnä se miten kyseiseen välimuistiin pääsee käsiksi on ratkaisevaa.

tosi nopea vilkaisu tutkimus paperiin... (virheellinen tulkinta hyvin mahdollista)
array taulukoita hyväksi käyttäen näyttää tekniikat toimivan, ajataan prosessori ennustamaan taulukon kokoa, jota sitten huijaamalla suuremmaksi kuin se on, päästään käsiksi taulukon ulkopuoliseen dataan (tavu, spectre1). Sitten höpisevät tämän tavun maskittamisesta (seulotaan bitit) ja sen palauttamisesta bitti kerrallaan välimuistiin, jonka käsittelyn pituus sitten kertoo mistä välimuistista data tuli. 8 säikeellä >=0,1MBs. tai noin puolet siitä virheen korjauksella. Ero spectreen taitaa olla eri välimuistin lukemisessa (ajoitus) ja tuo tavu/bitti menetelmä.

 

[moukula]

Spectre on palvelinmaailman asioita, eli "voin lukea toisen samalla fyysisella palvelimella olevan virtuaalikoneen alueella olevaa tietoa". Kotikäyttäjälle sen riskit ovat olemattomia.

Pilvipalvelut ovat kuitenkin sen verran iso osa nykyistä web-infrastruktuuria että luulisi tällaisten asioiden kiinnostavan. Toki hyökkäystä voi olla vaikea kohdentaa tarkasti, mutta jos saat sinne pilveen pyörimään softaa joka lukee kulloinkin ajossa olevalta palvelinraudalta muiden käyttäjien salausavaimia ja muuta dataa niin joskus voi kohdalle sattua jättipotti. Tälläkin hetkellä ja varmasti tulevaisuudessa ne kriittisimmät palvelut toki ajetaan pilven sijasta ihan dedikoidulla oikealla raudalla johon muilla kuin oman talon väellä ei ole pääsyä, eikä missään "hotellissa" virtualisoituna.

 

[hkultala]

Takaportteja jotka paljastumisen jälkeen ovat haavoittuvuksia.
Enpä usko että linjalta koskaan tulee prosessoria jossa ei olisi jokin piilotettu takaportti.

Ei näillä ole mitään tekemistä minkään takaporttien kanssa.

 

[”diginatiivi”]

Ei näillä ole mitään tekemistä minkään takaporttien kanssa.

Haavoittuvuuden kautta luotu takaportti?

 

[Timo 2]

Haavoittuvuuden kautta luotu takaportti?

Takaportti on tahallinen ja suunniteltu. Haaavoittuvuus on lautaaidassa oleva tahaton rako, jota ei huomattu.

 

[”diginatiivi”]

Jospa muotoilen sen näin: Haavoittuvuus ennalta tiedossa ja suunniteltu.

 

[hkultala]

Jospa muotoilen sen näin: Haavoittuvuus ennalta tiedossa ja suunniteltu.

Ei todellakaan ole ennalta tiedossa.

 

[VmH]

Nyt sitten jos tämä korjataan, niin luvassa on performanssi heikennyksiä. Näin ainakin viimeksi kävi.

 

[Luckyo]

Pilvipalvelut ovat kuitenkin sen verran iso osa nykyistä web-infrastruktuuria että luulisi tällaisten asioiden kiinnostavan. Toki hyökkäystä voi olla vaikea kohdentaa tarkasti, mutta jos saat sinne pilveen pyörimään softaa joka lukee kulloinkin ajossa olevalta palvelinraudalta muiden käyttäjien salausavaimia ja muuta dataa niin joskus voi kohdalle sattua jättipotti. Tälläkin hetkellä ja varmasti tulevaisuudessa ne kriittisimmät palvelut toki ajetaan pilven sijasta ihan dedikoidulla oikealla raudalla johon muilla kuin oman talon väellä ei ole pääsyä, eikä missään "hotellissa" virtualisoituna.

Tämä kuulostaa ihan hyvältä iltalehti-tason "pelko, epävarmuus, epäilys" jutulta, mutta todellisuuden kanssa tällä ei ole juuri mitään tekemistä. Spektre-pohjaisia exploitteja ei ole paljoa näkynyt testikoneiden ulkopuolella vaikka ne ensimmäiset ja ylivoimaisesti pahimmat spektre-haavoittuvuudet korjattiin todella hitaasti. Eli oli paljon aikaa kehittää työkalut. Käytännössä melkein kaikki tiedossa olevat expoitit olivat meltdown-expoitteja, koska niitä pystyi oikeasti tekemään ilman että expoitti oli käytännössä konekohtainen ja erittäin vaikeasti toteutettavissa.

 

[mRkukov]

Käytännössä melkein kaikki tiedossa olevat expoitit olivat meltdown-expoitteja, koska niitä pystyi oikeasti tekemään ilman että expoitti oli käytännössä konekohtainen ja erittäin vaikeasti toteutettavissa.

Ja siksi sitä kutsuttiinkin "meltdown". Muilla rei'illä ei ollut paljoa väliä niin kauan kuin tuota ei oltu paikattu.

 

[pomk]

Takaportteja jotka paljastumisen jälkeen ovat haavoittuvuksia.
Enpä usko että linjalta koskaan tulee prosessoria jossa ei olisi jokin piilotettu takaportti.

Miksi kukaan suunnittelisi näin huonon takaportin?

Paljon fiksumpaa olisi tehdä takaportti, jossa kun tietty avain syötetään johonkin rekisteriin, kaikki prossun muistisuojaukset menisivät pois päältä. Olis paljon helpompi käyttää ja sais ihan kunnolla datoja ulos. Tämmöstä ei tietysti prossuissa oikeasti ole, sillä tuon paljastuessa AMD vietäis oikeuteen hyvin nopeasti pilvipalvelinfirmojen toimesta.

 

[Cirrus]

Miksi kukaan suunnittelisi näin huonon takaportin?

Paljon fiksumpaa olisi tehdä takaportti, jossa kun tietty avain syötetään johonkin rekisteriin, kaikki prossun muistisuojaukset menisivät pois päältä. Olis paljon helpompi käyttää ja sais ihan kunnolla datoja ulos. Tämmöstä ei tietysti prossuissa oikeasti ole, sillä tuon paljastuessa AMD vietäis oikeuteen hyvin nopeasti pilvipalvelinfirmojen toimesta.

Periaatteessa itse vastasit samalla kysymykseenkin. Takaportti olisi myös helvetin huono jos siitä jää helposti kiinni ja sen todistaminen tahalliseksi on helppoa.

 

[pomk]

Periaatteessa itse vastasit samalla kysymykseenkin. Takaportti olisi myös helvetin huono jos siitä jää helposti kiinni ja sen todistaminen tahalliseksi on helppoa.

Ja vielä huonompi, jos sen voi paikata käyttöjärjestelmätasolla.

On kyllä kunnon paksut foliot silmille asti vedettynä, jos kuvittelee että spectre haavoittuvuudet on ”takaportteja”.

 

[joghe]

Cirrus sanoikin vähän kuten minäkin sen ole ajatellut.
On aivan sama millainen metodi takaportti on jos se toimii, mikäli se paljastuttuaan ei siltä näytä niin vielä parempi.
Enkä usko että oli viimoinen reikä joka paljastuu, uskoisin että näitä metodeja on useita jotka kaikki eivät edes tule paljastumaan.
Tämä toki puhdasta pähkäilyä, melkeinpä mutuiluksi voisi sanoa, ellei meillä olisi näitä uutisia.

Valmistaja saattaa lähteä tähän mukaan yksinkertaisesti siksi ettei ole vaihtoehtoa, pakotettuna.
Lisäksi reikien paljastumienen motivoi hankkimaan uutta "turvallisempaa".
Varsinkin jos kehitys tallaa paikoillaan, saadaan kätevästi hidastumaan reikien paikkailulla vanha muuten kelpo lastu.

 

[Ihmemies]

Käytännössä siis pitää vaan kaikki nopeusbuustit käytössä perus civiilien tietokoneissa. Jossain VM-servuhommissa voi sitten miettiä disablointia tarpeen mukaan. Tämä taisi olla AMD:n suosituskin asiaan.

 

[hkultala]

Cirrus sanoikin vähän kuten minäkin sen ole ajatellut.
On aivan sama millainen metodi takaportti on jos se toimii, mikäli se paljastuttuaan ei siltä näytä niin vielä parempi.
Enkä usko että oli viimoinen reikä joka paljastuu, uskoisin että näitä metodeja on useita jotka kaikki eivät edes tule paljastumaan.
Tämä toki puhdasta pähkäilyä, melkeinpä mutuiluksi voisi sanoa, ellei meillä olisi näitä uutisia.

Valmistaja saattaa lähteä tähän mukaan yksinkertaisesti siksi ettei ole vaihtoehtoa, pakotettuna.
Lisäksi reikien paljastumienen motivoi hankkimaan uutta "turvallisempaa".
Varsinkin jos kehitys tallaa paikoillaan, saadaan kätevästi hidastumaan reikien paikkailulla vanha muuten kelpo lastu.

Voisitteko nyt yrittää edes YHTÄÄN ymmärtää mistä tällaiset sivukanavat johtuu.

Ne johtuu ihan siitä, että keksitään uusia keinoja nopeuttaa prosessorin toimintaa tekemällä asioita spekulatiivisesti etukäteen, ennen kuin ollaan varmoja, että se homma pitää oikeasti tehdä. Ja sitten niistä spekulatiivisesti suoritetuista asioista jää jäänteitä välimuisteihin yms. (esim. siten, että välimuisteista heitetään muuta dataa näiden alta pois, ja tarkastelemalla tiettyjen asioiden nopeuksia voidaan päätellä, tuliko data välimuistista vai ei (että oliko joku, esim. spekulatiivisesti suoritettu koodi johtanut sen poisheittämiseen sieltä)). Ja vasta pari vuotta sitten alettiin kunnolla tutkia, että mitä kaikkea ilkeää todella näistä jämistä voidaan todella ovelilla algoritmeilla päätellä.

Jos kaikki asiat tehtäisiin vasta kun ollaan varmoja, että ne oikeasti myös pitää tehdä, haaskataan hirveästi aikaa päätösten odotteluun.

Mutta kun asiat tehdään spekulatiivisesti, niin tilanteessa jossa se piti tehdä, prossu nopeuttuu huomattavasti, ja tilanteessa, jossa sitä ei pitänyt tehdä, heitetään vaan spekulatiivisesti tehdyt asiat mäkeen, ja kärsitään joskus harvoin pieni hidastus tästä.

Onko kyllä todella typerää foliohattuilua ruveta väittämään että näitä tehdään sen takia että sinne halutaan tunkea jotain tarkoituksellisia takaportteja.

Kyllä ne suorituskykyoptimoinnit tehdään ihan paremman suorituskyvyn takia.

 

[pomk]

On aivan sama millainen metodi takaportti on jos se toimii, mikäli se paljastuttuaan ei siltä näytä niin vielä parempi.

Sitten näille varmaan on mahdollista koodata joku käyttökelpoinen exploitti. Ainakaan aiemmille spectre varianteille ei olla saatu oikein mitään käyttöä, sillä haavoittuvuus on aivan typerän vaikea hyödyntää. Jos koko tietoturvatutkimuksen maailmanlaajuinen poppoo ei saa aikaiseksi kuin paskan demon, niin on vaikea kuvitella että tuolla tekisi juuri mitään. Jos tarkoitus on ollut rakentaa takaportti, niin tämä on ainakin ihan älyttömän huono sellainen.

Lisäksi schedulerin parissa työskentelee melko paljon ihmisiä, ja jotta moinen tietoturvan puolesta uskottavan epämääräisesti huono exploitti sinne saataisiin, tulee porukan tehdä huomattavasti enemmän duunia ja exploitin olemassaolosta tulee tietämään aika moni prossun parissa työskennelleistä. En pidä uskottavana, että moinen ”salaisuus” jäisi pimentoon ihan kauhean pitkäksi aikaa.

 

[bladE_666]

On olemassa hyödyllisiä ja haitallisia uskomuksia. Valtaosa niistä ohjaa meidän jokaisen toimintaa elämässä ja ihan huomaamatta. Osa elää pahantahtoisessa maailmassa ja minä uskon siihen, että esim. herra Hkultala omaa sen verran kompentenssia asian tiimoilta, ettei käy epäselväksi, että nouseeko aurinko huomenna vai eikö. Kyllä, otan samalla myös riskin, että olen väärässä kaikesta huolimatta, sillä tuntemani käsityksen mukaan varmaa on vain epävarmuus ja kuolema mahdollisine monttubileineen.

 

[jive]

On mielenkiintoista nähdä miten tämä heijastelee esimerkiksi ajoneuvoteollisuuden puolelle. Olen ihmetellyt miten spekulatiiviseen suoritukseen perustuvia moniydinsuorittimia edes on saatu ASIL luokiteltua. Sinällään tämäkään löydös ei ilmeisesti mahdollista suorituspolun tai parametrien muuttamista vain muistin sisällön vuotamisen. Toistaiseksi toiminnallisen turvallisuuden puolella ei ole hirveästi painotettu tietoturvaa mutta mahtaako jossain vaiheessa sekin muuttua?

 

[joghe]

Voisitteko nyt yrittää edes YHTÄÄN ymmärtää mistä tällaiset sivukanavat johtuu.

Ne johtuu ihan siitä...

Kyllä ne suorituskykyoptimoinnit tehdään ihan paremman suorituskyvyn takia.

Näin varmaan on, enkä muuta edes yritä selittää.
Esitän että ne ovat siellä tarkoituksellisesti joko kehitysvaiheessa havaittuja aukkoja jätetty tai jopa tarkoituksellisesti kehitetty aukko joka ei todellakaan näytä takaportilta.
Nyt havaittu reikä on siellä siksi että se sinne kätevästi voitiin sijoittaa.

Folio kortti käytetty, seuraavaksi salaliitto kortti? Raisti ja natsi ei taida helposti soveltua tähän.

Lisäksi schedulerin parissa työskentelee melko paljon ihmisiä, ja jotta moinen tietoturvan puolesta uskottavan epämääräisesti huono exploitti sinne saataisiin, tulee porukan tehdä huomattavasti enemmän duunia ja exploitin olemassaolosta tulee tietämään aika moni prossun parissa työskennelleistä. En pidä uskottavana, että moinen ”salaisuus” jäisi pimentoon ihan kauhean pitkäksi aikaa.

Näillä kavereilla jotka kehittävät on varmasti aika pätevät salassapitosopparit tulilla, mitens hkultala siellä noksulla?

 

[Luckyo]

Ja siksi sitä kutsuttiinkin "meltdown". Muilla rei'illä ei ollut paljoa väliä niin kauan kuin tuota ei oltu paikattu.

 

[Luckyo]

Eikä sen jälkeenkään. Se oli koko pointti. Ainoa muussa kuin palvelinkäytössä edes jotenkin toimiva haavoittuvuus joilla näitä oli alun perin mediassa mainostettu oli meltdown. Spectre on täysin irrelevantti ympäristössä jossa ei ajeta useita virtuaalikoneita samalla fyysisellä raudalla, jossa uhkakuvana on kyky lukea jotain tietoa toisesta VM:stä.

Tämä on kaikki mitä spectrellä voi tehdä. Ja tämän tekemiseksi exploitti täytyy ohjelmoida jokaiselle yksittäiselle koneelle, ottaen huomioon sen uniikit erityisominaisuudet. Eli käytännössä hirvittävän kallis ja äärimmäisen vaikea toteuttaa, eikä sillä saa kuin pieniä paloja dataa välimuistista sen jälkeen kun olet jo ottanut k.o. koneella olevan VM:n käyttöön.

 

[Luckyo]

On mielenkiintoista nähdä miten tämä heijastelee esimerkiksi ajoneuvoteollisuuden puolelle. Olen ihmetellyt miten spekulatiiviseen suoritukseen perustuvia moniydinsuorittimia edes on saatu ASIL luokiteltua. Sinällään tämäkään löydös ei ilmeisesti mahdollista suorituspolun tai parametrien muuttamista vain muistin sisällön vuotamisen. Toistaiseksi toiminnallisen turvallisuuden puolella ei ole hirveästi painotettu tietoturvaa mutta mahtaako jossain vaiheessa sekin muuttua?

Kukaan autoa oikeasti ajamiseen käyttävä ei taida ajaa ajoneuvonsa tietokoneilla palvelinta jossa samalla fyysisellä koneella on useita virtuaalikoneita tilanteessa jossa yhdestä virtuaalikoneesta on luettava toisen virtuaalikoneen dataa luvattomasti.

Tietoturva tämän päivän ajoneuvoissa on lähinnä "kuka pääsee tunkemaan dataportiin skannerin" ja "DRM-suojaus dataportista käyttäjältä itseltään jotta tämä ei pääse diagnostiikkadataan käsiksi ja pysty korjaamaan vikoja ilman käyntiä merkkikohtaisella valtuutetulla korjaamolla".

 

[jive]

Kukaan autoa oikeasti ajamiseen käyttävä ei taida ajaa ajoneuvonsa tietokoneilla palvelinta jossa samalla fyysisellä koneella on useita virtuaalikoneita tilanteessa jossa yhdestä virtuaalikoneesta on luettava toisen virtuaalikoneen dataa luvattomasti.

Tietoturva tämän päivän ajoneuvoissa on lähinnä "kuka pääsee tunkemaan dataportiin skannerin" ja "DRM-suojaus dataportista käyttäjältä itseltään jotta tämä ei pääse diagnostiikkadataan käsiksi ja pysty korjaamaan vikoja ilman käyntiä merkkikohtaisella valtuutetulla korjaamolla".

Unohdat kätevästi että lähes kaikki uudet ajoneuvot ovat verkossa 24/7 ja osa palveluista on pilvessä johon on vain paikallinen käli.

 

[pomk]

Unohdat kätevästi että lähes kaikki uudet ajoneuvot ovat verkossa 24/7 ja osa palveluista on pilvessä johon on vain paikallinen käli.

Varsiainen ajojärjestelmä pitää kyllä edelleen olla irrallinen. Jossain jenkkiautossa ne jakoivat keskenään jonkun sarjaväylän ja sitä kautta tuli ongelmia, mutta isoin juttu mitä oikein valmistetussa autossa voi tapahtua on että stereoista saa vaihdettua biisin ja navin uudelleenohjattua muualle. Jarrut, kaasu ja ohjaustehostin ei ole kytkettynä internettiin.

 

[pomk]

Esitän että ne ovat siellä tarkoituksellisesti joko kehitysvaiheessa havaittuja aukkoja jätetty tai jopa tarkoituksellisesti kehitetty aukko joka ei todellakaan näytä takaportilta.
Nyt havaittu reikä on siellä siksi että se sinne kätevästi voitiin sijoittaa.

Eli on tehty hirveät määrät töitä, jotta tuote olisi potentiaalisesti huonompi kuin kilpailijoilla, ja samalla otetaan valtava riski siitä että joku puhuu ja firma viedään oikein urakalla kölin ali oikeudessa?

 

[jive]

Varsiainen ajojärjestelmä pitää kyllä edelleen olla irrallinen. Jossain jenkkiautossa ne jakoivat keskenään jonkun sarjaväylän ja sitä kautta tuli ongelmia, mutta isoin juttu mitä oikein valmistetussa autossa voi tapahtua on että stereoista saa vaihdettua biisin ja navin uudelleenohjattua muualle. Jarrut, kaasu ja ohjaustehostin ei ole kytkettynä internettiin.

Kustannussyistä fyysistä väylää jaetaan IVI ja X-by-wire järjestelmien välillä ja erotus on ohjelmistolla. Pitäisi varmaan katsoa mitä AUTOSAR nykyään on mieltä. Käsittääkseni esimerkiksi Teslassa kaikki kama on yhdellä piirikortilla. Tarkempaa tietoa siitä miten järjestelmä on raudalla ja ohjelmistolla osioitu ei ole.

Connected EV System Solutions NXPLive Demo

Cloud to vehicle connectivity enables energy management optimization in electric vehicles.

www.nxp.com

 

[pomk]

Kustannussyistä fyysistä väylää jaetaan IVI ja X-by-wire järjestelmien välillä ja erotus on ohjelmistolla.

Kerro ihmeessä lisää, ilmeisesti hommat muuttuneet paljon siitä kun noiden parissa on viimeksi tullut vietettyä aikaa.

Käsittääkseni esimerkiksi Teslassa kaikki kama on yhdellä piirikortilla. Tarkempaa tietoa siitä miten järjestelmä on raudalla ja ohjelmistolla osioitu ei ole.

No sillä ei ole onneksi käytännössä mitään merkitystä että monellako piirikortilla kamat on. Käytännössä noita on todella vaikea tehdä osoitettavasti turvallisiksi ylipäänsä jos turvatoiminnot on mitenkään riippuvaisia viihdejärjestelmän toiminnasta. Sopivasti bitti vinoon biisiä vaihtaessa, väylä täyteen oksennusta ja koko auton kaikki turvavehkeet lakkaa toimimasta. Ei kuulosta kovin hyvältä.

 

[Kizmo]

Voisitteko nyt yrittää edes YHTÄÄN ymmärtää mistä tällaiset sivukanavat johtuu.

Ne johtuu ihan siitä, että keksitään uusia keinoja nopeuttaa prosessorin toimintaa tekemällä asioita spekulatiivisesti etukäteen, ennen kuin ollaan varmoja, että se homma pitää oikeasti tehdä. Ja sitten niistä spekulatiivisesti suoritetuista asioista jää jäänteitä välimuisteihin yms. (esim. siten, että välimuisteista heitetään muuta dataa näiden alta pois, ja tarkastelemalla tiettyjen asioiden nopeuksia voidaan päätellä, tuliko data välimuistista vai ei (että oliko joku, esim. spekulatiivisesti suoritettu koodi johtanut sen poisheittämiseen sieltä)). Ja vasta pari vuotta sitten alettiin kunnolla tutkia, että mitä kaikkea ilkeää todella näistä jämistä voidaan todella ovelilla algoritmeilla päätellä.

Jos kaikki asiat tehtäisiin vasta kun ollaan varmoja, että ne oikeasti myös pitää tehdä, haaskataan hirveästi aikaa päätösten odotteluun.

Mutta kun asiat tehdään spekulatiivisesti, niin tilanteessa jossa se piti tehdä, prossu nopeuttuu huomattavasti, ja tilanteessa, jossa sitä ei pitänyt tehdä, heitetään vaan spekulatiivisesti tehdyt asiat mäkeen, ja kärsitään joskus harvoin pieni hidastus tästä.

Onko kyllä todella typerää foliohattuilua ruveta väittämään että näitä tehdään sen takia että sinne halutaan tunkea jotain tarkoituksellisia takaportteja.

Kyllä ne suorituskykyoptimoinnit tehdään ihan paremman suorituskyvyn takia.

Minusta ainakin on naiivia ajatella etteikö NSA:n tasoiset tahot ole näistä tienneet jo kauankin aikaa. Ei se toki aukoista tarkoituksella suunniteltuja tee. Mutta tarkoituksella voi olla myös hiljaa.

 

[pomk]

Minusta ainakin on naiivia ajatella etteikö NSA:n tasoiset tahot ole näistä tienneet jo kauankin aikaa. Ei se toki aukoista tarkoituksella suunniteltuja tee.

Juu tuo on ihan mahdollista, mutta kai se sinustakin on ihan eri asia jos tuotteisiin tehdään haitallisia takaportteja vs. joku kolmas osapuoli löytää haavoittuvuuden ja ei kerro siitä kenellekkään?

Mutta tarkoituksella voi olla myös hiljaa.

NSA on hiljaa tosi monesta asiasta. Vai meinaatko nyt että AMD:ta on informoitu (kenen toimesta?) haavoittuvuudesta, ja sit on hiljaa asiasta?

 

[jive]

Kerro ihmeessä lisää, ilmeisesti hommat muuttuneet paljon siitä kun noiden parissa on viimeksi tullut vietettyä aikaa.

Katsoitko NXP demon? V2X kirjaimellisesti kytkee kaasupolkimen verkkoon, jopa siihen pilveen.

 

[Luckyo]

Kustannussyistä fyysistä väylää jaetaan IVI ja X-by-wire järjestelmien välillä ja erotus on ohjelmistolla. Pitäisi varmaan katsoa mitä AUTOSAR nykyään on mieltä. Käsittääkseni esimerkiksi Teslassa kaikki kama on yhdellä piirikortilla. Tarkempaa tietoa siitä miten järjestelmä on raudalla ja ohjelmistolla osioitu ei ole.

Connected EV System Solutions NXPLive Demo

Cloud to vehicle connectivity enables energy management optimization in electric vehicles.

www.nxp.com

Edelleen, ei liity spectreen mitenkään. Spektre ei salli toisen VM:n sisällön tarkkaa muokkaamista. Se vain päästää lukemaan toisesta VM:stä toisen VM:n prossun välimuistin jämiä.

Suosittelen vahvasti ymmärtämään mitä spectre on haavoittuvuutena, ja miten se toimii ennen kuin jatkaa tätä keskustelua, koska nyt on selvästi kykyä ymmärtää teknistä nippelitietoa. Eli ei pitäisi olla vaikeaa hakea muutama video siitä mitä spectre on haavoittuvuutena, miten se toimii, mitä sillä on tehtävissä, ja miksi tämäkin on niin vaikeasti toteuttettavissa että sitä ei käytetty käytännössä ollenkaan.

 

[KoneenKokoaja]

Joo siis tämä uusi aukko perustuu siihen, että hyökkääjällä on tilastollinen taulukko siitä kuinka kauan minkäkin microkoodi operaation suorittaminen kestää ja mittaamalla suoritusaikoja ja muita prosessorin tietoja kuten sähkönkulutusta voidaan taulukon perusteella laskea salaisten microkoodi cachejen sisältöjä (ilman, että sinne päästään suoraan käsiksi). Teknisesti Virginian yliopisto on oikeassa, että hyökkäykseltä ei voi suojautua mitenkään, koska hyökkääjä voi hankkia saman prosessorin ja luoda sen avulla kattavat tilastollisettaulukot suoritusaijoista ja muista tiedoista minkä avalla laskea cachen sisältöjä koneissa missä on sama prosessori. Käytännössä kuitenkin tämä hyökkäys voidaan torjua ohjelmoimalla salaisia juttuja käsittelevät ohjelmat siten, että niiden suoritus kestää aina saman aikaa, jolloin niiden sisältöä ei voi selvittää tällä tavalla. Intel on ainakin julkaissut ohjeet siitä miten salaisia tietoja käsittelevät osat pitää koodata, jolloin tätä aukkoa ei voi hyödyntää.

Tutkin siis tätä miten tämä aukko toimii ja tämä siis oli käsitykseni minkä sain miten tää toimii. Sain myös käsityksen, että AMD prossuilla tämä ongelma olisi pahempi kuin Intelillä, koska cachen rakenne on erilainen. Tosin AMD ei ole vielä virallisesti kommentoinut asiaa. En lähde kuitenkaan edes yrittämään selittää miksi asia on näin en ole niin suuri asiantuntija mikroarkkitehtuureissa. Tässäkin karvalakki selityksessä voi olla aukkoja, mutta uskoisin periaatteellisella tasolla tämän selitykseni olevan oikea.

 

[user9999]

Päivitys tuossa Virginian Yliopiston jutussa.
This story has been updated to reflect a statement from Intel on May 3, 2021.

https://engineering.virginia.edu/news/2021/04/defenseless-uva-engineering-computer-scientists-discover-vulnerability-affecting

In response to a significant amount of global media coverage about the newly discovered vulnerability, Intel released a statement May 3 suggesting that no additional mitigation would be required if software developers write code using a method called “constant-time programming,” not vulnerable to side-channel attacks.

“Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks,” Venkat said. “However, the vulnerability we uncovered is in hardware, and it is important to also design processors that are secure and resilient against these attacks.

“In addition, constant-time programming is not only hard in terms of the actual programmer effort, but also entails high performance overhead and significant deployment challenges related to patching all sensitive software,” he said. “The percentage of code that is written using constant-time principles is in fact quite small. Relying on this would be dangerous. That is why we still need to secure the hardware.”

Intel viittaa varmaan seuraavaan artikkeliin

Intel Developer Zone

Find software and development products, explore tools and technologies, connect with other developers and more. Sign up to manage your products.

software.intel.com

 

[jive]

Mielenkiintoinen lausunto. Vakioaikainen algoritmi ohjelmistokielitasolla on toteutettavissa, mutta puhutaanko tässä nyt siitä että pitäisi kaikki kirjoittaa konekielellä?

 

[hkultala]

Mielenkiintoinen lausunto. Vakioaikainen algoritmi ohjelmistokielitasolla on toteutettavissa, mutta puhutaanko tässä nyt siitä että pitäisi kaikki kirjoittaa konekielellä?

Ei kaikki, vaan se koodi joka käsittelee esim. kryptoavaimia. Niiden kryptoalgoritmien varsinaisen työn tekevät osuudet eivät ole kovin isoja.

Jos kääntäjät yrittäisivät olla vähän vähemmän näsäviisaita, onnistuisi myös korkeamman tason ohjelmointikielillä, mutta valitettavasti kääntäjät optimoinneillaan pilaavat tämän. Ja yleensä edes kääntäjien "optimoi vähemmän"-flafit ei oikein toimi tähän, koska ne tyypillisesti säätää ihan vääriä asioita.