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

  • Keskustelun aloittaja Keskustelun aloittaja Kaotik
  • Aloitettu Aloitettu
Spaceman sanoi:
Hyvä threadi. Riitaoja ei ymmärrä peruskäsitteitä ohjelmoinnista tai edes millä granulateerilla prosessorit toimivat (bitti/tavu), ja siitä huolimatta on saanut pumpattua hkultalalta mielenkiintoista tietoa viihdyttävässä muodossa. :)
Napsauta laajentaaksesi...
Eikös tämä asia tullut jo käsiteltyä? Ja lisäksi ei ole oikein hyvä tapa pistää nimimerkkiä ja "ei ymmärrä" kommenttia peräkkäin. Se tietäväisempi vänkääjä tähän myös syyllistyi.

Itse aiheeseen, niin sehän on vielä kesken, kun ei tiedetä miten nuo Intelin tulevat mikrokoodipäivitykset toimivat. Kauan kestää kuitenkin korjaus vaikka kesästä 2017 asti ollut tiedossa.
 
hkultala sanoi:
:facepalm:
Tämä alkaa mennä jo kategoriaan "not-even-wrong".


Nykyaikaisissa prosessoreissa on 48-bittiset virtuaalisoitteet(*). Koska tahansa voi tulla osoituksia mihin tahansa näistä virtuaaliosoitteista. Ja mikä tahansa niistä virtuaaliosoitteista voi osoittaa mihin tahansa fyysesssä musitissa (paitsi että alimmat 12 bittiä on aina fyysisessä ja virtuaalisooitteessa samat). Kaikessa kirjanpidossa ja osoitteistuksessa pitää koko ajan ottaa tämä huomioon.


Ja sillä, mitkä entryt sieltä L1-DTLBstä löytyy, ja mitkä se joutuu hakemaan kauempaa, ei ole mitään tekemistä sen kanssa, mitä kirjanpitoa L1D-välimuisti tarvii. VIPT-välimuisti aloittaa accessinsa täysin TLBstä riippumatta(koska tarvii siihen accessiin aloittamiseen vain nitä alimpia 12 bitiä). Ja osuman tarkistamiseen tarvii sen koko fyysisen osoitteen, koska sen pitää pystyä erottamaan mikä tahansa fyysinen osoite toisistaan.

Se, että voidaan tehdä jonnekin 21 bitin alueelle muistisoituksia ilman että sen sisällä sekoaa mitään ei lohduta yhtään mitään, koska aina voi tulla accesseja sen 21 bitin alueen ulkopuolelle. Jos yritetään lukea osoitteesta 0x12345678 mutta saadaankin osoiteen 0x22345678 niin sitten prosessori toimii väärin.




Niinkuin oikeasti. Opettele ohjelmoimaan. Ensin jollain korkean tason kielellä, sen jälkeen assemblyllä. Sen jälkeen voisit ehkä alkaa joskus ymmärtääkin jotain.
Napsauta laajentaaksesi...

Mieti nyt vähän miten esimerkiksi cache toimii. Eli voimme lukea osan datasta nopeammin kuin koko muistista vaikka kuitenkin tarvitsemme sen koko muistin. Osoiteavaruuden voi optimoida aivan samalla tavalla, ei meidän tarvitse mapata koko osoiteavaruutta että saamme sataprosenttisen varmuuden missille ja 99.9+% todennäköisyyden osumalle.


Löysin tälläisen paperin jossa asiaa on yhdistetty itse datacachen tutkailuun:

https://pdfs.semanticscholar.org/20f5/3808fcf89391c0172674d97d9163c7a140ed.pdf

Tuosta nyt selvisi että idea/tutkimus on Lishing Liun vuodelta -94.

Ja jos cache on fyysisesti mapattu tarvitaan aina TLB-muunnos cachen tagin vertailuun, ja TLB:hen tuon käyttäminen soveltuu paljon paremmin kuin virtuaalimuistiin, TLB:n osoiteavaruus on aina ohjelmakoodin osalta lineaarinen, fyysinen muisti voi olla mapattu miten vain. Aikanaan tuota sovelluttu mahdollisesti Alpha EV45:ssa tms. TLB:ssä josta joku tekninen juttu jossain lehdessä josta asia jäänyt päähän. Ja tää oli vain teoriaa, monia muitakin vaihtoehtoja tietty on.


Ja ohjelmointi ei ole mun homma, eikä sen puoleen piirisuunnittelukaan, kai sitä saa silti jostain yrittää keskustella ilman että kaikki mitä itse ei ihan hiffaa tuomitaan vääräksi.

Joo ja pahoittelen että mun kirjallinen ulosanti on aika perseestä, mutta eipä tuo oma tyylisikään kaikkein vähiten provokatiivistä ole.
 
