Tak dělit se snad už od pětivoltového Pentia naučili a ty díry v Core jádrech byly o počátku ale před léty málo koho napadlo provádět nějaké šachy s předpovídáním a teprve až vešly útoky podobného stylu ve všeobecné povědomí se našlo dostatek hračičků kteří zkouší a hlavně pouští výsledky ven.
To jo, ale o nevyhnutelném průseru se ví aspoň od roku 2014, kdy začaly vyskakovat první útoky na cache CPU, na kterých zneužití Meltdown i Specter docela závisí. V popisu těchto útoků se většinou na konci píše něco jako "a pak už si jen z cache vytáhněte výsledek". Nijak to neřešili, protože samo o sobě to prý nepředstavovalo velké riziko, protože se to nedá moc dobře zacílit. Proč taky, to by sežralo výkon nebo zvýšilo cenu. Tyto 4 roky sezení na zadku jsou neomluvitelné, protože na zmírnění následků dnes aplikují stejná řešení, která od roku 2014 odmítali kvůli potenciálnímu snížení výkonu. Kdyby to řešili, byly by následky mnohem menší. Dokonce se zdá, že na nich začali pracovat až od zveřejnění Meltdown a Specter.
Výrobci CPU měli aspoň 3-4 roky, aby se na aspoň připravili na podobné útoky. Ty začaly už v roce 2014. Místo toho jen čekali, až to konečně praskne a vymlouvají se, že se to nedalo předpokládat, ale mohlo a mělo.
Jinak už z popisu Lazy FP State Restore musí být všem jasné, že takové ušetření výkonu nemůže zvýšit bezpečnost. Ta může buď zůstat stejná, nebo se snížit. První varianta platí jen v případě dokonalého provedení bezchybnými lidmi. Takhle je to u všech podobných fíčur. Například zneužití přidaných funkcí mimo šifrovanou část v PGP klientech a podobné, pohodlí zvyšující kraviny.
Únik dat ze sdílené cache mezi vlákny hyperthreadingu byl poprvé zmíněn už s první hyperthreadingem, tedy někde okolo lehce po roce 2000. Novější (ve smyslu 90. let) vydání bible architektur (Computer Architecture: A Quantitative Approach) se o nutnosti řešení útoku postranním časovým kanálem taky prý zmiňuje.
Tieto predpovedacie veci sa riešili viac menej v realtime komunite.
Lebo ak niečo trvalo 2 mikrosekundy +/-636 nanosekúnd, nebolo práve deterministické
A prišlo sa na prediktopry.
Potom sa hlavne v Drážďanoch pohvrhávali dáta do cache, a na overenie, či ta tie dáta sú sa museli použiť vedľajší kanál.
A Vojtěch Pavlík mal veľmi dobrú prednášku, ale jedna vec je taqm len tak mimochodom - púredikcia je len na posledných 20 bitoch logickej adresy
https://www.youtube.com/watch?v=rwbs-PN0Vpw&feature=youtu.be
a to keď si spojéme s veľkosťou staticky lionkovanej binárky
more hello.c
#include<stdio.h>
int main(int argc, char **argv)
{
printf("Ahoj svet\n");
return(0);
}
gcc hello.c -o hello.bin
gcc hello.c --static -o helloS.bin
ls -la
celkom 4720
drwxr-xr-x 2 fodrek users 4096 jún 15 10:17 .
drwxr-xr-x 97 fodrek users 4096 jún 15 10:14 ..
-rwxr-xr-x 1 fodrek users 16768 jún 15 10:17 hello.bin
-rw-r--r-- 1 fodrek users 97 jún 15 10:17 hello.c
-rwxr-xr-x 1 fodrek users 4798216 jún 15 10:17 helloS.bin
fodrek@FODREKMlPC-SUSE:~/hello.world> ls -lah
celkom 4,7M
drwxr-xr-x 2 fodrek users 4,0K jún 15 10:17 .
drwxr-xr-x 97 fodrek users 4,0K jún 15 10:14 ..
-rwxr-xr-x 1 fodrek users 17K jún 15 10:17 hello.bin
-rw-r--r-- 1 fodrek users 97 jún 15 10:17 hello.c
-rwxr-xr-x 1 fodrek users 4,6M jún 15 10:17 helloS.bin
a k tomu
2^10=1024
a dolných
2^20=1024*1024..
4798216/1024/1024= cca, 4.58
A keďže používame spodných 20 bit v prediktore, tak samotný Hello World svojím behom ovplyvňuje ďalšie 3-4 úseky svojho kódu, ktoré majú rovnakých spodných 20 bitov logickej adresy. Teda ide o akúsi autootravu prediktora. proseom sebe samḿu..
a okrem toho sû tam syscally, ktorých počet som porovnával študentom vocči poičtu krokov súčtu vetorov v openCL,, kde bolo, tuším, 29krokov v loaderi, teray mám výspis y ioného PC(nikde inde nepoužívam stderr to rúry. tak sa mi to ncehcelo hľadať a používam obchádzku--)
strace ./hello.bin 2>error.txt; cat error.txt|wc -l
Ahoj svet
27
strace ./helloS.bin 2>error.txt; cat error.txt|wc -l
Ahoj svet
12