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

  • Keskustelun aloittaja Keskustelun aloittaja Kaotik
  • Aloitettu Aloitettu
Googlen tekninen selitys:

Project Zero: Reading privileged memory with a side-channel

Ensimmäinen noista kolmesta toimii myös Bulldozer-johdannaisiin, eli kaikki AMDn prossut ei ole immuuneja.

Tämän tiedon nojalla se AMDn kernel-patchi on aika tyhmä. Näin nopeasti sitä lopetetaan vanhojen prossujen tukeminen. Excavator-prossuja on kuitenkin paljon myynnissäkin vielä, Raven Ridge on vasta tulossa.

Olin siis väärässä aiemmassa kommentissani jossa arvelin että AMD ei ole haavoittuvainen koska ei optimoi yhtä aggressiivisesti kuin Intel.


Noiden hyödyntämisen käytännöllisyydestä:
Yhdellä noista haavoittuvuuksista saavutettiin 1.5kB/s kaistanleveys siihen luvattomaan muistinlukemiseen. Menee kuukausia, että saa kaiken muistin luettua.
 
Viimeksi muokattu:
Vergen mukaan näyttää Microsoft alkaneen jaella hätäpäivitystä Windows 10:neen, itsellä ei kyllä vielä Windows Updatesta näy. 7 ja 8.1 tulee saamaan päivityksen Patch Tuesdayna.
 
Kakkosexploitti perustuu haarautumisenennustukseen.

Esimerkkikoodi oli toteutettu tähtäämään Haswellin haarautumisenennustimeen, mutta AMDn virallinen selitys miksi AMD ei muka ole haavoittuvainen ei oikein päde tuota vastaan, koska tuo ei perustu spekulatiivisiin lukuihin laittomista osoittesta, vaan laillisiin haarautumisiin osoitteissa, jotka haarautumisenennustimessa aliasoi halutun osoitteen kanssa.

Eli AMD olisi ehkä tuollekin todennäköisesti haavoittuvainen, JOS koodista tekisi version joka tähtää nimenomaan jotain AMDn prossua vastaan. En kuitenkaan tunne AMDn haarautumisenennustuksen yksityiskohtia että pystyisin tätä varmaksi sanomaan.
 
hkultala sanoi:
Tämän tiedon nojalla se AMDn kernel-patchi on aika tyhmä. Näin nopeasti sitä lopetetaan vanhojen prossujen tukeminen. Excavator-prossuja on kuitenkin paljon myynnissäkin vielä, Raven Ridge on vasta tulossa.
Napsauta laajentaaksesi...

Ymmärsinkö väärin, että vain tuo Variant 3 olisi se mitä sillä PTI-patchilla korjataan ja sen takia kaikki AMDn prossut voidaan jättää pois luvuista?
 
Sampsa sanoi:
Asmola sanoi:
Mielenkiinnolla odotan millaiset vaikutukset käytännön suorituskyvyssä yleisimmissä tehtävissä. Kai @Sampsa ajaa ainakin suppeat testit ennen ja jälkeen päivityksen?:think:
Napsauta laajentaaksesi...

Kaiser Soze sanoi:
Kiitoksia, tämähän selvensi. Erittäin vittumaiselta kuullostaa mut onneksi kotikäyttäjää vähemmän haittaa.

Ois kyl ihan ehdoton artikkeli tämä :)
Napsauta laajentaaksesi...

Eiköhän me tätä aktiivisesti tulla seuraamaan, uutisoimaan ja testaamaan :tup:
Napsauta laajentaaksesi...
Testatkaa Lightroomilla. Jollain isolla tietokannalla. Please.
 
Graag sanoi:
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.
Napsauta laajentaaksesi...
Ainakin ASUS ja Asrock ovat jo julkaisseet BIOS- päivityksistä erillisen päivitysohjelman ME- firmwarelle.
 
hkultala sanoi:
Ja tällaiseen todella ovelaan side channel-hyökkäykseen ei todellakaan osata varautua etukäteen.
Napsauta laajentaaksesi...