Sami Riitaoja sanoi:
Mieti nyt vähän miten esimerkiksi cache toimii. Eli voimme lukea osan datasta nopeammin kuin koko muistista vaikka kuitenkin tarvitsemme sen koko muistin. Osoiteavaruuden voi optimoida aivan samalla tavalla, ei meidän tarvitse mapata koko osoiteavaruutta että saamme sataprosenttisen varmuuden missille ja 99.9+% todennäköisyyden osumalle.
Napsauta laajentaaksesi...

Ensinnäkin, tuo "99.9+%" lukusi on ihan hatusta vedetty eikä vastaa todellista.

Toisekseen, mikään "99.9% varmuus" ei ole riittävä, ei riitä että 999 muististalukua luetaan oikein jos se tuhannes luetaan väärin.

Tarvitaan 100% varmuus ennen kuin voidaan julistaa välimuistiosuma.

(tai sitten jos se 100% varma osumatieto tulee jotenkin myöhässä, vaaditaan siitä myöhäisestä missistä selviämiseen helposti jotain todella monimutkaista ja hidasta replay-härväystä tai liukuhihnan flushausta jonka haitat on ziljoona kertaa suurempia kuin se hyöty, mikä voidaan jossain kriittisessä polussa saada joidenkin bittien vertailemisesta jotenkin myöhemmin)

Löysin tälläisen paperin jossa asiaa on yhdistetty itse datacachen tutkailuun:

https://pdfs.semanticscholar.org/20f5/3808fcf89391c0172674d97d9163c7a140ed.pdf

Tuosta nyt selvisi että idea/tutkimus on Lishing Liun vuodelta -94.

Ja jos cache on fyysisesti mapattu tarvitaan aina TLB-muunnos cachen tagin vertailuun, ja TLB:hen tuon käyttäminen soveltuu paljon paremmin kuin virtuaalimuistiin, TLB:n osoiteavaruus on aina ohjelmakoodin osalta lineaarinen, fyysinen muisti voi olla mapattu miten vain. Aikanaan tuota sovelluttu mahdollisesti Alpha EV45:ssa tms. TLB:ssä josta joku tekninen juttu jossain lehdessä josta asia jäänyt päähän. Ja tää oli vain teoriaa, monia muitakin vaihtoehtoja tietty on.
Napsauta laajentaaksesi...

Tuossa otettiin HUTEJA pois aikaisin vertaamalla vain alimpia bittejä. Tuossa tehtiin edelleen ihan täysi vertailu ennen kuin voitiin julistaa OSUMA.

Oleellinen pointti tuossa on virransäästö, että kun ekassa vaiheessa luetaan vain ne 2 alinta bittiä, sillä saadaan melkein neljäsosa välimuistin "teistä" pelattua pois ennen täysilevää tag-accessia. Jos välimuistissa on 8 tietä, joissa yhdessä on se data, muissa 7ssä kussakin on 25% todennäköisyydellä samat alimmat tag-bitit, eli tarvii tehdä täysi luku vain keskimäärin 2.75 tielle. Ja jos 8-teisessä välimuistissa sitä dataa ei ole, tarvii tehdä täysi luku vain keskimäärin 2 tielle.

Ja ohjelmointi ei ole mun homma, eikä sen puoleen piirisuunnittelukaan, kai sitä saa silti jostain yrittää keskustella ilman että kaikki mitä itse ei ihan hiffaa tuomitaan vääräksi.
Napsauta laajentaaksesi...

Järkevä keskustelu on sitä, että tiedostetaan se, mitä tiedetään ja ymmärretään, ja mitä ei tiedetä tai ymmärretä, eikä aleta väittää varmaksi omaa tulkintaa asioista, joita ei ymmärrä.
 
Jaahas herrat ovat lähellä asian ydintä.
Luulen että se osaavin taho ei huutele vaan tekee ja toimii (toivottavasti).
 
Zen_8400 sanoi:
Jätänpä tämän tähän 13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors
Napsauta laajentaaksesi...
Kommentoidaan nyt tännekin sen verran että ilmeisesti kyse on firman markkinamanipulointiyeityksestä. Ja ko. Firma on ilmeisesti matkalla jostain vastaavasta jo oikeuteen Saksassa.

Ilmeisesti haavoittuvuudet sinänsä ovat "todellisia", että ne on olemassa JOS koneeseen asennetaan tarkoituksella haitallinen BIOS, firmis piirisarjalle jne. Sellaisenaan koneissa ei ole noita haavoittuvuuksia.
Lisäksi huomionarvoista on että "löydökset" julkistettiin alle 24h sen jälkeen kun niistä oli ilmoitettu AMDlle joka ei ehtinyt vastaamaan tai ottamaan kantaa väitteisiin ennen julkaisua

Mutta tutkitaan tietenkin vielä asiaa
 
Kaotik sanoi:
Kommentoidaan nyt tännekin sen verran että ilmeisesti kyse on firman markkinamanipulointiyeityksestä. Ja ko. Firma on ilmeisesti matkalla jostain vastaavasta jo oikeuteen Saksassa.

