Zapisywanie do wykonania obrazu procesu na Linuksie

Question

Co się stanie, jeśli proces B zapisuje (z typową syscall zapisu) pewne dane do obrazu procesu A, podczas gdy ten drugi jest wykonywany? Czy nie spowoduje to korupcji tego, co proces A wykonuje?

Jestem nowy w Linuksie. O ile rozumiem, firma Unix historycznie nie narzuca obowiązkowych blokad plików (tak jak robi to Windows). Więc pisanie jest całkiem możliwe.

Przeszukałem Internet bez rezultatu. Kiedy zadaję to pytanie moim doświadczonym współpracownikom Linuksa, wszyscy oni odpowiadają, że proces A ma swój obraz całkowicie w pamięci.

Niemniej jednak z tego co przeczytałem, jądro może z łatwością zamienić niektóre strony z powrotem na plik obrazu z pamięci, na przykład, gdy warunki niskiej pamięci są zestresowane. Tak więc, podczas gdy na dysku, niektóre strony mogą zostać uszkodzone przez inny proces zapisu; następnie mogą zostać ponownie zamienione na RAM i wykonane.

Answer 1

Czy myślisz o zapisaniu procesu w jakimś /proc/1234/mem innego procesu pid_t 1234?

A może myślisz o zapisaniu procesu w pliku wykonywalnym ELF innego procesu?

Oba scenariusze są bardzo rzadkie i specyficzne dla systemu Linux (inne Posix nie mają tych), więc nie wiem, co może się stać w takim przypadku. Ale przynajmniej mechanizm zezwoleń powinien chronić niektórych.

Zobacz także błąd ETXTBSY.

W praktyce (jak pokazano przez strace -f /usr/bin/gcc hello.c -o hello) kompilator i linker wyjmujesz wykonywalny przed open -ing go do pisania wykonywalny, więc większość kompilacja nigdy napisać do starego pliku wykonywalnego:

870 stat("hello", {st_mode=S_IFREG|0755, st_size=6096, ...}) = 0 
870 unlink("hello")     = 0 
870 open("hello", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0777) = 17 
870 fstat(17, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 

Więc napisz do pliku wykonywalnego, musisz bardzo się postarać. Oczywiście, kiedy to zrobisz, może dojść do niegrzecznych wypadków.

Answer 2

Co przeczytałeś sugerując, że strony mogą zostać zamienione "z powrotem do pliku obrazu"?

Jeśli system ma mało pamięci, strony zostaną zamienione na partycję wymiany na dysku, która różni się od pliku wykonywalnego. Zapis do pliku wykonywalnego nie przyniesie efektu, dopóki następnym razem nie uruchomisz pliku.

Jeśli, w jakiś sposób, udało ci się zapisać na dokładnej stronie pliku wymiany (co byłoby trudne, ponieważ musiałbyś dokładnie wiedzieć, gdzie i kiedy dane zostały zapisane na dysku). Jeśli to zrobiłeś, możesz zmodyfikować kod obiektowy. Czy sugerujesz uszkodzenie pliku wykonywalnego lub jakiś sprytny sposób na zmianę programu podczas jego działania?

Answer 3

W rzeczywistości nie ma konieczności "niskiego poziomu pamięci" dla stron do zamiany. Linux i tak ładuje pliki wykonywalne "na żądanie", więc strona jest ładowana tylko wtedy, gdy jest wymagana.

Ale zobacz moją odpowiedź do poprzedniego jeden What happens when you overwrite a memory-mapped executable?