Vlákno názorů k článku Jak se zranitelnosti Spectre a Meltdown projevily v českých datacentrech? od PavelM - To byl fake. Žádný útok se nekonal, někdo...

To byl fake. Žádný útok se nekonal, někdo se chtěl přiživit na těch jménech ala Bondovky.

> A to ještě někdo používá?

Asi byste se divil kdo vsechno :)

> o se snad týká jen paravirtualizace, ne?

Sitauce u Xenu je trochu slozitejsi, to neni tak jednoduchy svet jako KVM :)

Viz https://xenbits.xen.org/xsa/advisory-254.html

A to ještě někdo používá? ;-)

Ale teď vážně: to se snad týká jen paravirtualizace, ne? A jak by proti tomu mohlo pomoct PTI na kernelu v dom0? (Z článku: "Z tohoto důvodu jsme do infrastruktury nasadili patche implementující KPTI.")

Uznávám, že samotný holý výrok "Meltdown [...] nelze použít k útoku z VM na hypervisor" není formulován šťastně a v případě paravirtualizace neplatí. Nicméně tak, jak to bylo myšleno, tedy v plném kontextu "nasazení (k)PTI k ochraně hypervisoru před Meltdown z VM je zbytečné" to stále platí. Tedy aspoň prozatím, možná se objeví nějaké další zranitelnosti, ale ty budou stejně dost pravděpodobně vyžadovat další patche. Nebo máte ještě jiný příklad?

Díky za debatu!

Xen.

Tak nové útoky na sebe nedaly dlouho čekat: https://skyfallattack.com/

To je hodně dobrá otázka :-)

Docela by mě zajímalo, který hypervisor (v kombinaci s ovladači ve virtualizovaném OS, předpokládám) mapuje něco zajímavého (a co) do adresního prostoru aplikací běžících ve VM. Velmi rád se v tomhle nechám opravit, přiznávám, že tuto variantu jsem nezkoumal a spokojil se s vyjádřeními, že se to neděje.

> nelze použít k útoku z VM na hypervisor nebo na jiné VM

A ze to plati obecne nezavisle na hypervisoru si myslite z jakeho duvodu?

Ano zjednodušil jsem to. A protože ty modernější architektury mají lepší IPC nejen kvůli vylepšené predikci, budou zřejmě v absolutních číslech pořád rychlejší. A předpokládám, že se objeví i další levnější způsoby obcházení problému, ale bohužel taky i další možnosti útoku.

Zkuste si o tom něco přečíst vy, přehledně třeba na: https://github.com/speed47/spectre-meltdown-checker

Je smutné vidět kolik nesmyslů a polopravd se okolo tohoto problému šíří.

On CPUman není úplně mimo. Bez ohledu na to, zda a kdy vydá Intel nový mikrokód pro Sandy a Ivy Bridge, na těchto dvou mikroarchitekturách budou pravděpodobně díky jednodušším branch prediktorům celkem spolehlivě fungovat retpolines. A ty nový mikrokód nepotřebují a s velkou pravděpodobností budou na těchto mikroarchitekturách výrazně rychlejší než vylévání branch target bufferu a zakazování predikce indirect branchingu (což je to, co přidává nový mikrokód).

Tvrzení, že pocítí dopady méně než modernější mikroarchitektury, je ale přehnaně silné. Na Skylake jsou sice retpolines trochu oříšek, ale zatím nic nenasvědčuje tomu, že neřešitelný. Navíc díky odlišnému návrhu procesoru jsou tam zmiňované obezličky v hardware levnější. Takže přestože je teoreticky možné, že procentuální dopad na výkon bude na Sandy Bridge o pár procentních bodů menší než u Skylake, v absolutních číslech se to moc neprojeví.

Bude, zkuste si o tom něco přečíst.

Ne, nestačí.

Ano Sandy a Ivy mít mikrokód nebude, protože stačí záplaty v SW, které berou míň výkonu než mikrokód a záplata v SW pro novější CPU, které doplácí na to, že mají speculative execution zase o něco "lepší".

Co je starší? Intel 2nd gen Sandy Bridge mít bude.

Jistě že pocítí, protože budou trvale nebezpečné :-)

S tím výkonem je to pravda. A paradoxní je, že starší procesory, které nebudou mít update mikrokódu pocítí menší snížení výkonu, než ty moderní s mikrokódem.

Stále ještě nerozumím tomu, proč tento update vyžaduje jiný přístup než jiné záplaty na local root exploity (v případě update jádra OS) a než jiné záplaty na VM escape (v případě update hypervisoru). Mám jisté pochybnosti o tom, že podobné tanečky provádíte u každého update kernelu a qemu/Hyper-V/VMware. Přitom z pohledu uživatele je to totéž. Dokonce pravděpodobnost útoku je zde menší než u jiných exploitů z posledních let.

Nebo je to kvůli mediální bublině okolo? Ale ta je spíš způsobená tím, že jde o technicky velice zajímavou novou třídu problémů. Dopad na zákazníka není větší než u "klasických" bezpečnostních problémů.

Update probíhá automatizovaně, individuálně s klienty řešíme čas rebooty serveru, protože u některých klientů restart serverů způsobí výpadek. Po restartu kontrolujeme stav všech služeb. Tato "drobná práce" násobená tisíci generuje velké množství práce. Ano, můžeme to řešit jako jiné firmy - říkat, že uděláme minor update a tím je to vyřešené (= reálně se to neřeší), a nebo to prostě hromadně všechno porestartovávat a nezájem. Nicméně my známe naše klienty, víme, že jim na serverech běží produkční systémy, a proto s nimi restart serveru koordinujeme tak, aby jim to nezpůsobilo žádný problém.

Díky za zajímavý vhled do toho, jak fungují česká datacentra.

"Tyto zranitelnosti jsou obecně významným problémem pro virtualizovanou infrastrukturu. [...] Z tohoto důvodu jsme do infrastruktury nasadili patche implementující KPTI."

No teda. Chápu, že technické podrobnosti těchto zranitelností většině lidí unikají. Nicméně od provozovatelů datacenter bych očekával, že si nastudují alespoň základy. Mít virtualizovanou infrastrukturu a "chránit" se tím, že nasadí PTI, tedy fix na Meltdown, který nelze použít k útoku z VM na hypervisor nebo na jiné VM, nezní zrovna profesionálně.

Co se týče několikrát zmíněného dopadu na výkon - pokud mají nasazeno jen PTI, tak není divu, že dopad na výkon nepozorují. Ta pravá legrace nastane, až nasadí opravy na Spectre variant 2, která se jich týká nejvíc. Teda, pokud se Intel uráčí vydat updaty mikrokódu. které fungují. Ale je dobře, že alespoň část datacenter s nutností nového hardware počítá a dopad na výkon na svých strojích sleduje.

A VSHosting, který podle článku aktualizuje "tisíce serverů ručně", to je taky něco.