Ilmeisesti haavoittuvuudet sinänsä ovat "todellisia", että ne on olemassa JOS koneeseen asennetaan tarkoituksella haitallinen BIOS, firmis piirisarjalle jne. Sellaisenaan koneissa ei ole noita haavoittuvuuksia.
Lisäksi huomionarvoista on että "löydökset" julkistettiin alle 24h sen jälkeen kun niistä oli ilmoitettu AMDlle joka ei ehtinyt vastaamaan tai ottamaan kantaa väitteisiin ennen julkaisua

Mutta tutkitaan tietenkin vielä asiaa
Napsauta laajentaaksesi...

Tutkinnoissa voisi lähteä liikkeelle vaikkapa siitä, että kuka tämän CTS-Labsin toimintaa rahoittaa. Ajoitus viittaa kyllä aika vahvasti yhteen suuntaan.
 
Alleged AMD Zen Security Flaws Megathread • r/Amd

Tuolla on hyviä linkkejä. "Bugit löytänyt" firma mm. ilmeisesti on feikannut pääkonttorinsa green screenin ja muutaman kuvapankkiotoksen avulla. Ellei muuta todisteta, niin kuulostaa suuren luokan kusetus / markkinamanipulaatioyritykseltä

EDIT: Ja ilmeisesti kaikki noista tarvitsevat admin oikeudet toimiakseen. Jos hyökkääjä saa admin oikeudet, niin peli on joka tapauksessa menetetty oli haavoittuvuuksia tai ei, joten koko homma kuulostaa todella liioitellulta
 
Viimeksi muokattu:
Gigabyte GA-H270N-WIFI emoon on näköjään ilmestynyt uusi bios F8d (2018/03/09)
  1. Update CPU Microcode
Reilu kuukausi sitten ilmestyi aikaisempi F8b, joka korjasi samaa. Itsellä ei ole ollut tuon vanhan kanssa mitään ongelmia. Kone pfSense palomuurina niin ongelmat olisi kyllä huomannut.
 
hkultala sanoi:
Ensinnäkin, tuo "99.9+%" lukusi on ihan hatusta vedetty eikä vastaa todellista.

Toisekseen, mikään "99.9% varmuus" ei ole riittävä, ei riitä että 999 muististalukua luetaan oikein jos se tuhannes luetaan väärin.

Tarvitaan 100% varmuus ennen kuin voidaan julistaa välimuistiosuma.

(tai sitten jos se 100% varma osumatieto tulee jotenkin myöhässä, vaaditaan siitä myöhäisestä missistä selviämiseen helposti jotain todella monimutkaista ja hidasta replay-härväystä tai liukuhihnan flushausta jonka haitat on ziljoona kertaa suurempia kuin se hyöty, mikä voidaan jossain kriittisessä polussa saada joidenkin bittien vertailemisesta jotenkin myöhemmin)
Napsauta laajentaaksesi...

Täähän oli liittyen Meltdowniin, eli Meltdownin selittää hyvin se että TLB:t käsitellään jäljessä. Jo jäljessä käsittely antaa paljon aikaa optimoida homman virrankulutusta, ja voidaan esimerkiksi koota kaikki tietylle linjalle osuvat hitit yhdessä.

Intel on ollut hipihiljaa iät ja ajat L1-taggauksestaan, mutta AMD on dokumentoinut Zenin L1-taggauksen ja TLB-käsittelyn oikein hyvin. Eli Zenin L1 on täysin virtuaalisesti accessoitu osittaiseisen lineaarisen tagin mukaan. Väärintulkintamahdollisuudet ja muut konfliktit on hoidettu L2:ssa.

https://support.amd.com/TechDocs/55723_SOG_Fam_17h_Processors_3.00.pdf

Toki AMD puhuu itse way predictionista mutta dokumennoinin mukaan on ihan selvää että fyysistä tagia ei ikinä L1:ssä käsitellä. Eikä ole uusi tekniikka, samaa on käytetty jo 80-luvulla direct mapped kakkujen kanssakin.
 
Sami Riitaoja sanoi:
Täähän oli liittyen Meltdowniin, eli Meltdownin selittää hyvin se että TLB:t käsitellään jäljessä. Jo jäljessä käsittely antaa paljon aikaa optimoida homman virrankulutusta, ja voidaan esimerkiksi koota kaikki tietylle linjalle osuvat hitit yhdessä.
Napsauta laajentaaksesi...

:facepalm:

"Jäljessä" ei ole "jäljessä" vaan sen data- ja tag-accessin kanssa rinnakkain, VIPT jonka olen jo vähintään kahteen kertaan selittänyt.

Ja osumaa ei edelleenkään voi julistaa ilman sitä oikeaa fyysistä osoitetta, jolla se L1-kakku on tagettu.

Ja muuten alkaa mennä taas "not even wrong"-osastolle. Pienen L1-TLBn acessoiminen ei vie paljoa virtaa, eikä sen venyttäminen moneen kellojaksooon säästäsisi sitä mitenkään merkittävästi. Ja joku ziljoonan eri accessin yhdistämislogiikka olisi paljon monimutkaisempi ja hankalampi kuin mitkään sen hyödyt.

