Názory k článku Díry v CPU: Zen 3 má zneužitelný Predictive Store Forwarding. Podle AMD je riziko malé

Tyhle díry jsem nikdy nepochopil. Chápu, že spočívají v tom, že jedno vlákno může přečíst hodnotu paměti, ke které by nemělo mít přístup. Ale absolutně nechápu, jak ví, na které adrese je něco tajného a dokáže poznat, co to má být.

Dokud tu budeme mit "predikci dat a jejich udrzovani v pameti" s nemoznosti jasne separovat datovy prostor danemu procesu primo v "prediktoru", nebo jinak znemozit cteni dat napr. pomoci sifrovani s bezpecnym ulozenim a pouzitim klice, tak tu Spectre bude s nami ;)

Ja by som to nekupoval.. Také deravé buzna cpu max, pre pedra z .de ????

V minulosti u Intelu jsem to chapal tak, ze nedokaze. Tady to bude stejne. V systemu musi byt jeste neco, co prave bude hlidat to, kde se ta zajimava data v pameti nachazi a toto "spectre" potom dostane za ukol je precist nebo pozmenit. Kvuli moznosti zmeny tam Intel integroval nejaky kontrolni kod, ktery kdyz se zmeni, tak se data zahodi, AMD to nebude mit jinak, takze zustava jen ta moznost precteni.
Jak pise Jan Olsan, proste je to dan za vykon procesoru a nebezpeci to je maximalne pro nejakou kritickou infrastrukturu, navic se to da vypnout a snizit si vykon. Domaci uzivatel rozhoden neni ohrozeny. U Intelu tam byl jeste problem, ze se z jednoho vlakna dalo cist jine a pokud byl na kazdem vlakne jiny virtualni pocitac (zase se netyka domaciho uzivatele), mohl jeden cist data druheho. Tady to ale take neni mozne.

Kdyz se to u Skylaku odhalilo, tak se mimo jine rikalo, ze je to konec provadeni spekulativniho uhadnuti kodu. Tahle technika bude opustena.
Ubehlo par let a AMD tu techniku zase nasadilo. Proc? Protoze to zvysuje vykon na ukor maleho rizika bezpecnosti. Neni to vhodne do kriticke infrastruktury, ale domaciho uzivatele vic potesi ten vetsi vykon.

To asi nemusí dopředu vědět, stačí když při pátrání například po šifrovacích klíčích AES-128 vyzkouší všechna získaná cizí data tj. otestovat relativně omezený počet (miliardy) kobinací klíčů což je podstatně rychlejší než brute force útok na 340 282 366 920 938 463 463 374 607 431 768 211 456 možných kombinací. Klíčový budei rozsah a rychlost takto získáných dat. Například u zranitelnosti Spectre kdysi demonstroval Google v Chrome těžbu cizích dat rychlostí cca 1kB/s (tj. 86MB/den, takže například při velikosti paměti 8GB je tu teoretická pravděpodobnost 1:100, že se k datům s uloženými klíči za den dostanu.

Takže s pravděpodobností 1:100 se za den dostanu k nějakému klíči. Ale vůbec netuším, jaký klíč to je a k čemu ho můžu použít. Asi jako když v Praze na Václaváku ztratím klíč od baráku a někdo ho najde. Ve skutečnosti tedy spíš nenajde jen můj klíč, ale miliony různých klíčů, co vypadají jako klíče, ale k ničemu nepasují. A ten zloděj pak začne obcházet všechny zámky a zkoušet, jestli do nich nějaký ten klíč nepasuje.
Prostě pořád si nedovedu představit reálnou hrozbu, kterou by tyto chyby měly způsobit. Teoreticky to samozřejmě můžu demonstrovat, ale při té demonstraci používám znalosti, které ten škodlivý kód nemá. Tedy demonstruju to na svém počítači, kde vím, že je uložený šifrovací klíč ke konkrétní službě konkrétního uživatele a ukážu, že ho ten škodlivý kód dokáže s jistou pravděpodobností najít.

Teoreticky pocas hladania toho kluca ziska informaciu, ze si bol prihlaseny na steam, gmail, fb, internet banking konkretnej banky a este nejakej sluzby a to uz moze vyskusat.

Tyhle utoky jsou spise teoreticke a "minig" by trval dlouho, jak popisuje PetebLazar. Tedy normalni uzivatel by mel byt relativne v bezpeci, pokud nema osobni pocitac zapnuty 24/7 s bezicim virem z nejakeho javascriptu, ktery posila vsemozne info o aktivitach na pocitaci. Celkove to ale neni trivialni problem a ukrast nekomu klic je teoreticky mozne, prakticky spise ne.
U serveru je to trosku vetsi problem, protoze hosting nemuze jen tak restartovat servery a mazat tak nejruznejsi cache a pameti. Tam ty servery - virtualky - musi bezet 24/7 a separace dat mezi nimi musi byt maximalni az absolutni.

Pan Jaroslav Crha 10.4.2021 at 19:21
1. Meltdown je uplne jina liga a je realne docela jednoduse zneuzitelny. Mimochodem asi byste se divil, ale vedelo se o tom HODNE dlouho, nez se to dostalo na verejnost. Muzu rici, ze z toho nejen inzenyri, ale cela oddeleni nespala. To byl problem pouze Intelu.
2. Dalsi problem mel opet ciste pouze Intel s jistym “Spectrem”, u ktereho se vypinal HT, protoze to bylo opet relativne jednoduse zneuzitelne. Propad vykonu byl myslim kolem 30%? Uz presne nevim.
3. Lehci verze Specter mel, ma a bude mit jak Intel, tak AMD, Apple a ARM. O tom se ted a tady bavime, Crho. Tyto se normalniho uzivatele nedotknou a i u serveru to muze byt volitelne nastaveni, protoze zneuzitelnost uz je velmi obtizna.
Takze nez zacnete s nejakym damage control, tak nejdriv hodne studujte a pak se pridte bavit.

Trochu pravdu mas, ale ne uplne.
Prvne propad vykonu byl po oprave MeltaSpektra citelny, tipnul bych to na ~10%.
Druha vec s tim, jak fanousci AMD radili kvuli tezko zneuzitelnemu designu, tak ano, take si to pamatuju, delali tu jak sileny, bylo to k smichu. Jenze casem se ukazalo, ze jedna z tech chyb, ted uz nevim ktera (Melta, Spektra v1, Spektra v2) je zneuzitelna vzdalene, slozite ale slo to, takze nakonec to problem byl znacny!

Já to vrátím do věcné roviny:
1. Ano, je to problém, a bude třeba problém řešit minimálně u serverů.
2. Jedná se o Zen3 arch, takže dopad je (zatím) poměrně malý a podchycený v samotném začátku, navíc AMD nic nezastírá a poskytuje několikeré řešení problému.

Osobně jsem zvědavý, jestli se chyba objeví i v Zen3+?

Presne! Spectre je proti BFU uplne nepouzitelne. Mnohem vetsi riziko je uzivatel sam.

Tady bych vypíchl ale jednu věc - dnes je módní PC jen uspávat a typická Windows10 typického BFU mají uptime i stovky hodin.

Přiznám se, že jsem nepátral po tom, zda takový kód dokáže bez problémů přežít spánek nebo hibernaci, ale minimálně u S1 jsem si téměř jist, u S3 už tak úplně ne.