dd if=/dev/urandom of=/dev/mem 安全吗？

Question

这究竟是做什么的？我不明白你怎么能用这个访问基本内存......似乎有点奇怪。安全吗？

dd if=/dev/urandom of=/dev/mem

Answer 1

不要在家里尝试这个！它可能会使您的系统崩溃，如果您真的不走运，它可能会损坏外围设备或使您的计算机无法启动。

实际上，在大多数平台上，它只是失败并出现错误，但这取决于硬件架构。除非您以非特权用户身份运行该命令，否则绝对不能保证这是无害的。对于非特权用户，该命令完全无害，因为您无法打开/dev/mem.

当您以 root 身份运行命令时，您应该知道自己在做什么。内核有时会阻止您做一些危险的事情，但并非总是如此。/dev/mem是您真正应该知道自己在做什么的那些潜在危险的事情之一。

我将介绍/dev/mem在 Linux 上写入的工作方式。其他 Unices 上的一般原则是相同的，但内核选项之类的东西完全不同。

当进程读取或写入设备文件时会发生什么取决于内核。对设备文件的访问会在处理此设备文件的驱动程序中运行一些代码。例如，写/dev/mem调用函数write_mem在drivers/char/mem.c。这个函数有 4 个参数：一个表示打开文件的数据结构、一个指向要写入的数据的指针、要写入的字节数以及文件中的当前位置。

请注意，只有当调用者首先具有打开文件的权限时，您才能做到这一点。设备文件通常服从文件权限。正常的权限/dev/mem是crw-r-----由国有root:kmem，因此，如果您尝试打开它写入而不根，你将只能收到拒绝“权限”（EACCESS）。但是如果你是 root（或者如果 root 已经改变了这个文件的权限），打开通过，然后你可以尝试写入。

write_mem函数中的代码进行了一些健全性检查，但这些检查不足以防止所有坏事。它做的第一件事是将当前文件位置*ppos转换为物理地址。如果失败（实际上，因为您使用的是具有 32 位物理地址但具有 64 位文件偏移量且文件偏移量大于 2^32 的平台），则写入失败并显示 EFBIG（文件太大）。下一个检查是要写入的物理地址范围在此特定处理器体系结构上是否有效，并且失败会导致 EFAULT（错误地址）。

接下来，在 Sparc 和 m68k 上，第一个物理页中写入的任何部分都会被悄悄跳过。

我们现在已经到达了主循环，它以可容纳在一个MMU页面中的块为单位迭代数据。 /dev/mem访问物理内存，而不是虚拟内存，但是处理器指令在内存中加载和存储数据使用虚拟地址，因此代码需要安排将物理内存映射到某个虚拟地址。在 Linux 上，根据处理器架构和内核配置，这种映射要么永久存在，要么必须即时进行；这就是xlate_dev_mem_ptr（并unxlate_dev_mem_ptr撤消xlate_dev_mem_ptr所做的一切）的工作。然后该函数copy_from_user从传递给write系统调用并只写入当前映射物理内存的虚拟地址。代码发出正常的内存存储指令，这意味着什么取决于硬件。

在我讨论写入物理地址之前，我将讨论在此写入之前发生的检查。在循环中，函数page_is_allowed如果内核配置选项阻止访问某些地址CONFIG_STRICT_DEVMEM启用（这是默认的情况下）：只有允许的地址devmem_is_allowed可以通过达成/dev/mem，为别人写失败EPERM（操作不允许）。此选项的说明指出：

如果打开此选项，并且 IO_STRICT_DEVMEM=n，则 /dev/mem 文件仅允许用户空间访问 PCI 空间以及 BIOS 代码和数据区域。这对于 dosmu 和 X 以及 /dev/mem 的所有普通用户来说已经足够了。

这是非常以 x86 为中心的描述。事实上，更一般地说，CONFIG_STRICT_DEVMEM阻止访问映射到 RAM 的物理内存地址，但允许访问不映射到 RAM 的地址。允许的物理地址范围的细节取决于处理器架构，但所有这些都不包括存储内核和用户进程数据的 RAM。附加选项CONFIG_IO_STRICT_DEVMEM（从 Ubuntu 18.04 开始禁用）阻止对驱动程序声明的物理地址的访问。

