Linux 4.6 (diskuse)

[little.owl]

A showmani z grsecurity se ihned opreli do jeho bezpecnosti:The Truth about Linux 4.6.

[trekker.dk]

Kecy jsou zadarmo, co takhle kdyby poslali kód k začlenění?

[Petr Tomášek]

A nevydělávají oni na tom grsecurity čistě náhodou?

[Jendа]

Vydělávají, ale patche pro aktuální kernely jsou normálně dostupné.

[Aleš Kapica]

Já bych řekl, že zajímavou informací pro ty co používají overlay systému je, že od verze 4.6-rc3 konečně funguje překrytí pomocí modulu "overlay" i nad vzdáleným adresářem přimountovaným přes NFS.

[Jardík]

Já bych byl rád za nějaký nový syscall na vytvoření nového procesu, tak aby se nemusel dělat snapshot ala fork(). I když je to copy-on-write, tak to při vypnutém overcommitu selže, když vaše aplikace "žere hodně", protože testuje, jestli máte to samé volné.

[joshua]

vfork() ?

[Pavel Píša]

Případně posix_spawn()

http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html

[VSi]

Zrovna nedávno jsem tenhle problém řešil. U posix_spawn() jsem ale narazil na to, že pokud člověk potřebuje propojit stdin/stdout, lze na to využít posix_spawn_file_actions_t *file_actions, ale v tu chvíli se už interně efektivní přístup přes vfork+execve nepoužije (záleží na implementaci v libc, testováno na Debianu) a při vypnutém overcommitu a "málo" paměti to selže. Přitom ruční volání vfork+dup2+close+execve použít lze.

[Jardík]

Problém s vforkem je ten, že po něm můžu tak akorát zavolat něco z exec rodiny a nic jiného. Přesměrování vstupu, výstupu, nebo obecně dupnutí deskriptoru, který chci přenechat potomkovi, tak je nemožné. Co se posix_spawn týče, tak o něm vím, bohužel je to wrapper nad forkem.

[Jardík]

A aby toho nebylo málo, tak v POSIX.1-2008 už není.

[VSi]

Přesměrování stdin/out/err možné je, mám to otestované. Zavolá se vfork, pak dup2 a close na deskriptorech, a nekonec execve.

[Jardík]

Když opomenu, že nesmíte po vfork volat nic kromě execve či _exit, nebo modifikovat jinou proměnnou než pid_t, tak bych se bál, jestli neleakuje to deskriptor zpátky do parenta.

[Michal Kubeček]

Rozumím dobře, že "mám to otestované" znamená "zkusil jsem to a měl jsem štěstí (nebo smůlu, podle úhlu pohledu), že jsem nenarazil na viditelné problémy"?

[VSi]

Je to nasazeno v jednom projektu, problémy ve srovnání s předchozím řešením se standardním fork+exec se neprojevily. Je možné že shodou okolností / specifičností případu / nedostatečným testováním.

Pokud to nefunguje nebo nemusí vždy fungovat, rád si nechám poradit, jak to udělat jinak a správně. Nebo v POSIXu/Linuxu neexistuje cesta, jak vytvořit nový proces a připojit se na jeho stdin/stdout, pokud není k dispozici alespoň dvojnásobek paměti než kolik potřebuje hlavní program (bez zapnutí memory overcommit v kernelu)?

[Michal Kubeček]

Manuálová stránka k vfork() to IMHO říká dost jednoznačně:

the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit(2) or one of the exec(3) family of functions

Navíc celkově ta manuálová stránka dost jasně dává najevo, že vfork() jako takový je spíš historická slepá ulička, které je dnes lépe se vyhnout.

jak vytvořit nový proces a připojit se na jeho stdin/stdout, pokud není k dispozici alespoň dvojnásobek paměti než kolik potřebuje hlavní program (bez zapnutí memory overcommit v kernelu)?

Za prvé: termínem "zapnutí" ve skutečnosti asi myslíte "nevypnutí". Za druhé: ta otázka mi přijde asi tak smysluplná, jako byste se ptal, jak co nejrychleji a nejpohodlněji běžet, pokud si svážete nohy v kolenou. Pokud byste to potřeboval jako teoretické cvičení nebo pro nějaký specifický corner case, možná by toho šlo docílit vhodnou kombinací flagů pro clone().

[Pavel Píša]

Pokud se jedná o Linux only řešení nebo může být přidaná alternativní cesta pro Linux, tak lze použít volání clone(), v něm lze například nastavit, že se má použít nový "prostor" otevřených I/O deskriptorů, pokud se nenastaví CLONE_IO tak nebudou deskriptory sdílené.

Pokud bude nastavené CLONE_VM a CLONE_VFORK a nebude nastavené CLONE_IO, tak by mělo jít požadované řešení pro spuštění child procesu s minimem vyplýtvaných prostředků vyřešit. Problém je, že clone() je nízkoúrovňové volání a je potřeba ověřit, co všechno dalšího je potřeba udělat, aby byl výsledek z pohledu libc, zavírání deskriptorů a dalších pravidel, na která můžete spoléhat v pořádku.

Před časem jsem si dost podrobně GLIBC posix_spawn prohlížel a zdálo se mi celkem dobře implementované. Zdrojový kód je zde

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c

P5itom posix_spawn_file_actions_t *file_actions vybadají i když se na to dívám teď, plně vyřešené v __spawnix a není důvod, aby se při jejich použití přešlo na fork(). Alespoň v současné implementaci.

Ale jak se dívám do logu, tak podstatnému přepsání došlo v lednu tohoto roku (2016), takže je možné, že předchozí implementace na fork() přecházela.

[VSi]

Super, díky za konstruktivní informace. V našem případě to bylo testováno na distribuční glibc ještě na Debianu Wheezy, a tam použití file_actions vedlo na fork(), jinak se použit vfork(). Hledal jsem tehdy řešení poměrně dlouho, a ten kód s vfork() použitým "unspecified" způsobem, bylo jedniné řešení. clone() jsem neznal, ale korektně bych to dával dohromady pěkně dlouho... Docela mě překvapuje, že podobná věc se dostává do glibc v roce 2016. Podle množství dotazů a diskusí co jsem tehdy našel nejsem zdaleka sám, kdo s tím měl problém. Krom toho, že fork() je zbytečná režie navíc (jde o aplikaci v realtime oblasti), tak případně řešení přes povolení overcommit-u má někdy nepříjemné vedlejší důsledky.

[Jardík]

Taky díky. Já posix_spawn ani nikdy nezkoušel. Přečetl jsem si, že je to wrapper nad forkem a tím to pro mě končilo. Teď vidím, že (už) není. Ještě kouknu do zdrojáku musl libc, jak to je tam.

[Pavel Píša]

MUSL implementuje posix_spawn od roku 2011 a od roku 2013 je postavený na CLONE.

Právě demonstrace zrychlení v MUSL byla argumentem pro přepsání implementace v GLIBC

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

Reportované je 25 zrychlení pro proces s mapovaným prostorem 40 MB bez hugepages.