Itse en olisi näin sinisilmäinen. Minusta tämä vaikuttaa päätökseltä hakea suorituskykyä tietoturvan kustannuksella, pre-fetch kun taisi olla ennen muistialueen sekoittamista. Lisätään tähän päälle uusia löydöksiä, joilla saadaan suorituskykyä pre-fetch -tekniikasta, kun suoritetaan useampia säikeitä, ja jätetään edelleen se tietoturva vähemmälle, niin en yhtään ihmettele, että tähän on päädytty. Kysymys kuuluukin, kuinka Intelin suunnittelijoilla ei käynyt mielessä tälläiset sivuvaikutukset, vai jätettiinkö ne vähemmälle huomiolle bisnespäätösten painaessa vaakakupissa enemmän.
 
Nopea tiivistelmä tähän ennen uutista:

On havaittu kaksi kriittistä haavoittuvuutta prosessoreissa, joita voi kutsua bugiksi.

1. Meltdown
2. Spectre

Meltdown koskee vain Intelin prosessoreita ja tähän on Linuxissa korjauksena se Kernel Page Table Isolation -ominaisuus.

Spectre koskee käytännössä kaikkia laitteita älypuhelimista pilvipalvelimiin ja kaikkia valmistajia. Hyökkäys on vaikeampi toteutta, mutta paikkaaminen melkein mahdotonta.

Hyökkäysvariantteja on 3 kpl:

So far, there are three known variants of the issue:
  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)
Variantit 1 ja 2 liittyy Spectreen ja variantti 3 on Meltdown.

Meltdown and Spectre
 
Sampsa sanoi:
Nopea tiivistelmä tähän ennen uutista:

On havaittu kaksi kriittistä haavoittuvuutta prosessoreissa, joita voi kutsua bugiksi.

1. Meltdown
2. Spectre

Meltdown koskee vain Intelin prosessoreita ja tähän on Linuxissa korjauksena se Kernel Page Table Isolation -ominaisuus.

Spectre koskee käytännössä kaikkia laitteita älypuhelimista pilvipalvelimiin ja kaikkia valmistajia. Hyökkäys on vaikeampi toteutta, mutta paikkaaminen melkein mahdotonta.

Hyökkäysvariantteja on 3 kpl:

So far, there are three known variants of the issue:
  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)
Variantit 1 ja 2 liittyy Spectreen ja variantti 3 on Meltdown.

Meltdown and Spectre
Napsauta laajentaaksesi...
Syntyipä yhdestä löydöstä iso soppa. Saas nähdä mitä tuon spectren korjaamiseksi tehdään valmistajien puolelta.
 
Sampsa sanoi:
Nopea tiivistelmä tähän ennen uutista:
Napsauta laajentaaksesi...

Voisiko noista saada jonkinlaisen yhteenvedon teknisesti rajoittuneemmille, jossa olisi ns. rautalangasta väännetty mistä ja miksi on kyse. Nyt keskustelussa on aikalailla teknistä termistöä jota asiaa seuraamaton ei ymmärrä mistä on kyse.
 
  • Tykkää
Reactions: VVG
Linus-setä on hyvin vihainen :eek::rofl:
LKML: Linus Torvalds: Re: Avoid speculative indirect calls in kernel
Koodi: 
From    Linus Torvalds <>
Date    Wed, 3 Jan 2018 15:51:35 -0800
Subject    Re: Avoid speculative indirect calls in kernel
   

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

                   Linus
 
tonkar sanoi:
Linus-setä on hyvin vihainen :eek::rofl:
LKML: Linus Torvalds: Re: Avoid speculative indirect calls in kernel
Koodi: 
From    Linus Torvalds <>
Date    Wed, 3 Jan 2018 15:51:35 -0800
Subject    Re: Avoid speculative indirect calls in kernel
  

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

                   Linus
Napsauta laajentaaksesi...
Mihin AMD unohtui Linusilta? ARM on samaan tapaan haavoittuva Spectrelle kuin AMD eli sen suhteen se ja sama
 
Voi olla että tästä käynnistyy melkoinen kisa että kuka tuo ensin markkinoille prosessorin jossa spectre on paikattu.
Ei kyllä ihan hetkeen tarvi sellaista odotella markkinoille.
 
Voi helvetti, pitääkö tässä alkaa patchaamaan kohta kaikki tietokone, puhelin, Raspberry, reititin jne.
 