映射到 RAM 的物理内存地址。那么有没有映射到 RAM 的物理内存地址？是的。这就是我上面承诺的关于写地址意味着什么的讨论。

内存存储指令不一定写入 RAM。处理器分解地址并决定将存储分派到哪个外围设备。（当我说“处理器”时，我所指的外围控制器可能不是来自同一制造商。）RAM 只是这些外围设备之一。如何完成分派很大程度上取决于处理器架构，但所有架构的基本原理或多或少都相同。处理器基本上分解了地址的高位，并在根据硬编码信息、通过探测某些总线获得的信息以及软件配置的信息填充的一些表中查找它们。可能会涉及很多缓存和缓冲，但简而言之，在这种分解之后，总线，然后由外围设备来处理它。（或者表查找的结果可能是该地址没有外设，在这种情况下，处理器进入陷阱状态，在该状态下它执行内核中的一些代码，通常会导致调用进程的SIGBUS。）

存储到映射到 RAM 的地址不会“做”任何事情，除了覆盖先前存储在该地址的值，并承诺稍后在同一地址加载将返回最后存储的值。但即使 RAM 也有一些地址不是这样：它有一些寄存器可以控制诸如刷新率和电压之类的东西。

一般而言，对硬件寄存器的读取或写入执行硬件被编程为执行的任何操作。大多数对硬件的访问都是这样工作的：软件（通常是内核代码）访问某个物理地址，这到达连接处理器和外设的总线，外设做它的事情。一些处理器（特别是 x86）也有单独的 CPU 指令，这些指令会导致读取/写入外设，这与内存加载和存储不同，但即使在 x86 上，许多外设也是通过加载/存储到达的。

该命令dd if=/dev/urandom of=/dev/mem将随机数据写入任何映射到地址 0（以及后续地址，只要写入成功）的外设。在实践中，我希望在许多架构上，物理地址 0 没有任何外设映射到它，或者有 RAM，因此第一次写入尝试失败。但是如果有一个外设映射到地址 0，或者如果您更改命令以写入不同的地址，您将在外设中触发一些不可预测的事情。随着地址增加的随机数据，它不太可能做一些有趣的事情，但原则上它可以关闭计算机（实际上可能有一个地址可以做到这一点），覆盖一些使其无法启动的 BIOS 设置，甚至击中某些有缺陷的外围设备会损坏它。

alias Russian_roulette='dd if=/dev/urandom of=/dev/mem seek=$((4096*RANDOM+4096*32768*RANDOM))'

Answer 2

这是安全的，如果您正确配置了内核（安全，因为它不起作用）

每个手册页mem(4)：

/dev/mem 是一个字符设备文件，它是计算机主内存的映像。例如，它可用于检查（甚至修补）系统。

所以理论上，dd if=/dev/urandom of=/dev/mem应该覆盖您安装的物理内存的整个地址空间，并且由于内核和其他程序从内存运行，这应该有效地使系统崩溃。在实践中，有限制。从同一个手册页：

从 Linux 2.6.26 开始，根据体系结构，CONFIG_STRICT_DEVMEM 内核配置选项限制了可以通过该文件访问的区域。

在虚拟机 Ubuntu 18.04 上尝试此操作，dd: writing to '/dev/mem': Operation not permitted即使具有sudoroot 权限，它也会返回错误crw-r-----。来自Ubuntu 维基：

/dev/mem 保护

一些应用程序（Xorg）需要从用户空间直接访问物理内存。存在特殊文件 /dev/mem 以提供此访问权限。过去，如果攻击者具有 root 访问权限，则可以从该文件查看和更改内核内存。CONFIG_STRICT_DEVMEM 内核选项被引入以阻止非设备内存访问（最初命名为 CONFIG_NONPROMISC_DEVMEM）。

所以从技术上讲，不它是不安全的（因为它会使系统崩溃）并且如果内核选项CONFIG_STRICT_DEVMEM被禁用，这是一个安全漏洞，但从我目前看到的情况来看，如果启用该选项，该命令将不会运行。根据跨站点重复，重启将解决它的任何问题，但当然当时 RAM 中的数据会丢失并且不会刷新到磁盘（如果必须的话）。

对于之前使用的重复链接，有一个建议的方法，busybox devmem因此如果您决定弄乱 RAM，毕竟可能有一种方法。