Чи безпечна розробка / тестування модуля linux за допомогою віртуальної машини?

18

Я в класі операційних систем. Підійшовши, нам доведеться виконати деяку роботу над зміною коду ядра. Нам рекомендували не використовувати особисті машини для тестування (я думаю, це означає встановити його), оскільки ми можемо написати поганий код і написати там, де нам не слід. Нам надають доступ до машини в лабораторії, щоб бути в безпеці.

Якби я тестував за допомогою VM, чи захистив би він хост-систему від потенційно небезпечного коду? Мені дуже хочеться, щоб у школі не дотримувалися системи, і знімки будуть корисні.

Якщо це все ще високий ризик, якісь пропозиції щодо того, що мені потрібно врахувати, щоб перевірити безпечно?

Для початку ми будемо використовувати щось на зразок linuxmint. Якщо хтось хоче побачити, що буде у поточному проекті: http://www.cs.fsu.edu/~cop4610t/assignments/project2/writeup/specification.pdf

linux kernel-modules virtual-machine

— ворожий
джерело

Чесно кажучи, не так багато ризику зробити це на реальному обладнання, особливо якщо ви робите резервні копії. Я маю, і я впевнений, що багато інших чортів також є.

— варення

@hobbs Це тому, що багато хто з нас любить небезпечно жити, як правило, досить довго, щоб шкодувати про це. Робота над вашою фактичною машиною прекрасна, якщо ви ретельний розробник, який працює над досить маленькими модулями. Для великих розробок (або необережних розробників) , мабуть, найкраще працювати в ізольованому середовищі. Також може бути хорошою ідеєю працювати над "чистим розподілом", щоб переконатися, що жодна настройка рівня ядра не може впливати на ваш модуль. Майте на увазі, що розробка модуля ядра - це найменша помилка, яка може мати найстрашніші наслідки: D

— Джон У. Сміт

28

Основні ризики, що розробляють модулі ядра, полягають у тому, що ви можете зламати систему набагато простіше, ніж за допомогою звичайного коду, і ви, ймовірно, виявите, що іноді створюєте модулі, які неможливо вивантажити, що означає, що вам доведеться перезавантажуватися, щоб повторно завантажити їх після того, як ви виправите те, що не так.

Так, VM чудово підходить для такого роду розробок, і саме це я використовую, коли працюю над модулями ядра. VM добре ізолює ваше тестове середовище від вашої запущеної системи.

Якщо ви збираєтеся робити та відновлювати знімки, вам слід тримати свій вихідний код у сховищі контролю версій поза VM, щоб випадково не втратити останній код, коли ви відкинете поточний стан VM.

3

Або можливо зробити знімок лише певних аспектів відеомережі. Наприклад, зберігання вихідного коду на окремому віртуальному диску. Звичайно, непогашене сховище вихідного коду VM, до якого ви регулярно перевіряєте код, - в будь-якому разі є хорошою ідеєю; це може врятувати вас від багатьох невтішних помилок, і це вчить гарній практиці кодування.

— CVn

Інша сторона легшого збою вашої системи полягає в тому, що, коли ви збиваєте свою систему, у вас є більший шанс викликати побічну корупцію.

— користувач253751

14

Якщо припустити, що ви не намагаєтеся написати драйвер для фактичного обладнання, це чудовий спосіб роботи над модулями. Ви можете зробити знімок робочої системи, і якщо ви щось підірвете, просто поверніться до знімка.

Якщо можете, зробіть повний дублікат VM, на всякий випадок, якщо система знімків є більш дивною, ніж я думаю. :)

— Hack Saw
джерело