Venom: závažná bezpečnostní chyba v QEMU, Xenu a KVM

Linux tohle samozřejmě umí taky (přes memory cgroups), a tam, kde to je potřeba, se to používá (a než nadhodíte problém s forkem před exec: každý normální program používá vfork). Třeba u té virtualizace. Většinou je to ale: why bother. Kdo by se s tím doma nastavoval. A bez nastavení funguje OOM killer o dost lépe. Např. lze restartovat počítač, když došla paměť, i jinak než hard resetem.

Ad každý normální program používá vfork:
1. posix_spawn byl na Linuxu léta jen wrapper pro fork-exec, což mi přijde vtipné.
2. vfork měl (má?) race condition, a navíc není (nebyl?) thread safe.
3. V době návrhu memory managementu kernelu jste měli jen ten fork-exec.
4. fork-exec není jediný problém. Například Firefox používá forkování, se všemi s tím spojenými problémy.

Jak už jsem mnohokrát psal, chování při OOM je na Linuxu příšerné. Solaris dlouhá léta podporuje posix_spawn, doporučuje jeho použití místo fork-exec, a nelže aplikacím o úspěšné alokaci paměti. Windows mají CreateProcess, a nelžou aplikacím o úspěšné alokaci paměti. AIX sice lže aplikacím o úspěšné alokaci paměti, ale má alespoň SIGDANGER, který procesům posílá, když to praskne a paměti se nedostává. Díky tomu aplikace mohou například zmenšit velikost bufferů apod. Jenom Linux slibuje aplikacím paměť kterou nemá, a pak pomocí OOM Killeru losuje a odstřeluje procesy bez možnosti situaci řešit nějak lépe.

Ad bez nastavení funguje OOM killer o dost lépe. Např. lze restartovat počítač, když došla paměť - to je důsledkem toho že na Linuxu máte jeden paměťový pool pro user mode aplikace i kernel, a nejspíš nemáte ani předalokované buffery, které by vám umožnily se s OOM vypořádat lépe.

Nevím, že by vfork měl race condition. vfork má jediné omezení: nesmíte v něm měnit nic jiného než stack.

V Linuxu se dá overcommit vypnout, pak to funguje úplně stejně jako v Solarisu, AIX nebo Windows. Dostanete ale ty samé problémy :-)

Jak lépe to chcete řešit bez toho, že strávíte týden nastavováním paměťových politik (což se samozřejmě u velkých serverů dělá či alespoň dělat mělo)? Jako ve Windows, kde se systém raději uswapuje, než aby udělal cokoliv, aby se dostal do alespoň částečně použitelného stavu?

V Linuxu můžete mít tolik poolů, kolik chcete, jmenuje se to memory cgroups, odhlašování se potom řeší přes D-Bus, takže pro to váš současný pool nepotřebuje vůbec žádnou paměť. Tu situaci, kdy nejde restartovat počítač, protože došla paměť, znám jen z Windows.

Ad Nevím, že by vfork měl race condition: if the child process calls an external function (such as exec()), the dynamic linker may be invoked to resolve the Procedure Linkage Table (PLT) entry, for which the dynamic linker will acquire a mutex lock. This lock may already be held by a different thread in the parent process. If this happens it will create a deadlock between the parent and child processes, because no thread in the parent can run until the child has called exec() or exit(). As a result, both the parent and the child processes will hang.
http://www.oracle.com/technetwork/server-storage/solaris10/subprocess-136439.html

https://sourceware.org/bugzilla/show_bug.cgi?id=14749
https://sourceware.org/bugzilla/show_bug.cgi?id=14750

Ad V Linuxu se dá overcommit vypnout, pak to funguje úplně stejně jako v Solarisu, AIX nebo Windows. Dostanete ale ty samé problémy - jenže pokud používáte fork-exec, tak rychle skončíte na OOM. Na Solarisu se používá system(), ve Windows CreateProcess(), a ani jedno z těch API nemá problém.

Ad ve Windows, kde se systém raději uswapuje, než aby udělal cokoliv, aby se dostal do alespoň částečně použitelného stavu - to že stroj swapuje znamená ztrátu výkonu, nic více a nic méně. I pokud by přihlášení trvalo moc dlouho, pořád budete schopný proces odstřelit vzdáleně.

Ad V Linuxu můžete mít tolik poolů, kolik chcete - to ovšem neodděluje pool kernelu a aplikací, ani to neprovede předalokaci bufferů potřebných pro uvolnění paměti. Na Unixech je bohužel běžné, že když paměť dojde, tak například přestane fungovat FS a networking.

Ještě ad má jediné omezení: nesmíte v něm měnit nic jiného než stack - toho je bohužel dost obtížné docílit, zvlášť ve vyšších jazycích.

...Windows na certifikovaném stroji s certifikovanými drivery problémy s uspáváním opravdu nemají. Pokud se nějaký problém vyskytne, většinou je to věc third-party driveru

nekrm mě doublethinkem, já takovej stroj mam, občas se nechce uspat, takže když ho šoupnu do batohu, tak se naštěstí hw sám natvrdo vypne

k OOM se nebudu dál vyjadřovat, nedostatek paměti sem viděl jen na widlích a to v jedný z největších korporací na světě, která bohužel nemá na to zaplatit si kvalitní administrátory widlí, takže to tam řeší restartem

Ad já takovej stroj mam, občas se nechce uspat - third party driver, BIOS.

Ad nedostatek paměti sem viděl jen na widlích - zato já jsem viděl na Linuxu OOM Killer v akci naposledy minulý týden. Zřejmě nějaký memory leak u Apache. Naštěstí tohle nemusím řešit já.

Ad bohužel nemá na to zaplatit si kvalitní administrátory widlí - možná utratili moc peněz za unixové stroje nebo za linuxové adminy ;)

third party driver - ne, už sem psal že to mam všechno certifikovaný

BIOS - ne, nějakej čas sem problém neměl, pak najednou jo, všechny updaty šly skrz win update, zajímavý

Zřejmě nějaký memory leak u Apache - skončilo to něčim co můžeš linkovat? nebo je to tvoje klasický troubení?

možná utratili moc peněz za unixové stroje nebo za linuxové adminy - pravděpodobněji utratili všechny prachy za m$ sw, takže nezbylo vůbec na nic, prostě tradiční uvažování managerů který znaj jen widle