Intel on ollut hipihiljaa iät ja ajat L1-taggauksestaan, mutta AMD on dokumentoinut Zenin L1-taggauksen ja TLB-käsittelyn oikein hyvin. Eli Zenin L1 on täysin virtuaalisesti accessoitu osittaiseisen lineaarisen tagin mukaan. Väärintulkintamahdollisuudet ja muut konfliktit on hoidettu L2:ssa.

https://support.amd.com/TechDocs/55723_SOG_Fam_17h_Processors_3.00.pdf

Toki AMD puhuu itse way predictionista[/b] mutta dokumennoinin mukaan on ihan selvää että fyysistä tagia ei ikinä L1:ssä käsitellä. Eikä ole uusi tekniikka, samaa on käytetty jo 80-luvulla direct mapped kakkujen kanssakin.
Napsauta laajentaaksesi...

AMD on dokumentoinut L1-tagauksensa ja TLB-käsittelynsä oikein hyvin ja sen sijaan että uskot sitä AMDn dokumentaatiota keksit omasta päästäsi että sen täytyy kuitenkin toimiahiukan eri tavalla kuin miten AMD sen dokumentoi toimivan.

(ja keksit siihen omasta päästäsi tavaksi sellaisen, missä ei ole mitään järkeä, koska se aiheuttaisi hyvin pahoja ongelmia)

:facepalm:
 
hkultala sanoi:
:facepalm:

"Jäljessä" ei ole "jäljessä" vaan sen data- ja tag-accessin kanssa rinnakkain, VIPT jonka olen jo vähintään kahteen kertaan selittänyt.

Ja osumaa ei edelleenkään voi julistaa ilman sitä oikeaa fyysistä osoitetta, jolla se L1-kakku on tagettu.
Napsauta laajentaaksesi...

Jos ei mahdu päähän niin ei mahdu. Eli siis jos vaikka AGU:n laitetaan tieto kuinka suurelle alueelle L1-cachen data on levittäytynyt virtuaalisen tagin osumaksi riittää bittimäärä joka kattaa tuon alueen. Fyysinen osoite on oltava kokonainen, virtuaalisen lineaarisen ei. Esimerkiksi Zenin L1-latenssi on 4 kellojaksoa lyhyellä osoitteella ja 5 pidemmillä.

Ja muuten alkaa mennä taas "not even wrong"-osastolle. Pienen L1-TLBn acessoiminen ei vie paljoa virtaa, eikä sen venyttäminen moneen kellojaksooon säästäsisi sitä mitenkään merkittävästi. Ja joku ziljoonan eri accessin yhdistämislogiikka olisi paljon monimutkaisempi ja hankalampi kuin mitkään sen hyödyt.
Napsauta laajentaaksesi...

Yhden cachelinjan tarvittava data on yleensä 64 bittiä. TLB:n kautta haettuna ensin pitää hakea 36 bittinen virtuaalinen vastaavuus, sen jälkeen lukea 36 bittinen fyysinen käännös ja verrata tätä cachelinjojen 36 bittiseen tageihin. Etkö edelleenkään näe tässä mitään mahdollisuutta säästää mitään?

AMD on dokumentoinut L1-tagauksensa ja TLB-käsittelynsä oikein hyvin ja sen sijaan että uskot sitä AMDn dokumentaatiota keksit omasta päästäsi että sen täytyy kuitenkin toimiahiukan eri tavalla kuin miten AMD sen dokumentoi toimivan.

(ja keksit siihen omasta päästäsi tavaksi sellaisen, missä ei ole mitään järkeä, koska se aiheuttaisi hyvin pahoja ongelmia)

:facepalm:
Napsauta laajentaaksesi...

No just luin sen tuosta 17h optimointiopuksesta. L1:n ollessa L2:n subset jokainen cachelinja on tagätty fyysisesti L2:ssa, suurin osa virtuaalisen L1:n taggauksen ongelmista poistui siinä. Ja AMD kertoo tuossa linkitetyssä oppaassaan kaikki virtuaalisen L1-cachen taggauksen mahdolliset haittapuolet, todennäköisesti implementaatio ei edes kaikista niistä kärsi. Selvästi käy kuitenkin selväksi että L1:stä accesssoidaan vain virtuaalisen tagin mukaan, fyysisen ollessa oikein mutta virtuaalisen väärin(prosessin vaihto) osuma tulee L2:sta eikä L1:stä, L1:n tagi päivitetään.
 
Super-GAU für Intel: Weitere Spectre-Lücken im Anflug

Kahdeksan uutta spectre-haavoittuvuutta löydetty. Näiden on vahvistettu koskevan Intelin prosessoreita ja joitakin ARM prosessoreita. AMD:n mahdollinen haavoittuvuus on vielä tutkinnassa.

Jokainen näistä saa Spectren ja Meltdownin tapaan oman nimen ja haavoittuvuusnumeron (Common Vulnerability Enumerator, CVE). Toistaiseksi näitä haavoittuvuuksia kutsutaan nimellä 'Spectre Next-Generation'.

