Vraisemblablement, c'est en quelque sorte 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?
Vraisemblablement, c'est en quelque sorte 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?
Réponses:
Il donne accès à la mémoire physique du système.
La mem(4)
page de manuel explique plus en détail ce qui /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! :-)
/ 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 aux adresses de mémoire d'E / S liées au matériel périphérique, comme les adaptateurs vidéo.
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
et ensuite travailler dans le shell root, ou utiliser
sudo dd if=/dev/urandom of=/dev/mem
/dev/mem
fournit un accès à la mémoire physique, c’est-à-dire à toute la mémoire vive du système. Toutefois, cela ne signifie pas qu’il vous donne un accès complet en lecture / écriture à la mémoire vive (voir l’option CONFIG_STRICT_DEVMEM de 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.
Si vous écrivez aveuglément pour /dev/mem
obtenir un comportement incertain, voici une vidéo sur youtube qui fait de même.
Testez-le avec busybox devmem
busybox devmem
est un petit utilitaire CLI que mmaps /dev/mem
.
Vous pouvez l'obtenir dans Ubuntu avec: sudo apt-get install busybox
Utilisation: lisez 4 octets à partir de l'adresse physique 0x12345678
:
sudo busybox devmem 0x12345678
Ecrire 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 voudrez probablement utiliser:
open("/dev/mem", O_RDWR | O_SYNC);
mmap(..., PROT_READ | PROT_WRITE, MAP_SHARED, ...)
MAP_SHARED
rend les écritures 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 /dev/mem
visualiser et modifier la RAM normale sur le noyau v4.9, vous devez commencer par:
CONFIG_STRICT_DEVMEM
(défini par défaut sur Ubuntu 17.04)nopat
option de ligne de commande du noyau pour x86Les ports IO fonctionnent toujours sans ceux-ci.
Cache vidant
Si vous essayez d'écrire dans la RAM au lieu d'un registre, la mémoire peut être mise en cache par la CPU: https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region -of-address-space-in-linux et je ne vois pas un moyen très portable / facile de le vider ou de marquer la région comme non cachable:
Alors peut-être /dev/mem
ne peut- il 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:
volatile
variable sur un processus utilisateur/proc/<pid>/maps
+/proc/<pid>/pagemap
devmem2
et observez le processus utilisateur:kmalloc
virt_to_phys
et la renvoie à l'utilisateurdevmem2
devmem2
pour écrire au registreprintf
s sortir de l'appareil virtuel en réponse/ 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 IO mappés en mémoire.
De nombreux noyaux modernes seront configurés avec "CONFIG_STRICT_DEVMEM" qui restreint / dev / mem aux périphériques IO mappés en mémoire.
É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.
PS remarque 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.
dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM