Was ist / dev / mem?

Es bietet Zugriff auf den physischen Speicher des Systems.

Die mem(4)Manpage erklärt mehr darüber, was /dev/memist.

Ja - das kann alle möglichen Probleme verursachen. Ein Neustart sollte Sie beheben, aber schlechte Dinge können sehr leicht passieren. Achtung! :-)

/ dev / mem bietet Zugriff auf den physischen Speicher des Systems, nicht auf den virtuellen Speicher. Auf den virtuellen Adressraum des Kernels kann mit / dev / kmem zugegriffen werden.

Es wird hauptsächlich für den Zugriff auf E / A-Speicheradressen verwendet, die sich auf Peripheriegeräte wie Videoadapter beziehen.

sudo cat /dev/urandom > /dev/memtut nichts, da sudo das privileg von cat erhöht, aber nicht von der umleitung. Sie können entweder sudo suin der Root-Shell arbeiten und dann arbeiten oder verwenden
sudo dd if=/dev/urandom of=/dev/mem

/dev/memBietet Zugriff auf den physischen Speicher, dh auf den gesamten Arbeitsspeicher im System. Dies bedeutet jedoch nicht, dass Sie vollen Lese- / Schreibzugriff auf den Arbeitsspeicher haben (siehe Option CONFIG_STRICT_DEVMEM in diesem Dokument). Beachten Sie auch, dass in einigen Bereichen des physischen Speichers andere Geräte, wie z. B. Grafikkartenspeicher usw., zugeordnet sind.

Das blinde Schreiben in /dev/memführt zu einem unsicheren Verhalten. Hier ein Youtube-Video, das dasselbe tut.

/ dev / mem gewährt traditionell Zugriff auf den gesamten physischen Adressraum. Dazu gehört RAM, aber auch alle speicherzugeordneten E / A-Geräte.

Viele moderne Kernel werden mit "CONFIG_STRICT_DEVMEM" konfiguriert, wodurch / dev / mem nur auf speicherzugeordnete IO-Devices beschränkt wird.

Zufällige Abfälle darauf zu schreiben, ist eine schlechte Idee, aber es ist schwierig, genau zu sagen, was für ein schlechtes Leben passieren wird. Hardware kann auf unvorhersehbare Weise auf zufällige Abfälle reagieren, beschädigte Kernel-Speicherstrukturen können unvorhersehbares Kernelverhalten verursachen. Im besten Fall würde ich mit einem Systemabsturz rechnen, im schlimmsten Fall sind Datenbeschädigung oder sogar Hardware-Bricking nicht ausgeschlossen.

PS beachte, dass Ihr Befehl, wenn er als normaler Benutzer ausgeführt wird, nichts tun sollte, da der sudo nur den Befehl cat und nicht die Weiterleitung aufhebt.

Testen Sie es mit busybox devmem

busybox devmemist ein winziges CLI-Dienstprogramm, das mmaps verwendet /dev/mem.

Sie können es in Ubuntu bekommen mit: sudo apt-get install busybox

Verwendung: 4 Bytes von der physikalischen Adresse lesen 0x12345678:

sudo busybox devmem 0x12345678 

Schreiben Sie 0x9abcdef0an diese Adresse:

sudo busybox devmem 0x12345678 w 0x9abcdef0 

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

MAP_SHARED

Beim Mapping /dev/memmöchten Sie wahrscheinlich Folgendes verwenden:

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

MAP_SHARED Schreibt das Schreiben sofort in den physischen Speicher, was das Beobachten erleichtert und für das Schreiben von Hardware-Registern sinnvoller ist.

CONFIG_STRICT_DEVMEM und nopat

Um das /dev/memreguläre RAM in Kernel v4.9 anzuzeigen und zu ändern, müssen Sie Folgendes tun:

• deaktivieren CONFIG_STRICT_DEVMEM(standardmäßig unter Ubuntu 17.04 festgelegt)
• Übergeben Sie die nopatKernel-Befehlszeilenoption für x86

IO-Ports funktionieren auch ohne diese.

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

Cache-Spülung

Wenn Sie versuchen, in den RAM-Speicher anstelle eines Registers zu schreiben, wird der Speicher möglicherweise von der CPU zwischengespeichert: https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region -of-address-space-in-linux und ich sehe keine sehr tragbare / einfache Möglichkeit, sie zu leeren oder die Region als nicht cachbar zu markieren:

• https://stackoverflow.com/questions/22701352/wie-zu-flush-the-cpu-cache-for-a-region-of-address-space-in-linux
• https://stackoverflow.com/questions/885658/isit-möglich-zu-allocate-in-user-space-a-non-cacheable-block-of-memory-on-li

Also vielleicht /dev/memnicht zuverlässig verwendet werden, um Speicherpuffer an Geräte zu passieren?

Dies kann leider in QEMU nicht beobachtet werden, da QEMU keine Caches simuliert.

Wie teste ich es?

Nun zum Spaß. Hier sind ein paar coole Setups:

• Userland-Speicher
  • volatileVariable in einem Userland-Prozess zuordnen
  • erhalte die physikalische Adresse mit /proc/<pid>/maps+/proc/<pid>/pagemap
  • die physische Adresse mit devmem2und beobachten Sie, wie der Benutzerlandprozess reagiert:
• Kernelland-Speicher
  • Kernelspeicher mit zuweisen kmalloc
  • Holen Sie sich die physische Adresse mit virt_to_physund geben Sie sie an das Benutzerland zurück
  • Ändern Sie die physische Adresse mit devmem2
  • Fragen Sie den Wert vom Kernel-Modul ab
• IO Mem und QEMU Virtual Platform Device
  • Erstellen Sie ein Plattformgerät mit bekannten physischen Registeradressen
  • verwenden Sie devmem2, um in das Register zu schreiben
  • beobachten Sie, wie printfs als Antwort aus dem virtuellen Gerät kommt