Puolet haavoittuvuuksista on vakavia:
"Intel classifies four of the Specter NG vulnerabilities as "high-risk"; the danger of the other four is only rated as medium."

Päivityksiä näihin on tulossa mahdollisesti jo tässä kuussa ja lisää myöhemmin kesällä. Odotettavissa on lisää hidastuksia edellisten päivitysten päälle.
 
TAspect sanoi:
Super-GAU für Intel: Weitere Spectre-Lücken im Anflug

Kahdeksan uutta spectre-haavoittuvuutta löydetty. Näiden on vahvistettu koskevan Intelin prosessoreita ja joitakin ARM prosessoreita. AMD:n mahdollinen haavoittuvuus on vielä tutkinnassa.
Napsauta laajentaaksesi...

Nää on Meltdown-haavoittuvuuksia vaikka ovatkin nimetty Spectreksi. Eli Intelin prossut ja ARM:t jotka Meltdownista kärsivät ovat potentiaalisia kohteita. KPTI erottaa muistiavaruudet mutta Meltdownista kärsivät prosessori on täysin rikki muistinsuojauksen osalta, nyt nähtävästi on sitten löydetty mahdollisuudet ronkkia cachesta dataa ulos - korjaus lienee cachen tyhjentäminen aina osoiteavauuren muutoksien yhteydessä ellei keksitä jotain vähemmän hittiä aiheuttavaa suojausta. Alkaa olemaan Intelin prossut aika turhia serveripuolella.....
 
Sami Riitaoja sanoi:
Nää on Meltdown-haavoittuvuuksia vaikka ovatkin nimetty Spectreksi. Eli Intelin prossut ja ARM:t jotka Meltdownista kärsivät ovat potentiaalisia kohteita. KPTI erottaa muistiavaruudet mutta Meltdownista kärsivät prosessori on täysin rikki muistinsuojauksen osalta, nyt nähtävästi on sitten löydetty mahdollisuudet ronkkia cachesta dataa ulos - korjaus lienee cachen tyhjentäminen aina osoiteavauuren muutoksien yhteydessä ellei keksitä jotain vähemmän hittiä aiheuttavaa suojausta.
Napsauta laajentaaksesi...

Jos tuo pitää paikkansa ja osoittautuu, että AMD on immuuni koko tälle Spectre-NG -haavoittuvuusjoukolle, niin laitan kyllä AM4-lankun, 2700X:n, ja muistit tilaukseen. Ehkäpä suhtaudun asiaan liian epärationaalisesti ja tunteella, mutta en vain voi sille mitään että Intelin reikäjuustoprosessorin käyttäminen alkaa tässä vaiheessa tuntua suorastaan vastenmieliseltä.
 
No aika tietysti näyttää osuuko näistä mitään/mikään Ryzeneille, mutta joka tapauksessa ei voi kuin ihmetellä. Aivan vitun käsittämätöntä. Miten voi olla että miljaardien R&D budjetilla ei näitä pystytä löytämään ja vuosikaudet tehdään rikkinäisiä tuotteita.. Huoh.

Akateemiset tutkijat, googlen inssit ja ketä näitä nyt löytääkään... Kuinka kauan vaikka NSA:lla on ollut työkalut näiden exploittaamiseen...
 
No ei nää nyt löydetyt haavoittuvuudet tavallista työpöytäkäyttäjää haittaa millään tavalla. Serveripuolella varmaan alkaa kohta olla tarve pistää Meltdown-prossut kierrätykseen, tuskin nää haavoittuvuudet vielä tähänkään tulee jäämään ja jos joka fiksi syö suorituskykyä niin....
 
Aika rohkeaa väittää näillä tiedoilla ettei nämä peruskäyttäjää haittaa. En ehkä ole peruskäyttäjä, mutta ajelen juurikin virtuaalikoneita tekemään asioita, joissa mahdollisuus törmätä vihamieliseen ohjelmakoodiin on normaalia suurempi.

Eiköhän nyt vaan odotella rauhassa että viralliset advisoryt tulee pihalle ja sitten hutkitaan lisää. Peace out.
 
aiwan sanoi:
Aika rohkeaa väittää näillä tiedoilla ettei nämä peruskäyttäjää haittaa. En ehkä ole peruskäyttäjä, mutta ajelen juurikin virtuaalikoneita tekemään asioita, joissa mahdollisuus törmätä vihamieliseen ohjelmakoodiin on normaalia suurempi.

Eiköhän nyt vaan odotella rauhassa että viralliset advisoryt tulee pihalle ja sitten hutkitaan lisää. Peace out.
Napsauta laajentaaksesi...
Ei, et todellakaan ole peruskäyttäjä. Peruskäyttäjä on tuskin edes kuullut ikinä sanaa "virtuaalikone".
 
Chloe Price sanoi:
Veikkaisin itse ihan mutupohjalta että jos näistä ei olisi koskaan raportoitu, niin harva olisi tuskin mitään huomannut edes.
Napsauta laajentaaksesi...

