Безопасна ли разработка / тестирование модуля linux с использованием виртуальной машины?


18

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

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

Если это все еще высокий риск, какие-либо предложения о том, что мне нужно рассмотреть, чтобы безопасно проверить?

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


Честно говоря, делать это на реальном оборудовании не так уж и рискованно, особенно если вы делаете резервные копии. У меня есть, и я уверен, что многие другие разработчики тоже.
Хоббс

@hobbs Это потому, что многим из нас нравится жить в опасности, обычно достаточно долго, чтобы сожалеть об этом. Работать на своей реальной машине хорошо, если вы осторожный разработчик, работающий над довольно маленькими модулями. Для более крупных разработок (или неосторожных разработчиков) , вероятно, лучше всего работать в изолированной среде. Также было бы неплохо поработать над «чистым дистрибутивом», чтобы убедиться, что никакие настройки на уровне ядра не могут помешать вашему модулю. Имейте в виду, что разработка модулей ядра - это то, где самая маленькая ошибка может иметь самые ужасные последствия: D
Джон У. Смит,

Ответы:


28

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

Да, ВМ отлично подходит для такого рода разработки, и это то, что я использую, когда работаю над модулями ядра. ВМ прекрасно изолирует вашу тестовую среду от работающей системы.

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


3
Или может быть возможно сделать снимок только определенных аспектов VM. Хранение исходного кода на отдельном виртуальном диске, например. Конечно, хранилище исходного кода вне ВМ, в которое вы регулярно проверяете код, в любом случае является хорошей идеей; это может спасти вас от многих смущающих ошибок и учит хорошей практике кодирования.
CVN

Другая сторона более простого сбоя вашей системы заключается в том, что когда вы ее рушите, у вас больше шансов вызвать побочное повреждение.
user253751

14

Предполагая, что вы не пытаетесь написать драйвер для реального оборудования, это отличный способ работы с модулями. Вы можете сделать снимок работающей системы, и если вы что-то взорвете, просто вернитесь к снимку.

Если вы можете, сделайте полную копию виртуальной машины, на случай, если система снимков будет более странной, чем я думаю. :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.