Czy tworzenie / testowanie modułu Linux jest bezpieczne przy użyciu maszyny wirtualnej?

18

Jestem w klasie systemów operacyjnych. Zbliżając się, musimy popracować nad modyfikacją kodu jądra. Radzono nam, aby nie używać komputerów osobistych do testowania (przypuszczam, że to oznacza instalację), ponieważ moglibyśmy napisać zły kod i napisać w innym miejscu, w którym nie powinniśmy. Dla bezpieczeństwa mamy dostęp do maszyny w laboratorium.

Gdybym miał przetestować na maszynie wirtualnej, czy chroniłoby to system hosta przed potencjalnie niebezpiecznym kodem? Naprawdę nie chcę utknąć w systemie w szkole, a migawki będą przydatne.

Jeśli nadal istnieje wysokie ryzyko, jakieś sugestie dotyczące tego, co muszę rozważyć, aby przeprowadzić bezpieczny test?

Na początek będziemy używać czegoś takiego jak linuxmint. Jeśli ktoś chce zobaczyć, co będzie w bieżącym projekcie: http://www.cs.fsu.edu/~cop4610t/assignments/project2/writeup/specification.pdf

linux kernel-modules virtual-machine

— entimaniac
źródło

Szczerze mówiąc, nie jest to zbyt duże ryzyko na prawdziwym sprzęcie, szczególnie jeśli wykonujesz kopie zapasowe. Mam i jestem pewien, że wielu innych deweloperów też.

— hobbs

@ Hobbs To dlatego, że wielu z nas lubi żyć niebezpiecznie, zwykle wystarczająco długo, aby żałować. Praca na prawdziwej maszynie jest w porządku, jeśli jesteś ostrożnym programistą pracującym nad raczej małymi modułami. W przypadku większych projektów (lub nieostrożnych programistów) prawdopodobnie najlepiej jest pracować w odizolowanym środowisku. Dobrym pomysłem może być również praca nad „czystą dystrybucją”, aby upewnić się, że żadne dostosowanie na poziomie jądra nie będzie miało wpływu na moduł. Należy pamiętać, że rozwój modułu jądra jest miejscem, w którym najmniejszy błąd może mieć najokropniejsze konsekwencje: D

— John WH Smith

28

Główne zagrożenia związane z tworzeniem modułów jądra polegają na tym, że można znacznie łatwiej zawiesić system niż przy użyciu zwykłego kodu, i prawdopodobnie okaże się, że czasami tworzone są moduły, których nie można zwolnić, co oznacza, że konieczne będzie ponowne uruchomienie komputera w celu ponownego załadowania je po naprawieniu tego, co jest nie tak.

Tak, VM nadaje się do tego rodzaju prac rozwojowych i tego używam, gdy pracuję nad modułami jądra. Maszyna wirtualna ładnie izoluje środowisko testowe od działającego systemu.

Jeśli zamierzasz pobierać i przywracać migawki, powinieneś trzymać swój kod źródłowy w repozytorium kontroli wersji poza maszyną wirtualną, aby nie przypadkowo stracić najnowszego kodu po odrzuceniu bieżącego stanu maszyny wirtualnej.

3

Lub może być możliwe wykonanie migawki tylko niektórych aspektów maszyny wirtualnej. Na przykład przechowywanie kodu źródłowego na osobnym dysku wirtualnym. Oczywiście repozytorium kodu źródłowego spoza VM, do którego regularnie sprawdzasz kod, jest dobrym pomysłem; może uchronić cię przed wieloma kłopotliwymi błędami i uczy dobrej praktyki kodowania.

— CVn

Z drugiej strony łatwiejsze awarie systemu polegają na tym, że awaria systemu ma większą szansę na spowodowanie uszkodzenia zabezpieczenia.

— user253751

14

Zakładając, że nie próbujesz napisać sterownika dla rzeczywistego sprzętu, jest to świetny sposób na pracę z modułami. Możesz wykonać migawkę działającego systemu, a jeśli coś wysadzisz, po prostu wróć do migawki.

Jeśli możesz, zrób pełny duplikat maszyny wirtualnej, na wypadek, gdyby system migawkowy był dziwniejszy niż myślę. :)

— Brzeszczot
źródło