Tämä on varmaankin totta, jos tarkastellaan koko maailman PC-käyttäjäkuntaa kokonaisuutena. Mutta ei ketään taida kauheasti kiinnostaa, miten keskimääräinen käyttäjä keskimäärin tilanteen kokee.

Perkules kun ei ollut mahdollisuutta testata tällä 7700K:lla ennen ja jälkeen esim. Cinebenchiä, oli vielä 7600K kun noita päivityksiä alkoi sadella.
Napsauta laajentaaksesi...

Esim. InSpectrellä saat kytkettyä Meltdown- ja Spectre-pätsit päälle ja pois, jos haluat testata niiden vaikutusta suorituskykyyn (Cinebenchissä eroa ei juurikaan tule).
 
Kaotik sanoi:
Tämä tuskin toimii mikrokoodi-pätsin suhteen?
Napsauta laajentaaksesi...

Jos olen oikein ymmärtänyt, niin Spectre-mikrokoodi vaikuttaa suorituskykyyn vasta silloin, kun käyttöjärjestelmä kytkee mikrokoodin mukanaan tuomat uudet ominaisuudet päälle.
 
Viimeksi muokattu:
Microsoft ja Google ovat yhdessä julkaiseet uuden sivukanavahaavoittuvuuden: Speculative Store Bypass (variant 4). Intel sanoo, että nettiselaimiin jo aikaisemmin tulleet päivitykset tarjoavat osittaista suojaa myös varianttia 4 vastaan, mutta täyttä suojaa varten tarvitaan uusi, tällä hetkellä betavaiheessa oleva mikrokoodipäivitys. Mikrokoodin vaikutus prosessorin suorituskykyyn on 2-8 prosenttia. Artikkelin perusteella on epäselvää, onko tuo kaikkien suojausten yhteisvaikutus, vai tuleeko V4:n aiheuttama hidastuminen vielä SpectreV2-mikrokoodin aiheuttaman hidastumisen päälle.
 
Atorox sanoi:
Microsoft ja Google ovat yhdessä julkaiseet uuden sivukanavahaavoittuvuuden: Speculative Store Bypass (variant 4). Intel sanoo, että nettiselaimiin jo aikaisemmin tulleet päivitykset tarjoavat osittaista suojaa myös varianttia 4 vastaan, mutta täyttä suojaa varten tarvitaan uusi, tällä hetkellä betavaiheessa oleva mikrokoodipäivitys. Mikrokoodin vaikutus prosessorin suorituskykyyn on 2-8 prosenttia. Artikkelin perusteella on epäselvää, onko tuo kaikkien suojausten yhteisvaikutus, vai tuleeko V4:n aiheuttama hidastuminen vielä SpectreV2-mikrokoodin aiheuttaman hidastumisen päälle.
Napsauta laajentaaksesi...

Tähän tuoreimpaan taitaa AMDn K7-johdannaiset (eli siis phenomiin asti) olla immuuneita, ne eivät tee mitään ennustuksia sen suhteen, aliasoituuko loadit ja storet keskenään, vaan uudelleenjärjestelevät vain sellaisia loadeja ja storeja, joiden osoitteet on täysin tiedossa.

Intelillä ensimmäinen haavoittuva taitaa olla Core 2.

Applen ARM-ytimet ovat myös haavoittuvaisia tälle, monet muut ARMit sen sijaan immuuneja. (ei kuitenkaan välttämättä kaikki muut).
 
hkultala sanoi:
Tähän tuoreimpaan taitaa AMDn K7-johdannaiset (eli siis phenomiin asti) olla immuuneita, ne eivät tee mitään ennustuksia sen suhteen, aliasoituuko loadit ja storet keskenään, vaan uudelleenjärjestelevät vain sellaisia loadeja ja storeja, joiden osoitteet on täysin tiedossa.

Intelillä ensimmäinen haavoittuva taitaa olla Core 2.

Applen ytimet ovat myös haavoittuvaisia tälle.
Napsauta laajentaaksesi...
Minä ymmärsin erillä tavalla:
AMD Processor Security | AMD

Uutisessa sanotaan että microsoft toimittaa suositellut korjaukset 15h gen asti.
 
Cirrus sanoi:
Minä ymmärsin erillä tavalla:
AMD Processor Security | AMD

Uutisessa sanotaan että microsoft toimittaa suositellut korjaukset 15h gen asti.
Napsauta laajentaaksesi...

amd whitepaper sanoi:
AMD processors families 15h, 16h, and some models of family 17h have logic that allow loads to bypass older stores but lack the architectural SPEC_CTRL or VIRT_SPEC_CTRL. For software that requires protection, software can directly manipulate non-architectural MSRs.
Napsauta laajentaaksesi...

Tuolla mainitaan AMDn prosessoriperheet 15h( = bulldozer, piledriver, steamroller, excavator) , 16h ( = bobcat, puma, jaguar) , 17h ( = zen)

