ARM64架构下运行Linux为何必须启用MMU？
在当今的计算世界里，ARM64（也称AArch64）早已不再是“低功耗小众平台”的代名词。从智能手机到数据中心服务器，从边缘设备到高性能计算集群，ARM64的身影无处不在 🚀。而在这背后，一个看似不起眼却至关重要的硬件组件—— 内存管理单元（MMU） ，正默默支撑着整个系统的稳定与安全。
但你有没有想过：
“如果我把MMU关掉，还能不能跑Linux？”
这个问题听起来有点像在问：“没有方向盘的车还能开吗？” 可惜的是，在现代操作系统的世界里，答案是明确的—— 不行 ❌。
尤其对于ARM64这样的通用架构而言，MMU不是可选项，而是 系统存在的基石 。本文将带你深入底层，从代码、机制和实验三个维度，彻底揭开这个被长期误解的技术谜题 🔍。
为什么我们甚至会讨论“无MMU运行”？
其实，“无MMU也能运行操作系统”并非天方夜谭。早在20世纪末，uClinux项目就在摩托罗拉ColdFire这类没有MMU的嵌入式处理器上成功移植了Linux内核的一个精简版本 💡。它通过静态链接、禁止
fork()
、禁用
mmap()
等方式，硬生生地绕过了虚拟内存的需求。
那么问题来了：既然uClinux能在ARM7TDMI这种老古董上跑，那为什么不能在更先进的ARM64上复刻一次奇迹呢？毕竟，Cortex-A系列芯片也支持MPU（Memory Protection Unit），难道不能替代部分功能？
很遗憾，现实比理想骨感得多。ARM64的设计哲学从一开始就假定了 完整的虚拟内存系统存在 ，这意味着任何试图剥离MMU的努力，都像是想拆掉房子的地基还指望墙不倒 😅。
MMU不只是地址翻译器，它是操作系统的“安全中枢”
很多人对MMU的理解停留在“把虚拟地址转成物理地址”这一步，但这只是冰山一角 🧊。真正让Linux得以成为多任务、多用户、高安全性操作系统的，是MMU提供的三大核心能力：
✅ 地址空间隔离：每个进程都有自己的“房间”
想象一下，如果没有MMU，所有程序共享同一块物理内存空间，A进程不小心写到了B进程的数据区怎么办？更可怕的是，恶意程序可以直接读取浏览器密码或银行App的密钥。
有了MMU之后，每个进程都有自己独立的页表，即使它们访问相同的虚拟地址（比如
0x400000
），实际映射的物理地址完全不同。这就是
进程隔离
的基础。
// 每个进程的 mm_struct 都有自己的页表根
struct mm_struct {
pgd_t *pgd; // Page Global Directory —— 页表起点！
struct vm_area_struct *mmap;
unsigned long start_code, end_code;
...
};
一旦切换进程，CPU就会更新TTBR0_EL1寄存器指向新进程的
pgd
，瞬间完成地址空间切换。这一切的前提是什么？
MMU必须开着
！
✅ 内存保护：谁都不能越界
MMU不仅能隔离地址空间，还能控制每一页的访问权限。例如：
- 栈区域设置为“不可执行”，防止缓冲区溢出攻击；
- 内核代码页标记为“用户态不可读写”，避免提权漏洞；
- 设备寄存器页禁止缓存，保证I/O一致性。
这些都依赖于页表项中的控制位：
| 控制位 | 含义 |
|---|---|
AP[1:0]
| 访问权限（只读/读写，内核/用户） |
XN
| Execute Never —— 禁止执行 |
PXN
| Privileged eXecute Never —— 特权级也不准执行 |
AttrIdx
| 内存类型（Normal/Device/Strongly Ordered） |
比如一个典型的用户栈页表项可能是这样构建的：
pte = phys_addr | PTE_VALID | PTE_TYPE_PAGE | PTE_AP_USER | PTE_XN;
看到了吗？连“不能执行”这种基础安全策略，都要靠MMU来实现。关掉MMU？等于主动打开后门🚪。
✅ 虚拟内存高级特性：按需分页、交换、动态加载
现代应用之所以能轻松使用几GB内存，是因为有 按需分页（Demand Paging） 和 Swap机制 的存在。程序启动时，并不会把所有页面加载进RAM；只有当访问某个未映射页面时，才会触发“缺页异常”，由内核从磁盘加载内容。
这背后的功臣是谁？还是MMU。它负责检测无效页表项并抛出Page Fault异常，交给内核处理。
同样，
mmap()
、
dlopen()
、
brk()
等系统调用也都依赖虚拟地址空间的存在。没有MMU，就没有这些机制，也就没有现代软件生态。
ARM64的地址转换机制：四级页表是怎么工作的？
ARM64采用四级页表结构（L0 ~ L3），支持最多48位虚拟地址，提供高达256TB的寻址空间。这是怎么做到的？
假设我们有一个4KB粒度的页表配置，典型的48位虚拟地址被划分为以下几个字段：
| 字段 | 位范围 | 说明 |
|---|---|---|
| Sign Extension | [63:48] | 必须全0或全1，确保地址合法性 |
| Level 0 Index | [47:39] | L0页表索引（9位 → 512项） |
| Level 1 Index | [38:30] | L1页表索引 |
| Level 2 Index | [29:21] | L2页表索引 |
| Level 3 Index | [20:12] | L3页表索引 |
| Page Offset | [11:0] | 页内偏移（4KB） |
每次地址翻译时，MMU从TTBR0_EL1获取L0页表基址，然后逐级查找，直到找到最终的物理页帧。整个过程由硬件自动完成，效率极高 ⚡。
来看一段初始化页表的关键汇编代码：
// 设置TTBR0_EL1，告诉MMU一级页表在哪
mov x0, #0x400000 // 假设页表位于4MB处
msr ttbr0_el1, x0 // 写入寄存器
isb // 插入同步屏障，确保生效
这几行代码看似简单，却是开启虚拟内存世界的钥匙 🔑。如果不正确设置TTBR，启用MMU后第一条指令就会跳进黑洞，引发Data Abort异常。
而且ARM64还支持两个地址空间：
- TTBR0_EL1 → 用户空间（低地址）
- TTBR1_EL1 → 内核空间（高地址）
通过虚拟地址高位自动选择，无需手动干预。这也是为什么内核代码可以永远驻留在高地址区域（如
0xFFFF_8000_0000
），而用户程序无法触及。
Linux内核启动流程：MMU何时启用？能不能跳过？
让我们看看Linux内核在ARM64上的真实启动路径：
ENTRY(_stext)
mrs x21, CurrentEL
cmp x21, #CurrentEL_EL2
b.eq 1f
// 设置初始栈
adrp x8, __initial_sp
mov sp, x8
// CPU低层配置
bl __cpu_setup
// 构建恒等映射页表
adrp x0, idmap_pg_dir
adrp x1, swapper_pg_dir
bl __create_page_tables
// 启用MMU并跳转
adrp x8, __enable_mmu
br x8
ENDPROC(_stext)
注意最后两步：
1.
__create_page_tables
创建 identity mapping（物理=虚拟）和内核页表；
2.
__enable_mmu
配置TCR、SCTLR，最终设置SCTLR.M位开启MMU。
关键点来了： 在进入start_kernel()之前，MMU已经被强制启用了！
也就是说，你想直接跳过这段代码、强行保持MMU关闭状态继续运行？对不起，下一跳就死机 🛑。
因为后续代码已经运行在虚拟地址环境了。如果你没建立正确的映射关系，PC指针一动，立马触发异常。
编译时就决定了命运：CONFIG_MMU根本没法关！
你以为改个配置就能试试看？Too young too simple 😏。
打开
arch/arm64/Kconfig
文件，你会看到这一行：
config ARM64
def_bool y
select MMU # ← 注意这里！
select GENERIC_ATOMIC64
select IRQ_DOMAIN
...
看到了吗？只要选择了ARM64架构， MMU就被强制选中了 ！你甚至不能在menuconfig里取消它。
尝试手动编辑
.config
文件，把
CONFIG_MMU=y
改成
n
，然后执行：
make ARCH=arm64 oldconfig
结果是什么？
*** ERROR: CONFIG_MMU must be enabled for ARM64 architecture
系统直接报错退出。
再进一步，就算你用补丁强行绕过检查，编译过程也会很快崩溃：
In file included from ./include/linux/mm.h:14,
from ./include/linux/uaccess.h:10,
from init/main.c:47:
./include/asm/mmu.h: No such file or directory
因为大量头文件和结构体（如
mm_struct
,
pgd_t
,
pte_t
）都是在
#ifdef CONFIG_MMU
条件下定义的。关掉MMU，等于把这些全都删了。
实验验证：真有人试过禁用MMU吗？
当然有！我们可以用QEMU模拟ARM64平台来做个极限测试。
实验一：延迟启用MMU可行吗？
启动命令：
qemu-system-aarch64 \
-machine virt -cpu cortex-a57 \
-kernel arch/arm64/boot/Image \
-append "console=ttyAMA0" -nographic -s -S
用GDB连接：
(gdb) target remote :1234
(gdb) break __enable_mmu
(gdb) continue
断点命中时查看寄存器：
(gdb) info registers sctlr
sctlr_el1 0x800d207d
此时
M=0
，表示MMU尚未启用。但我们发现，前面的代码（如
__cpu_setup
）居然能正常执行！
这说明： 早期引导阶段确实可以在无MMU环境下运行一小段代码 。
但如果我们在
__enable_mmu
内部跳过
msr sctlr_el1, x1
这条指令，强制不让MMU开启，会发生什么？
下一跳指令立即失败：
Exception Level: EL1
Far: 0xffffff8000080000 (VA)
Par: 0x0 (translation fault)
原因很简单：目标地址属于内核空间，但没有页表映射，无法翻译成物理地址。
结论：短暂无MMU运行是可能的，但仅限于极早期初始化阶段。一旦进入标准内核主循环，就必须启用MMU，否则寸步难行 🚶♂️。
那些“看似成功”的边界案例，真的能算Linux吗？
你说，FreeRTOS、Zephyr、OP-TEE这些东西不是也能在ARM64上跑吗？它们有些还不需要MMU啊！
没错，但请搞清楚一件事：
它们不是Linux ❗
虽然名字里带“OS”，但它们更像是“带调度功能的库”而非完整操作系统。
| 系统 | 是否需要MMU | 支持fork/mmap？ | POSIX兼容性 |
|---|---|---|---|
| Linux (标准) | ✅ 必须 | ✅ 全面支持 | ✅ 完整 |
| Zephyr RTOS | ❌ 可选 | ❌ 不支持 | ❌ 有限 |
| FreeRTOS | ❌ 可选 | ❌ 无 | ❌ 无 |
| OP-TEE (TEE OS) | ⚠️ 可选 | ❌ 单一服务 | ❌ 否 |
| uClinux | ✅ 必须（但裁剪版） | ⚠️ 替代方案 | ⭕ 部分 |
比如Zephyr，它的线程栈都是编译时静态分配的，所有对象地址固定，根本不涉及虚拟内存概念。你可以把它理解为“一个多任务裸机程序”。
而uClinux虽然号称“无MMU Linux”，但它从未正式支持ARM64。现有的补丁集只适用于ARMv4T~ARM9，且停留在Linux 4.9时代。面对现代ARM64驱动模型（Device Tree、ACPI）、KASLR、模块化设计，uClinux早已力不从心。
工具链也在“合谋”：glibc/musl都依赖mmap
就算你能魔改出一个“无MMU的ARM64内核”，接下来的问题更致命： 用户空间怎么办？
主流C库（glibc、musl）在初始化堆的时候都会调用
mmap()
或
brk()
，而这两种机制都依赖虚拟内存系统。
以musl为例，其
malloc
实现中就有如下逻辑：
void *brk(void *addr) {
if (!addr) return current_break;
if (addr > max_break) {
void *p = mmap(PAGE_ALIGN(addr), ...);
if (p == MAP_FAILED) return NULL;
max_break = p + MMAP_THRESHOLD;
}
current_break = addr;
return addr;
}
看到了吗？连
brk()
这种传统系统调用，在musl里也会fallback到
mmap()
！而在无MMU系统中，
mmap()
只能返回
ENOSYS
（功能未实现），导致
malloc
永远失败。
换句话说： 连最简单的printf(“Hello World\n”);都会崩掉 😱。
所以，未来还有可能打破这个规则吗？
理论上讲，除非你重新发明一套全新的操作系统范式，否则几乎不可能。
ARMv8.5引入了MTE（Memory Tagging Extension）、PAC（Pointer Authentication）等新技术，增强了安全性，但它们 不是为了取代MMU ，而是作为补充机制协同工作。
例如MTE仍然依赖虚拟地址空间进行标签管理：
MSR TCR_EL1, x0 // 先设置页表基址（MMU相关）
MSR MTE_CTL_EL1, x1 // 再启用内存标签（额外功能）
可见，MMU依然是整个内存系统的起点。
至于某些专用加速器芯片（如AI推理卡）采用“No-MMU + DMA直连”架构，追求极致性能，那也是特定领域优化，不适合通用计算场景。
总结：MMU是ARM64上运行Linux的“氧气”
我们可以做一个大胆的类比：
如果说CPU是大脑，内存是血液，那么MMU就是呼吸系统——你也许能屏息几秒钟，但绝不能永远不喘气。
在ARM64平台上运行标准Linux， 启用MMU不是选择题，而是生存条件 。无论是从架构设计、源码实现、编译约束还是生态系统角度看，MMU都已经深度融入每一个角落。
那些所谓的“例外情况”：
- 引导加载程序（U-Boot）：只是短暂过渡；
- RTOS（Zephyr/FreeRTOS）：根本不是Linux；
- TEE系统（OP-TEE）：功能极度受限；
- FPGA原型：仅供研究调试；
都不足以撼动这一基本事实。
所以，下次当你听到有人说“我在ARM64上跑了无MMU Linux”，不妨微笑着问一句：
“那你
fork()过吗？mmap()过吗？装过Docker吗？”
大概率，对方会沉默 😶。
毕竟，在这个世界里，真正的自由来自于抽象，而不是裸奔 🏃♂️💨。
扫一扫
954
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
