N'essayez pas ca a la maison! Cela peut planter votre système et si vous n'avez vraiment pas de chance, cela pourrait endommager un périphérique ou rendre votre ordinateur non amorçable.
En fait, sur la plupart des plates-formes, il échoue simplement avec une erreur, mais cela dépend de l'architecture matérielle. Il n'y a certainement aucune garantie que cela est inoffensif, sauf si vous exécutez la commande en tant qu'utilisateur non privilégié. Avec un utilisateur non privilégié, la commande est parfaitement inoffensive car vous ne pouvez pas l'ouvrir /dev/mem.
Lorsque vous exécutez une commande en tant que root, vous êtes censé savoir ce que vous faites. Le noyau vous empêchera parfois de faire quelque chose de dangereux, mais pas toujours. /dev/memest l'une de ces choses potentiellement dangereuses où vous êtes vraiment censé savoir ce que vous faites.
Je vais vous expliquer comment fonctionne une écriture /dev/memsur Linux. Le principe général serait le même sur d'autres Unices, mais des choses comme les options du noyau sont complètement différentes.
Que se passe-t-il lorsqu'un processus lit ou écrit dans un fichier de périphérique dépend du noyau. Un accès à un fichier de périphérique exécute du code dans le pilote qui gère ce fichier de périphérique. Par exemple, écrire pour /dev/memappeler la fonction write_memdansdrivers/char/mem.c . Cette fonction prend 4 arguments: une structure de données qui représente le fichier ouvert, un pointeur sur les données à écrire, le nombre d'octets à écrire et la position actuelle dans le fichier.
Notez que vous n'irez jusque-là que si l'appelant était autorisé à ouvrir le fichier en premier lieu. Les fichiers de périphérique obéissent normalement aux autorisations de fichier. Les autorisations normales de /dev/memsont crw-r-----détenues par root:kmem, donc si vous essayez de l'ouvrir pour l'écriture sans être root, vous obtiendrez simplement «permission refusée» (EACCESS). Mais si vous êtes root (ou si root a changé les permissions de ce fichier), l'ouverture passe et vous pouvez alors tenter une écriture.
Le code de la write_memfonction fait quelques vérifications d'intégrité, mais ces vérifications ne suffisent pas pour se protéger contre tout ce qui est mauvais. La première chose qu'il fait est de convertir la position actuelle du fichier *pposen une adresse physique. Si cela échoue (en pratique, parce que vous êtes sur une plate-forme avec des adresses physiques 32 bits mais des décalages de fichiers 64 bits et que le décalage de fichier est supérieur à 2 ^ 32), l'écriture échoue avec EFBIG (fichier trop volumineux). La vérification suivante consiste à savoir si la plage d'adresses physiques à écrire est valide sur cette architecture de processeur particulière, et une défaillance entraîne EFAULT (mauvaise adresse).
Ensuite, sur Sparc et m68k, toute partie de l'écriture dans la toute première page physique est ignorée en silence.
Nous avons maintenant atteint la boucle principale qui itère sur les données dans des blocs qui peuvent tenir dans une seule page MMU .
/dev/memaccède à la mémoire physique, pas à la mémoire virtuelle, mais les instructions du processeur pour charger et stocker des données dans la mémoire utilisent des adresses virtuelles, de sorte que le code doit organiser pour mapper la mémoire physique à une adresse virtuelle. Sous Linux, selon l'architecture du processeur et la configuration du noyau, ce mappage existe de façon permanente ou doit être fait à la volée; c'est le travail de xlate_dev_mem_ptr(et unxlate_dev_mem_ptrannule tout ce qui xlate_dev_mem_ptrfait). Ensuite, la fonction copy_from_userlit à partir du tampon qui a été transmis à lawriteappel système et écrit simplement à l'adresse virtuelle où la mémoire physique est actuellement mappée. Le code émet des instructions de stockage de mémoire normales, et ce que cela signifie dépend du matériel.
Avant de discuter de ce qu'une écriture à une adresse physique fait, je vais discuter d'une vérification qui se produit avant cette écriture. A l'intérieur de la boucle, la fonction page_is_allowedbloque l'accès à certaines adresses si l'option de configuration du noyau CONFIG_STRICT_DEVMEMest activée (ce qui est le cas par défaut): seules les adresses autorisées par devmem_is_allowedpeuvent être atteintes /dev/mem, pour d'autres l'écriture échoue avec EPERM (opération non autorisée). La description de cette option indique:
Si cette option est activée et IO_STRICT_DEVMEM = n, le fichier / dev / mem autorise uniquement l'accès de l'espace utilisateur à l'espace PCI et au code BIOS et aux régions de données. C'est suffisant pour dosemu et X et tous les utilisateurs courants de / dev / mem.
C'est une description très centrée sur x86. En fait, de manière plus générique, CONFIG_STRICT_DEVMEMbloque l'accès aux adresses de mémoire physique qui sont mappées à la RAM, mais autorise l'accès aux adresses qui ne mappent pas à la RAM. Les détails des plages d'adresses physiques autorisées dépendent de l'architecture du processeur, mais tous excluent la RAM où sont stockées les données du noyau et des processus terrestres de l'utilisateur. L'option supplémentaire CONFIG_IO_STRICT_DEVMEM(désactivée à partir d'Ubuntu 18.04) bloque les accès aux adresses physiques revendiquées par un pilote.
Adresses de la mémoire physique mappées à la RAM . Il existe donc des adresses de mémoire physique qui ne sont pas mappées à la RAM? Oui. C'est la discussion que j'ai promise ci-dessus sur ce que signifie écrire à une adresse.
Une instruction de stockage en mémoire n'écrit pas nécessairement dans la RAM. Le processeur décompose l'adresse et décide vers quel périphérique envoyer le magasin. (Quand je dis «le processeur», j'englobe les contrôleurs périphériques qui peuvent ne pas provenir du même fabricant.) La RAM n'est qu'un de ces périphériques. La manière dont la répartition est effectuée dépend beaucoup de l'architecture du processeur, mais les principes fondamentaux sont plus ou moins les mêmes sur toutes les architectures. Le processeur décompose essentiellement les bits supérieurs de l'adresse et les recherche dans certaines tables qui sont remplies en fonction des informations codées en dur, des informations obtenues en sondant certains bus et des informations configurées par le logiciel. Beaucoup de mise en cache et de mise en mémoire tampon peuvent être impliqués, mais en un mot, après cette décomposition,bus et ensuite c'est au périphérique de s'en occuper. (Ou le résultat de la recherche de table pourrait être qu'il n'y a pas de périphérique à cette adresse, auquel cas le processeur entre dans un état d' interruption où il exécute du code dans le noyau qui se traduit normalement par un SIGBUS pour le processus appelant.)
Un magasin à une adresse mappée à la RAM ne «fait» rien d'autre que d'écraser la valeur précédemment stockée à cette adresse, avec la promesse qu'un chargement ultérieur à la même adresse restituera la dernière valeur stockée. Mais même la RAM a quelques adresses qui ne se comportent pas de cette façon: elle a quelques registres qui peuvent contrôler des choses comme le taux de rafraîchissement et la tension.
En général, une lecture ou une écriture dans un registre matériel fait tout ce que le matériel est programmé pour faire. La plupart des accès au matériel fonctionnent de cette façon: le logiciel (normalement le code du noyau) accède à une certaine adresse physique, cela atteint le bus qui connecte le processeur au périphérique, et le périphérique fait son travail. Certains processeurs (en particulier x86) ont également des instructions CPU distinctes qui provoquent des lectures / écritures sur des périphériques distincts de la charge de la mémoire et du stockage, mais même sur x86, de nombreux périphériques sont accessibles via le chargement / stockage.
La commande dd if=/dev/urandom of=/dev/memécrit des données aléatoires sur le périphérique mappé à l'adresse 0 (et aux adresses suivantes, tant que les écritures réussissent). Dans la pratique, je m'attends à ce que sur de nombreuses architectures, l'adresse physique 0 ne dispose d'aucun périphérique mappé ou de RAM, et donc la toute première tentative d'écriture échoue. Mais s'il y a un périphérique mappé à l'adresse 0, ou si vous changez la commande pour écrire dans une adresse différente, vous déclencherez quelque chose d'imprévisible dans le périphérique. Avec des données aléatoires à des adresses croissantes, il est peu probable de faire quelque chose d'intéressant, mais en principe, cela pourrait éteindre l'ordinateur (il y a probablement une adresse qui le fait en fait), écraser certains paramètres du BIOS qui rendent impossible le démarrage, ou même frapper certains buggy périphérique d'une manière qui l'endommage.
alias Russian_roulette='dd if=/dev/urandom of=/dev/mem seek=$((4096*RANDOM+4096*32768*RANDOM))'