Vanhempia ei mainita, koska ne ei tee tuota optimointia.
 
aiwan sanoi:
Aika rohkeaa väittää näillä tiedoilla ettei nämä peruskäyttäjää haittaa. En ehkä ole peruskäyttäjä, mutta ajelen juurikin virtuaalikoneita tekemään asioita, joissa mahdollisuus törmätä vihamieliseen ohjelmakoodiin on normaalia suurempi.

Eiköhän nyt vaan odotella rauhassa että viralliset advisoryt tulee pihalle ja sitten hutkitaan lisää. Peace out.
Napsauta laajentaaksesi...
Eikös toi mennyt niin että intelillä piti olla ihan tietty versio prossusta että noita voi ajaa ja amd:llä taas toimii kaikissa?.itse ei noita tule käytettyä vaan pistän mielummin toisen koneen päälle jos haluan jotain testata.:)

x86 virtualization - Wikipedia
 
hkultala sanoi:
Tuolla mainitaan AMDn prosessoriperheet 15h( = bulldozer, piledriver, steamroller, excavator) , 16h ( = bobcat, puma, jaguar) , 17h ( = zen)

Vanhempia ei mainita, koska ne ei tee tuota optimointia.
Napsauta laajentaaksesi...
Olet oikeassa. Ymmärsin sinun viestisi täysin väärin!
 
hkultala sanoi:
Tuolla mainitaan AMDn prosessoriperheet 15h( = bulldozer, piledriver, steamroller, excavator) , 16h ( = bobcat, puma, jaguar) , 17h ( = zen)

Vanhempia ei mainita, koska ne ei tee tuota optimointia.
Napsauta laajentaaksesi...
Miten toi voi olla tuossa AMD whitepaperissa että "...and some models of family 17h have logic..." ? Nyt vähän avoimuutta kuluttajia kohtaan AMD.
 
Tämähän alkaa vaikuttaa siltä, että kun omaa konetta ja sen rautaa seuraavan kerran päivitellään, niin kyse ei ole niinkään tehonlisästä kuin tietoturvapäivityksestä raudalle.
 
Niin kauan, kun noilla vain voidaan lukea tietoa (käytännössä hitaasti ja vaivalloisesti), peruskäyttäjälle noiden haitta ei ole kriittinen. Ilmeisesti tuo selainten pätsi, josta puhuttiin osittain auttavana lie scriptien ajastuksen / tarkan kellon sotkeminen.

Sitäkautta tuo telee varmaankin kaikkien ongelmaksi, että tiettyjä tukia saatetaan tiputtaa laitteilta, kun ja jos tuon kautta voidaan lukea materiaalien suojausavaimia ym. Mielenkiintoista nähdä, onko mitä vaikutusta pleikkari / Xbox alueella. Niissä on tosin pirun köyhät prossut, joten toimiikohan niissä mitkään näistä?

Jos olen käsittänyt oikein, niin noiden käyttö tekee ainankin yhden raskaan threadin. Periaatteessa, kun jopa videon dekoodaus on nykyään yleensä kevyttä kauraa, niin selaimen voisi pistää aina pysäyttämään yli hetken kestävät kaikki raskaat threadit ja vaatimaan hyväksyntä, ennen jatkamista.

Palvelimissa, jos niissä ajetaan useita käyttäjiä / softia tuo on ongelma. Sitten taas jos ajetaan vain jotain laskentaa, niin hidastavat patsit voidaan huoletta poistaa..
 
Windowsiin tuli näköjään viimeisimmän patch tuesdayn mukana tuki variant 4 -suojaukselle. Tuen aktivoimiseksi tarvitaan myös mikrokoodipäivitys. Variantti 4 on ilmeisestikin lähinnä IT-ammattilaisten ja palvelinpuolen ongelma, kotikäyttäjän ei tarvitse siitä välittää.

Uusin julkaistu haavoittuvuus vuotaa FPU/MMX/SSE/AVX -rekisterit, ja on nimeltään "Lazy FPU State Restore". Embargo purettiin kuukausi etuajassa, koska tieto haavoittuvuuden olemassaolosta vuoti julkisuuteen, ja POC-koodinkin joku jo ehti väsäämään. Lazy FPU -haavoittuvuutta on ilmeisesti erittäin hankala hyödyntää etänä, sen paikkaamiseen vaaditaan vain käyttöjärjestelmäpäivitys, ja esim. Linux on ollut siltä suojassa jo kernelistä 4.6 alkaen. Windowsin tilanteesta en löytänyt äkkiseltään tietoa.
 
Ja taas julkaistiin lisää:

New Spectre-Level Flaw Targets Return Stack Buffer

“In this paper, we introduce a new attack vector for Spectre-like attacks that are not prevented by deployed defenses,” researcher Nael Abu-Ghazaleh wrote in the paper. “Specifically, the attacks exploit the return stack buffer (RSB) to cause speculative execution of the payload gadget that reads and exposes sensitive information.”
 
