Vlákno názorů k článku BranchScope je nový útok postranním kanálem na procesory Intel od utracena exekuce - Neni to tak davno, cca 20 let, kdy...
-
utracena exekuce (neregistrovaný)
Neni to tak davno, cca 20 let, kdy jsem se velmi podivoval nad spekulativnim provadenim instrukci. Cele mi to prislo zalozene na predpokladu, ze vetveni se vlastne dit nebude a proto si vse pripravime dopredu. A kdyz nakonec vetveni nastane, budeme vytresteni jako krava pred kopcem a vse pripravene splachneme do zachodu. Namitky, ze vetveni se precejen deje, byly bagatelizovany s tim, ze sice ano lec velice zridka.
Je to stejna logika, jako kdyz mame garaz s vraty, ktere nejsou videt z prijezdove silnice. Auto zajizdi do garaze bez zastaveni na zaklade predpokladu, ze vrata jsou temer vzdy otevrena. Majitel vrata totiz zavira jen zcela vyjimecne a tak se prilis nevyplati zastavovat kvuli kontrole stavu vrat. Timto totiz lze usetrit nejaky cas. Az potud vcelku prima 'life hack'.
Lec jen do okamziku hacku tohoto 'life hacku'. On si totiz nekdo uvedomil, ze pokud je predpoklad otevrenosti vrat spravny, lze temer neustale otevrenou garaz pohodlne vykrast. Zrejme se nejedna o myslenku, ze ktere by si vetsina z nas v nemem uzasu sedla na zadek. O to vice mne bavi ten nemy uzas a mozna az hysterie, kterezto utoky postrannimi kanaly vyvolavaji.
-
Jenže ono to má dramatický dopad na výkon, protože ten prediktor se v drtivé většině případů trefí. A i když se netrefí, tak není situace horší, než kdyby to nezkusil. Prostě se zahodí práce, která se dělala na pozadí navíc. Když se ale trefí, roste výkon i několikanásobně. Doporučuji přednášku odkazovanou v článku.
Myšlenka je to skvělá, jen se předpokládalo, že informace nepronikají ze spekulativní části do té ostré. Ale samotné spekulativní vykonávání je velmi užitečné a nechceme o něj přijít. Stačí se podívat, jaký dopad mají jen záplaty, které kvůli Spectre upravují chování keší. Výkon padá až o třetinu a lidem to dost vadí.
-
Petr M (neregistrovaný)
No a navíc se zjistilo, že se střeva CPU flákají, tak se to použilo na HyperThread a podobný vopičárny. Kdyby se spekulativně dělaly obě větve, tak tam stopa v cache zůstane i nezůstane a rychlost by byla ještě vyšší (pokud je počet instrukvcí mezi skoky <= délce pipeline, nečeká se nikdy s výjimkou sosání do cache - a i to začne dřív, než při posledním průchodu cyklem před skokem do jiné stránky). A pochybuju, že další bank registrů by zabral víc křemíku, než několikaúrovňový tabulky předpovědí.
-
Peter FodrekZlatý podporovatelkolko vetveni moze byt v 20- stupnovej pipeline, aku mame dnes?
teoreticky 20
a top dava 2^20= 2048 vetiev, to chcem vediet, ako by sa z nich vyberela ta spravna, a tu logiku a pocet vykonnych jednotiek.... -
20 kroková pipeline neznamená 20 instrukcí skoku. Jednak aby dávalo smysl udělat podmíněný skok, tak se předtím musí ta podmínka vyhodnotit, což může být i několik instrukcí nebo volání funkce apod., dále se zpracování každé instrukce rozpadá na několik fází a právě tyto fáze jsou v těch pipeline krocích.
Když to vezmu z druhé strany - pokud dám za sebou několik podmíněných skoků, tak se mezi nimi nezmění stav FLAGS registru, tedy už tam je vše spočítané a CPU to nemusí dělat spekulativně protože tu podmínku zná.Takže i pokud se budu snažit, těch opravdu podmíněných větvení do pipeline moc nedostanu. A popravdě nevím jestli na to má CPU nějaký limit.
-
Peter FodrekZlatý podporovatel
tých 20 vetvení je možných za sebu na rôzne flagy, ktoré sa nastavia pred tým vetvením. A samozrejme ide o vetvenia v mikrokóde.
-
> tých 20 vetvení je možných za sebu na rôzne flagy, ktoré sa nastavia pred tým vetvením
A kolik asi tak skoků se provede spekulativně pokud předtím CPU vyhodnotí všechny podmínky?
> samozrejme ide o vetvenia v mikrokóde
Nechceš se nad tím výrokem ještě jednou zamyslet? Pokud tedy alespoň tušíš co to je mikrokód.
-
Peter FodrekZlatý podporovatel
mikrokód je sada mikroprogrmov (v mojom význame) Mikroprogram pre konkrétnu inštrukciu je program vykonávajúci danú zložitú inštrukciu inštrukčnej sady CPU.
vďaka preplánovaniu (reorder) mikroinštrukcií a premenovaniu (rename) registrov je taká situácia pravdepodobnejšia, lebo vieme premiešať mikroinštrukcie rôznych inštrukcií.
-
Petr M (neregistrovaný)
Takže něco jako instrukce pro kopírování bloku? Tam je read, write, inc read pointeru, inc write pointeru, dec čítače, kontrola meze čítače, skok. Sedm instrukcí. Pokud to nedělá chomták, tak RISC jádro hodí bez problémů 3-5 řezů, takže podmínka je splněna a i během průchodu je bez predikce připravený na konec (jenom aktualizuje výsledky při každým průchodu, prostor na to je). A má přednačtený v cache, s čím bude dělat po konci cyklu.
Btw, čím víc řezů pipeline, tím víc rozdělané a míň dokončené práce při stejným taktu máš.
-
Peter FodrekZlatý podporovatel
>A i když se netrefí, tak není situace horší, než kdyby to nezkusi
To je otazka, vo vykon nie, ale je tam spotrebovana enmegria na zmeny stavov CMOS, takze sa spotrebuje nmejaka energia a je to nanic...
-
tap (neregistrovaný)
Myslim, ze to nieje spravne prirovnanie. Situacia je skor taka, ze viacero garazi vedla seba brany su otvorene alebo zatvorene. Pri otvorenej brane auto rychlo zaparkuje pri zatvorenej auto zastavi premavku otvori si... No a ide o to ze nejaky extrerny pozorovatel na najblizsej krizovatke podla hustoty premavky vie odhadnut ci a ktora brana bola alebo nebola zatvorena. Pozorovatelovi velmi pomoze ked na zaciatku moze do premavky pustat auta, o ktorych vie ci idu alebo nejdu do garaze a do ktorej. Ide o to najst riesenie aby ten pozorovatel to odhadnute nevedel. Rieseni je kopa od spomalenia vsetkych, znáhodnenie hustory, zhorsenie moznosti pokludneho pozorovania, cez zabranenie aby mohol do premavky vkladat svoje auta, az po upravu vjazdu do garazi aby aj v pripade zavretej to nespomalilo premavku.
