Le développement / test d'un module Linux est-il sûr en utilisant une machine virtuelle?

18

Je suis dans une classe de systèmes d'exploitation. À venir, nous devons faire un travail de modification du code du noyau. Il nous a été conseillé de ne pas utiliser de machines personnelles pour tester (je suppose que cela signifie l'installer) car nous pourrions écrire du mauvais code et écraser quelque part où nous ne devrions pas. On nous donne accès à une machine dans un laboratoire pour être en sécurité.

Si je devais tester à l'aide d'une machine virtuelle, cela protégerait-il le système hôte d'un code potentiellement dangereux? Je veux vraiment ne pas avoir à rester collé à un système à l'école et les instantanés seront utiles.

Si le risque est toujours élevé, avez-vous des suggestions sur ce que je dois considérer pour tester en toute sécurité?

Nous allons utiliser quelque chose comme linuxmint pour commencer. Si quelqu'un veut voir ce qu'il y aura dans le projet actuel: http://www.cs.fsu.edu/~cop4610t/assignments/project2/writeup/specification.pdf

linux kernel-modules virtual-machine

— entimaniac
source

Honnêtement, ce n'est pas vraiment un risque de le faire sur du vrai matériel, surtout si vous faites des sauvegardes. Je l'ai fait, et je suis sûr que de nombreux autres développeurs l'ont également fait.

— Hobbs

@hobbs C'est parce que beaucoup d'entre nous aiment vivre dangereusement, généralement assez longtemps pour le regretter. Travailler sur votre machine réelle est très bien si vous êtes un développeur prudent travaillant sur des modules plutôt petits. Pour les développements plus importants (ou les développeurs négligents) , il est probablement préférable de travailler sur un environnement isolé. Ce pourrait aussi être une bonne idée de travailler sur une "distribution propre", pour vous assurer qu'aucune personnalisation au niveau du noyau ne puisse interférer avec votre module. Gardez à l'esprit que le développement du module du noyau est l'endroit où la plus petite erreur peut avoir les conséquences les plus terribles: D

— John WH Smith

28

Les principaux risques liés au développement de modules du noyau sont que vous pouvez planter votre système beaucoup plus facilement qu'avec du code normal, et vous constaterez probablement que vous créez parfois des modules qui ne peuvent pas être déchargés, ce qui signifie que vous devrez redémarrer pour recharger les après avoir corrigé ce qui ne va pas.

Oui, une machine virtuelle convient à ce type de développement et c'est ce que j'utilise lorsque je travaille sur des modules du noyau. La machine virtuelle isole parfaitement votre environnement de test de votre système en cours d'exécution.

Si vous souhaitez prendre et restaurer des instantanés, vous devez conserver votre code source archivé dans un référentiel de contrôle de version en dehors de la machine virtuelle afin de ne pas perdre accidentellement votre dernier code lorsque vous supprimez l'état actuel de la machine virtuelle.

3

Ou il peut être possible de ne prendre en photo que certains aspects de la machine virtuelle. Garder le code source sur un disque virtuel séparé, par exemple. Bien sûr, un référentiel de code source hors VM dans lequel vous archivez régulièrement du code est de toute façon une bonne idée; il peut vous éviter de nombreuses erreurs embarrassantes et enseigne les bonnes pratiques de codage.

— un CVn du

L'autre côté de planter votre système plus facilement est que lorsque vous plantez votre système, vous avez plus de chances de provoquer une corruption des garanties.

— user253751

14

En supposant que vous n'essayez pas d'écrire un pilote pour du matériel réel, c'est un excellent moyen de travailler sur des modules. Vous pouvez prendre un instantané du système de travail, et si vous faites exploser quelque chose, revenez simplement à l'instantané.

Si vous le pouvez, faites une copie complète de la machine virtuelle, juste au cas où le système de cliché serait plus étrange que je ne le pense. :)

— Hack Saw
source