Tämänkään toimintaa ei ole todistettu AMD:n tai ARM:n prosessorilla. Voi olla ettei toimi AMD:lla ja taas Intelin nopeus tippuu kun AMD:n pysyy samana :cigar:
 
Kannattaako nyt odotella rautapäivitettyjä prossuja vai voiko hyvillä mielin uusia läppärin. Uudessa koneessa olisi Intel 8550u. Jos nyt ensivuonna saa jotenkin paljon ajankohtaisempia laitteita, niin ehkä sinne voisi kärvistellä. Nykyinen Lenovo sai mikrokoodipäivityksiä ja käyttis on viimeisin Win10, joten sillä vielä pärjännee, mutta kun rahaa laittaa tiskiin, niin mieluusti sitten maksaa pitkäikäisestä laitteesta.
 
Asiaahan voi tarkastella esim. päivitysten saatavuuden tai koneen suorituskyvyn näkökulmasta. Intel tarjoaa Spectre-mikrokoodipäivitykset tällä hetkellä muistaakseni Nehalemiin, eli n. 10 vuotta vanhoihin prosessoreihin saakka. Jos Intel jatkaa samalla linjalla tulevaisuudessakin, niin 8550u-prosessorille tulee päivityksiä jonnekin 2020-luvun loppupuolelle saakka. Ts. rautapäivitettyjen prossujen odottelu on turhaa. Uudet mikrokoodit saa aina asennettua Windowsin kautta, joten siitäkään ei tarvitse olla huolissaan, että Lenovo lopettaisi läppärin tukemisen.

Toisaalta, jos annat koneen suorituskyvylle erityistä painoarvoa (varsinkin I/O-operaatioiden osalta), niin kannattaa ehkä jättää konepäivitys myöhemmäksi. Nyt ostetun koneen nopeus on jo valmiiksi jonkin verran kärsinyt Meltdown/Spectre-päivitysten takia ja se saattaa tulevina vuosina hidastua uusien sivukanavahaavoittuvuuksien paikkailun myötä vielä lisää.
 
Atorox sanoi:
Asiaahan voi tarkastella esim. päivitysten saatavuuden tai koneen suorituskyvyn näkökulmasta. Intel tarjoaa Spectre-mikrokoodipäivitykset tällä hetkellä muistaakseni Nehalemiin, eli n. 10 vuotta vanhoihin prosessoreihin saakka. Jos Intel jatkaa samalla linjalla tulevaisuudessakin, niin 8550u-prosessorille tulee päivityksiä jonnekin 2020-luvun loppupuolelle saakka. Ts. rautapäivitettyjen prossujen odottelu on turhaa. Uudet mikrokoodit saa aina asennettua Windowsin kautta, joten siitäkään ei tarvitse olla huolissaan, että Lenovo lopettaisi läppärin tukemisen.

Toisaalta, jos annat koneen suorituskyvylle erityistä painoarvoa (varsinkin I/O-operaatioiden osalta), niin kannattaa ehkä jättää konepäivitys myöhemmäksi. Nyt ostetun koneen nopeus on jo valmiiksi jonkin verran kärsinyt Meltdown/Spectre-päivitysten takia ja se saattaa tulevina vuosina hidastua uusien sivukanavahaavoittuvuuksien paikkailun myötä vielä lisää.
Napsauta laajentaaksesi...
En tiennytkään, että mikrokoodit ei vaadi BIOS päivitystä. Tämä on hyvä, sillä uusi läppäri olisi Huawei ja heidän tuestaan ei ole kokemuksia.

Vaikea ottaa kantaa IO suorituskykyyn. Videoeditointia, photaria ja kevyitä pelejä on tarkoitus käytellä.
Suorituskyky tippunee verrannollisesti myös muissa ja odottaessa vanha läppärini hidastuu entisestään myös.
 
Atorox sanoi:
Toisaalta, jos annat koneen suorituskyvylle erityistä painoarvoa (varsinkin I/O-operaatioiden osalta), niin kannattaa ehkä jättää konepäivitys myöhemmäksi. Nyt ostetun koneen nopeus on jo valmiiksi jonkin verran kärsinyt Meltdown/Spectre-päivitysten takia ja se saattaa tulevina vuosina hidastua uusien sivukanavahaavoittuvuuksien paikkailun myötä vielä lisää.
Napsauta laajentaaksesi...

Nimenomaan näin. Noiden "rautakorjattujen" prosessorien pitäisi olla nopeampia kuin softalla korjattujen. Olennaista sekin ettei tiedetä millaista uutta Spectreä vielä keksitään ja rautakorjauksen "pitäisi" estää myös vielä keksimättömien Spectre-tyylisten hyökkäysten toiminta, tai osa niistä. Huonolla tuurilla keksitään jotain ihan uutta ja sitten taas tarvitaan erilaista korjausta. Ei ole juurikaan ollut edes spekulaatiota tuollaisista.
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
262 355
Viestejä
4 553 652
Jäsenet
74 959
Uusin jäsen
sorjonen

Hinta.fi

Back
Ylös Bottom