JiiPee sanoi:
Voi olla että tästä käynnistyy melkoinen kisa että kuka tuo ensin markkinoille prosessorin jossa spectre on paikattu.
Ei kyllä ihan hetkeen tarvi sellaista odotella markkinoille.
Napsauta laajentaaksesi...
Enpä usko. Kernelipäivitykset korjaavat tietoturvaongelmat nopeuden kustannuksella, ja eniten hittiä ottavat ohjelmat joko optimoivat mahdollisuuksien rajoissa tai eivät. Työpöytäkäyttäjille tämä ei tule vaikuttamaan juuri mitenkään, mutta servupuolella tilanne voi olla käyttötarkotuksesta riippuen hyvinkin erilainen. Olen kyllä näissä asioissa täysi maallikko, mutta käsittääkseni PCID:tä tukevilla prossuilla hidastukset voidaan ainakin teoriassa korjata softapuolella ilman mainittavaa hidastusta suorituskyvyssä. EPYCit mennee silti jatkossa kuin kuumille kiville.
 
Sampsa sanoi:
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
Napsauta laajentaaksesi...

Mitenkäs vaikka joku pfSense, joka rakentuu bsd:n ympärille. Kuinka asia siinä bsd:ssä korjataan?
 
Juuh, tän haavoittuvuuden yksityiskohdat oli tarkoitus tuoda julki vasta myöhemmin. Tuo linkkaamani vastaus on about tuntia julkistamista vanhempi.
 
looz sanoi:
Juuh, tän haavoittuvuuden yksityiskohdat oli tarkoitus tuoda julki vasta myöhemmin. Tuo linkkaamani vastaus on about tuntia julkistamista vanhempi.
Napsauta laajentaaksesi...

Ei minua oikeastaan kiinnostanut kuin tietää, että onko tällä samat vaikutukset kuin Linuxissa eri cpu-valmistajille, mutta jäämme kai sitten odottelemaan
 
looz sanoi:
Enpä usko. Kernelipäivitykset korjaavat tietoturvaongelmat nopeuden kustannuksella
Napsauta laajentaaksesi...
Ongelma tuon Spectren kanssa on vain se, että sitä ei kernel päivityksellä korjata. Se on kaikkien nykyprosessorien arkkitehtuuriin sisältyvä "ominaisuus", oli valmistaja kuka tahansa. Meltdownia, joka koskee Inteliä ja joitain ARM-ytimiä, korjataan kernel-päivityksellä. Spectren korjaaminen vaatii arkkitehtuurin uudelleensuunnittelua. Sen "hyvä" puoli on, että onneksi se on varsin vaikeasti hyödynnettävissä Meltdowniin.

Sami Riitaoja tuolla aiemmin mainitsi saman asian, mitä pohdiskelin eilen nukkumaan mennessä itsekseni. Tuo Meltdown rautabugihan ei mihinkään poistu millään kernel-päivityksellä ja haavoittuvuus sinällään siis säilyy edelleen. Päivityksen jälkeen on vain luotettava siihen softaan, eli käyttikseen, että homma todellakin toimii 100%:n turvallisesti. Jos ylläpitäisin jotain pirun kriittistä järjestelmää, en olisi edelleenkään täysin rauhallisin mielin tietäen, että se Meltdown on edelleen olemassa.
 
Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linu… · torvalds/linux@00a5ae2 · GitHub
1zanzeV.jpg

Linusin tekemä patchi Linuxin Kerneliin ei näytä vaikuttavan AMD lopulta.
 
Onkohan tuo varmasti KB4054022 kun minulle tuo on tullut jo marraskuun lopulla?
 
Täytyy sanoa, että sain aamunaurut tästä. Harmi kun en ostanut Inteliä kuin gäppäsi alas. Noh, täytyy katsoa joukkokanneriskit vielä ensin.

Az9i3h9.png
 
Sampsa sanoi:


Cannon Lakessa korjattu?
Napsauta laajentaaksesi...


Veikkaan, että tämän vuoden tuotteisiin (jos ehtivä) korjaus on kyllä tasoa purukumi.

Kyllä prosessorin suunnittelu ja validointi alusta loppuun vie sen verran aikaa, että varmaankin nyt vain korjaavat tämän niin minimimuutoksella kuin mahdollista, että tuotejulkistukset eivät myöhästy.

