Qu'est-ce que / dev / mem?

Question

Vraisemblablement, cela est-il lié à la mémoire? Quel serait

Sudo cat /dev/urandom > /dev/mem

faire? Corbeille toute la RAM? Toute la mémoire virtuelle non-noyau? Aucune de ces réponses?

Answer 1

Il donne accès à la mémoire physique du système.

La page de manuel mem(4) explique plus en détail ce que /dev/mem est.

Oui, cela pourrait causer toutes sortes de problèmes. Un redémarrage devrait vous réparer, mais de mauvaises choses peuvent arriver très facilement. Faites attention! :-)

Answer 2

/ dev/mem fournit un accès à la mémoire physique du système , pas à la mémoire virtuelle. Vous pouvez accéder à l'espace d'adressage virtuel des noyaux à l'aide de/dev/kmem.

Il est principalement utilisé pour accéder à IO adresses mémoire associées au matériel périphérique, telles que les cartes vidéo.

Answer 3

Sudo cat /dev/urandom > /dev/mem ne fera rien, puisque Sudo augmentera le privilège de chat mais pas celui de la redirection. Vous pouvez soit faire Sudo su puis travailler dans le shell racine, soit utiliser
Sudo dd if=/dev/urandom of=/dev/mem

/dev/mem donne accès à la mémoire physique, c’est-à-dire à tous les RAM du système. Toutefois, cela ne signifie pas qu’il vous donne un accès complet en lecture/écriture à RAM (voir l’option CONFIG_STRICT_DEVMEM dans ce document). Notez également que dans certaines régions de la mémoire physique, d’autres périphériques, tels que la mémoire vidéo, etc., sont mappés dessus.

Écrire aveuglément sur /dev/mem entraînera un comportement incertain. ici est une vidéo youtube faisant de même.

Answer 4

/ dev/mem fournissait traditionnellement l'accès à l'intégralité de l'espace d'adressage physique. Cela inclut la RAM, mais également tous les périphériques mappés en mémoire IO.

De nombreux noyaux modernes seront configurés avec "CONFIG_STRICT_DEVMEM" qui restreint/dev/mem aux mémoires mappées IO.

Écrire des ordures au hasard est une mauvaise idée, mais il est difficile de prédire ce qui va arriver de mal. Le matériel peut réagir de manière imprévisible à des erreurs aléatoires. Les structures de mémoire endommagées du noyau peuvent entraîner un comportement imprévisible du noyau. Au mieux, je m'attendrais à un crash du système, au pire à une corruption des données ou même à des dégâts matériels.

P.S. notez que votre commande, lorsqu'elle est exécutée en tant qu'utilisateur normal, ne doit rien faire, car Sudo n'élimine que la commande cat, pas la redirection.

Answer 5

Testez-le avec busybox devmem

busybox devmem est un utilitaire CLI minuscule qui mmaps /dev/mem.

Vous pouvez l'obtenir dans Ubuntu avec: Sudo apt-get install busybox

Utilisation: lit 4 octets à partir de l'adresse physique 0x12345678:

Sudo busybox devmem 0x12345678

Écrivez 0x9abcdef0 à cette adresse:

Sudo busybox devmem 0x12345678 w 0x9abcdef0

Source: https://github.com/mirror/busybox/blob/1_27_2/miscutils/devmem.c#L85

MAP_SHARED

Lors du mappage /dev/mem, vous souhaiterez probablement utiliser:

open("/dev/mem", O_RDWR | O_SYNC);
mmap(..., PROT_READ | PROT_WRITE, MAP_SHARED, ...)

MAP_SHARED fait que les écritures passent immédiatement dans la mémoire physique, ce qui facilite l'observation et est plus logique pour les écritures de registre matériel.

CONFIG_STRICT_DEVMEM ET nopat

Pour utiliser /dev/mem pour afficher et modifier des fichiers RAM réguliers sur le noyau v4.9, vous devez d'abord:

• disable CONFIG_STRICT_DEVMEM (défini par défaut sous Ubuntu 17.04)
• passer l'option de ligne de commande du noyau nopat pour x86

Les ports IO fonctionnent toujours sans ceux-ci.

Voir aussi: https://stackoverflow.com/questions/39134990/mmap-of-dev-mem-fails-with-invalid-argument-for-virt-to-phys-address- but-addre/45127582 # 45127582

vidage du cache

Si vous essayez d'écrire sur RAM au lieu d'un registre, la mémoire peut être mise en cache par la CPU: https://stackoverflow.com/questions/22701352/how- vider-le-processeur-cpu-pour-une-région-d'adresse-espace-sous-linux et je ne vois pas un moyen très portable/facile de le vider ou marquer la région comme non cachable:

• https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a--region-of-address-space-in-linux
• https://stackoverflow.com/questions/885658/is-it-possible-to-allocate-in-user-space-a-non-cacheable-block-of-memory-on -li

Alors peut-être que /dev/mem ne peut pas être utilisé de manière fiable pour transmettre des mémoires tampons aux périphériques?

Cela ne peut malheureusement pas être observé dans QEMU, car QEMU ne simule pas les caches.

Comment le tester

Maintenant pour la partie amusante. Voici quelques configurations intéressantes:

• Mémoire du pays d’usage
  • allouer la variable volatile à un processus utilisateur
  • obtenir l'adresse physique avec /proc/<pid>/maps + /proc/<pid>/pagemap
  • l'adresse physique avec devmem2 et observez le processus utilisateur:
• mémoire de Kernelland
  • allouez la mémoire du noyau avec kmalloc
  • récupère l'adresse physique avec virt_to_phys et la renvoie à l'utilisateur
  • modifier l'adresse physique avec devmem2
  • interroger la valeur du module de noyau
• IO mem et périphérique de plate-forme virtuelle QEMU
  • créer une plate-forme avec des adresses de registre physiques connues
  • utiliser devmem2 pour écrire dans le registre
  • regarder printfs sortir du périphérique virtuel en réponse