Thunderspy, zranitelnosti v Thunderboltu (diskuse)

[Blaazen]

Podobně to bylo s FireWire, ten měl taky přístup do paměti.

[lertimir]

Ano a na rozdíl od USB bylo velmi rychlé (což bylo v čase USB1) a nezatěžovalo procesor. A k ptoblému opravdu je tak složité aby nějaké zařízení mělo přístup pouze k nějaké určité části paměti i když má DMA? A mít jakýkoliv přístup jinde znemožněn?

[BFU]

Jo, protoze pak kdyz mas nejaky nahodny buffer s datama co chces poslat pres tu omezenou sbernici, tak se ti muze stat, ze nema spravny alignment nebo neni na spravne adrese a musi se kopirovat v RAM. Kdyz pak USB 3.x da 5,10,20 Gib/s, tak to kopirovani je problem.

Tohle se resi pomoci IOMMU, kde se da nastavit permissions pro ruzne pristupy z ruznych masteru na te sbernici (prave ze treba DMA muze pristupovat jenom na urcitou cast pameti). No, a pak tu jsou bugy v IOMMU ...

[Peter Golis]

A takto to potom dopadá.

[lertimir]

Jenže kopírování v RAM je pořád ještě mnohem rychlejší. Stařičká DDR3 1600 což beru jako už mnoho let jako etalon má tranfer rate 12800MB/s a DDR4 2400 má 19200MB/s, Tedy alespoň 5 krát více než 20Gb/s, navíc by to mohla být pamět s druhou sběrnící na DMA, takže by sse datové toky na hlavní sběrnici vůbec nemusely křížit. A bezpečnost by byla vyřešena.

[BFU]

Tech 12800 MiB/s je ovsem rychlost sbernice DRAMky (Drepper cpumemory.pdf Table 2.2 , 4. radek). DRAM samotna zvladne o dost mene kvuli ruznym prodlevam (Drepper sekce 2.2.2), a obzvlast pri kopirovani procesorem jich je dost, i kdyz cache a ruzne write buffery po ceste tomu docela pomahaji aby to nebylo tak zle.

Pri kopirovani procesorem se otevre radek pameti (prodleva), cely se natahne do cache (prefetch), otevre se jiny radek (prodleva), zapise se na jine misto, a tohle se opakuje. Ty predlevy se castecne kryji, ale ne uplne. DMA je to same, akorat nema cache ale nejaky interni buffer co se chova dost podobne.

No a podle toho co tam Drepper tvrdi, tak ve vysledku z tech 12.8 GiB/s bude tak 4 GiB/s, no a to uz k tem 20 Gib/s=2.5 GiB/s nema tak daleko.

DRAM ma jenom jednu sbernici, ze ma procesor nejakou network-on-chip (NOC) nepomuze, pokud bude DRAMka zadusena memcpy()ovanim.

[j]

Ve skutecnosti to ta Dram zvladne, ovsem za idealnich podminek. Uplne stejne jako libovolnej disk (vcetne SSD). Prakticky musi jit o linearni RW (a ma to jeste dalsi podminky - musis se trefit do cyklu...), stejne jako u tech disku. Proto ti realnej vykon meritelne ovlivni zmena casovani, cimz defakto primo ovlivnujes latenci, a naprosto nemeritelne zmena frekvence, coz ale spousta trotlu kteri o tom vedi kulovy nadokaze pochopit. Viz "kup si 4000+ ramky" a to nemluvim o tom, ze jim to stejne bez pretaktovani nepobezi ani na ty frekvenci.

Jinak ono to USB taky ani zdaleka neda ty hypoteticky parametry. Ve skutecnosti da v pomeru k nim mnohem min, nez cokoli jinyho. Realny parametry mel naposled snad ten zminenej firewire, zbytek jsou marketingovy krasozvasty. Je to uplne stejny, neli horsi, nez "gbit" po wifi. Coz se sice dosahnout da, ale rozhodne ne krabicema, ktery si bfucka kupujou.

[BFU]

memcpy() na velkych datech asi uplne idealni nebude, ze ?

[Ivan]

Presne tak, v pripade USB, se dalo zkopirovat dolnich v 4GB ram fyzicke pameti. Stacilo do USB vlozit spravne zarizeni. Pokud to BIOS nenastavil jinak, coz nekdy delal, jindy ne. Dneska uz ale Linux kernel na tohle nespoleha na nastavuje si to sam.

[rotujici banana]

Jak píše kolega nade mnou, tohle řeší IOMMU. Intel jeho použití nazývá "Kernel DMA Protection". Dál jenom hádám, ale nejspíš to znamená, že IOMMU je aktivní a to už od bootu/UEFI, aby zařízení nemělo zranitelné časové okno.

[Joska]

To je stary znamy problem se zarizenimi co maji DMA. To je ve vsech OS fixnuto snad uz 3-4 roky takze se zadna senzace nekona. Mac OS 10.12, Linux 5, Widle 10 vsjo opacovano.

[B]

Tyhle dementy, co musí pro každý bug tvořit webovou stránku, logo, youtube kanál a další hovadiny, by měli zavřít do nějakého léčebného ústavu.