Vlákno názorů ke zprávičce Intel Core má další zranitelnost Lazy FP State Restore od VLM - Tak dělit se snad už od pětivoltového Pentia...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 15. 6. 2018 9:46

    VLM (neregistrovaný)

    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.

  • 15. 6. 2018 10:31

    654 (neregistrovaný)

    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.

  • 15. 6. 2018 10:37

    Petr M (neregistrovaný)

    Ono samo o sobě je zhovadilost ukládat klíče do sdílených registrů kdekoliv (nejenom ve FPU).

    V tomhle je jednoznačně lepší AMD a jejich dedikovaný ARM jádro pro šifrování s oddělenou RAM a FLASH a připojením po PCIe. Jenom aby se to taky aktivně používalo v systému...

  • 15. 6. 2018 19:41

    pc2005 (neregistrovaný)

    Ano, pokud se tedy tomu dedikovanému šifrovacímu HW dá věřit, stíhá traffic a umožňuje update na novější šifrovací algoritmy, ale třeba meltdown ti může tajná data (třeba heslo) přečíst už v driveru klávesnice v kernelu.

  • 15. 6. 2018 18:20

    pc2005 (neregistrovaný)

    Ú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.

  • 15. 6. 2018 10:39

    Peter Fodrek
    Zlatý podporovatel

    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

  • 15. 6. 2018 11:38

    Peter Fodrek
    Zlatý podporovatel

    vcelku by ma zaujîmalo s 49m nesûhlasia..

    nebodaj strace ls a gcc sû sporné nástroje.

    Pokiaľ nesúhlsia s mojím výkladom merania.. tak v čom?

  • 15. 6. 2018 22:04

    Sid (neregistrovaný)

    To je nejaky opak auto korekcie co pouzivas?:-) ci v ramci testovania sa ti nahodne prepisala pamat?

  • 16. 6. 2018 8:18

    Peter Fodrek
    Zlatý podporovatel

    Nie len sa náhodne prelínajú locsles en_US, sk_SK a de_CH, a tá posledná robí problémy a nie vždy si to všimnem