Tuloksenteko ja Osakekurssi on se pyhistä pyhin. Muut ongelmat hoitaa valehtel.... Ei kun PR-osasto. Näin se menee pörssiyhtiöissä.

Hauskaa nähdä Intelin kiemurtelevan. Lakiosastollakin väännetään varmaan 24t päiviä
 
halcyon sanoi:
Hauskaa nähdä Intelin kiemurtelevan. Lakiosastollakin väännetään varmaan 24t päiviä
Napsauta laajentaaksesi...
Ja lakiosaston budjetti taisi myös kadota. "tehkää mitä vain, jotta..." :D

Ja samaan aikaan muualta firmasta tulee näitä "koskee kaikkia, myös AMDtä" lausuntoja. Voihan noistakin vetää herneen nenään kun tahallaan puhutaan pahaa kilpailijasta. :)
 
mRkukov sanoi:
Ja samaan aikaan muualta firmasta tulee näitä "koskee kaikkia, myös AMDtä" lausuntoja. Voihan noistakin vetää herneen nenään kun tahallaan puhutaan pahaa kilpailijasta. :)
Napsauta laajentaaksesi...
No onneksi intellin pr ymmärtää tämän paremmin kuin täällä.
2/3 mitre tunnisteen saaneesta haavoittuvuudesta koskee myös amd:tä, joten... Totuuden saa aina kertoa.
 
Cirrus sanoi:
No onneksi intellin pr ymmärtää tämän paremmin kuin täällä.
2/3 mitre tunnisteen saaneesta haavoittuvuudesta koskee myös amd:tä, joten... Totuuden saa aina kertoa.
Napsauta laajentaaksesi...
Kyllä, mutta tuo Inteliä ja joitain ARM:ja koskeva Meltdown on kyllä kriittisin, koska exploitti on helppo toteuttaa. Spectre taas hankala toteuttaa sekä korjata.

Kyllä Intel veti ihan puhdasta corporate tuubaa tuossa tiedotteessa ja yritti a) vähätellä Meltdownin vaikutusta "average user" maininnalla b) korostaa nimenomaan Spectreä Meltdownin sijaan.

Intel on ongelmissa, jos ja kun nuo Meltdown päivitykset aiheuttavat palvelinpuolella kovan suorituskykyvaikutuksen ja he tietävät sen itsekin. Eilinen tiedote laukaistiin selvästi lyhytaikaiseksi markkinoiden rauhoitukseksi ja se näytti toimivan. Veikkaisin, että firmassa pistettiin viimeistään eilen kriisiryhmä pystyyn, jossa on lakiosastoa, PR-ihmisiä ja insinöörejä ja nyt mietitään kuumeisesti skenaarioita, miten jatko meinataan hoitaa firman kannalta parhaimmalla tavalla.
 
SpecuCheck:
GitHub - ionescu007/SpecuCheck: SpecuCheck is a Windows utility for checking the state of the software mitigations against CVE-2017-5754 (Meltdown) and hardware mitigations against CVE-2017-5715 (Spectre)

SpecuCheck
SpecuCheck is a Windows utility for checking the state of the software mitigations against CVE-2017-5754 (Meltdown) and hardware mitigations against CVE-2017-5715 (Spectre). It uses two new information classes that were added to the NtQuerySystemInformation API call as part of the recent patches introduced in January 2018 and reports the data as seen by the Windows Kernel.
Napsauta laajentaaksesi...
 
Cirrus sanoi:
No onneksi intellin pr ymmärtää tämän paremmin kuin täällä.
2/3 mitre tunnisteen saaneesta haavoittuvuudesta koskee myös amd:tä, joten... Totuuden saa aina kertoa.
Napsauta laajentaaksesi...

Unohtamatta Intelin Management Engineä? Sekin vain odottaa aukkojen todentamista jolloin paska taas vyöryy. Väittäisin että ME aukkojen etsintä saa uusia voimia tästä meltdown/spectre huumasta.
 
Viimeksi muokattu:
Onko tietoa miten on Snapdragon Kryo:n laita? Ainakin SD835 Kryo 280 on joku custom A-73, mutta mites SD820 / SD821?
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
258 691
Viestejä
4 496 063
Jäsenet
74 271
Uusin jäsen
Esa.

Hinta.fi

Back
Ylös Bottom