张健：Linux内核的最新进展（6.2版本）

1 Linux内核开发模式

宏观上说一下内核的开发模式，还有 Linux 6.2 整体的大概是什么情况。这里包括自己跟着写代码之外，还包括对于规范的理解，还包括跟社区的沟通。

一般来说，参与社区不是单单一个动作，对内核来说其实也是一样的。即使你说编译器，它可能也不是一个社区，包括 RISC-V 它虽然是一个架构，但它其实里面又有不同的工作组，这里面其实还有挺多沟通的事情。写代码是一部分的工作，大家如果去关注内核的时候，如果对于内核的开发模式有一个了解的话，会对于关注内核的动态会有一些帮助。

从这个图中能看到一些，我们如果想关注一些内核的动态，能从这些点去关注。

1.1提交邮件列表

普通软件开发流程很简单，我们一般写代码 Review 合进去，一般软件开发就这么做。而内核开发其实很类似，假设已经都落到特性上（就不说前面特性怎么定出来的），我们要开发一个特性了，开发之后发内核社区还是比较 old school 的，它是通过发邮件的方式发到邮件列表 ，然后大家都可以 Review 。

最终是看 maintainer有没有给你 acknowledgment（ACK） ，给你 ACK之后补丁就有机会合进去，最终评审这部分最终的目标其实就是没有人反对，并且你所修改的子系统的这部分（比如 arch/arm64 的或者内存子系统，或者是 RISC-V），能给你一个 ACK，所以 ack by xxx 就过了，然而 Review 过了以后并不会直接合进去。

1.2合入Next分支

在平时比较简单开发流程，评审过之后可能跑个CI，通过后可能就合进去了。但是对于内核来说，它其实不会直接合进去。为啥呢？因为内核补丁太多了，其实每一次的大版本内核的合入可能都是上万个提交。这么多个补丁，如果评审之后一把就合了主线，大家就很难拿到一个相对比较稳定的主线去做开发。所以用了一个折中的方式，先合入到每个子系统的分支（比如我们去合入到 arch/arm64 子系统的分支里面，或者合入这个内存的子系统），或者文件系统的一个 next分支。

什么是 next分支？next分支是在下一次内核大版本开发时，补丁有机会被合进的分支，所以叫 next分支。如果你的补丁过 Review 就会合到 next分支。这种情况下， 对于一般的特性来说就比较稳了，到了 next分支，在下一版大版本开发的时候，你就有机会被推到主线。当然个别情况也有可能你进next分支之后，进主线的时候被其他人叫过来 “哎这个东西我不同意”，一般比较资深的 maintainer 可能会跳出来了，你的补丁有可能会被踢出去。一般是改得比较深的比较多的补丁上会有这个可能。假如没有反对意见，其实最终会合到主分支。

1.3合入窗口(merge window)

平时开发的补丁要合入主线，往往是一直可以（除非是要 freeze，否则一般可以一直合入的）。但是对于内核来说，补丁其实并不是一直可以合入的，对于一个大特性来说，真正能合入的时间叫 merge window，就是合入窗口。对于每一个内核来说，其实都只有两周的合入窗口。比如现在 6.2 内核大概是在 10 ~ 8 周之前开了两周的 merge window，然后只有在两周的 merge window 期间才能够合入大特性。

在 merge window 干什么事？其实这些代码会被各子系统 maintainer会发一个 request（比如 arch/arm64 或者是内存子系统），请求 Linus 去合入。如果 Linus 没意见，就会合到主分支。可能你经常看到 Linus 喷补丁，有的时候是在 Review 阶段，有的时候是在两周的 merge window 期间（next分支往里推的时候）。

1.4合入主线(master)

如果能够进主分支，通常来说问题不大了。但是也不排除在后面的大版本的测试过程中，或者由于一些人的反对或者测试确实出现了一些性能下降或者重大的问题，也有可能补丁会再被踢出来。

合到主分支之后，测试时间对 Linux 来说是有 7~8周 的 release candidate 。在这个过程里，可以合入一些 bugfix，补丁也是可以通过 RC 合进去的，但如果是更大的修改，可能 RC 就合不进去了。

1.5评估补丁合入的时间

可能经常你会看到，某某公司的某个特性，预计什么版本会合入。怎么能预计呢？因为他说补丁已经进了某个子系统的 next分支，它一旦进 next分支后，可以知道在下一个大版本里面，它就有可能会被合进去。所以他大概也可以这样讲，但也有可能正好没进去。

包括大家前面有提到 Rust，其实前面会有好几次说 Rust 要合一些代码，你发现好像没怎么合进去，因为这个东西改的确实比较多，所以有时候会有些争议。

1.6进入staging分支

这是一个比较顺的路线，你最终合进去了，是一个比较好的结局。这个过程也比较崎岖，因为你从补丁开发开始，可能要经过一两年的时间才会合进去。但也有可能事情不顺，评审之后你发现补丁可能进不去，但是好像又没直接给你拍死，在驱动里面比较多见。就还会进入到一个 staging分支里。

staging 什么意思呢？这个东西暂时还不符合要求，但是你如果愿意再搞一搞，其实也可以再进去。我前面自我介绍里有写叫 ilp32，当时也搞好长时间，跟Cavium公司一起搞，最后也没合入主线就在 standing分支里飘，飘了一年多还是没进去，也是一个悲伤的故事。

1.7了解内核动态的方式

每个阶段都可以是我们去了解内核动态的方式。比如在补丁 Review 的时候，我们可以通过邮件列表，看说这个人是在讨论什么，有哪些补丁在讨论。你能看到他们是怎么讨论的。基本来说，你去看一些讨论，你大概知道他最近可能关注点是什么，他可能对于补丁的合作要求大概是什么，你大概知道怎么回事了。后面不管你自己问问题还是写补丁的时候，可能会做更有针对性一点，但这个方式对你要求有点高，要求你对这个部分确实比较熟悉。

比如像我是做 ARM 的，但我想关注那块动态，但我并不想很深入地去看，我还可以在哪看呢？我想大概知道他什么时候可能会进，我可以在 next分支看一下，我会看一看这个模块或者子系统，当前的 next分支做到什么程度。我可以基本上认为 next分支的代码会在未来的几周之内进到 master分支的。但如果你连这个都不想知道，你只想知道真正进了 master分支，那其实就在每个内核开发的 merge window 之后。但如果你连这个都不想知道，你最后看 release 结果也可以。

这部分内核开发流程还可以参考内核文档，并且这部分已经有了中文翻译：https://gitee.com/mirrors/linux_old1/blob/master/Documentation/translations/zh_CN/process/2.Process.rst

2 Linux 6.2整体情况

我来之前顺便看了一下6.2 内核的整体情况，除了合并记录之外大概是有 13000 多个提交。

2.1提交按作者看提交数量

靠前的作者里大概有两种，一种是像 Linus、Thomas 和 Arnd ，包括 Mark Brown，他们其实都是 maintainer（某个子系统或者内核 maintainer） ，所以当我按作者查询的时候可以看到他们的名字的；还有一种情况是因为代码重构或硬件支持或修复一些简单的错误（做大特性，一个补丁一次也很难合入这么多补丁的）。`

来自pengutronix.de的Uwe Kleine-König的补丁基本是把不需要传入i2c设备id的枚举（probe）替换为新的接口（probe_new）。probe_new不需要传入设备id。API的修改来自：“Stephen Kitt [e-mail]”提交的“bf08ce132cd0 drivers/gpio: use simplei2c probe”。

Linaro的Krzysztof Kozłowski，主要是做一些设备树的binding和小问题的修改。比如像Linaro是做 ARM 生态的组织（因为ARM是一个公司，它不像RISC-V本来就是一个偏社区型的东西，当时 ARM 跟几个公司一起专门去做ARM生态一个组织，叫Linaro`）。

还有一种情况是它可能在蓄谋做更大的事情，在过程里面有很多小事情要干。比如之前有人专门喷过华为这个事，为什么华为总会有工程师去发一些很简单的补丁，其实他们在做一个内核维测的工具。

2.2按邮箱后缀看提交数量

按邮箱后缀大概是这么个排名。为什么按邮箱后缀呢？因为像 kernel.org，gmail，包括 Linaro，背后其实可能都会归到一些公司里面，所以我们不好讲是哪个公司里面的。Linaro 有两种，一种是 linaro.org 是 Linaro 自己的员工，另一种是其他各公司员工发布的是否也会用 linaro.org 后缀（ Linaro 是一个社区的组织）。

我们看到这里有几种人，一种是像 Linaro 这种做社区的；还有一种软硬件方案都做，像 Intel 、nvidia 和 华为；还有一种像 redhat和 suse，他们都是做发行版的。

3 Linux 6.2在体系结构的更新

说到稍微具体点的技术，因为我自己在做工作中，包括学习，去接触 ARM架构的时候，其实我能明显感觉到，首先它这东西挺多的，而且有的时候确实有些问题不太好调，同时它有一些相对比较基本的内容。

哪些内容比较基本？对任何一个架构来说，其实我们有三方面的内容一定要先搞清楚。第一方面是软硬件接口（就是汇编语言），第二方面是异常怎么去处理，第三方面是内存怎么管的。把这三个东西搞清楚，大多数特性都是从这三个东西长出来的。如果你这三个东西没搞清楚，有些时候看一些东西你就觉得好像是这么回事，但是它背后的逻辑你可能搞不清楚。所以我们顺便也借这个东西稍微提一下。

3.1 ARM64的shadow stack代码的归一，可以同时支持PAC和非PAC的情况

PAC 是什么？ PAC 其实是一个指针认证的能力，它其实在看指针访问是不是合法的一个东西。为什么 ARM架构上面能有 PAC 的特性？因为在 ARM64 里面其实只有一位是真正起到内核空间跟用户空间划分作用（我们所见的 ARM64 地址空间，用户空间是若干个 0 开头的，内核空间是若干个 1 开头）。比如我是 52BIT 地址空间，BIT63-BIT52 并不是都是要都置成 0 或者 1 才会让硬件认为你是内核态或者用户态，其实只设置 1 位就行了，那剩下那些位干嘛？这个地方就留了点余地，用来做一些事情的，其中一个事情是 PAC。

像刚才说的架构三个最基本的是：汇编语言、异常和内存管理。如果我知道了 ARM架构下面只有一位去控制内核空间还是用户空间，当我去看 PAC 的时，就能够理解它为什么能用，一旦我有这个知识后，再去看白皮书会发现白皮书写得好清楚，它其实就是按照基本的 3 个线索去写的。包括我们去看 PAC 时，关注 PAC 要用到哪些指令，如果你知道了 ARM架构，因为 ARM架构是 RISC 的，它是 load/store 模型，我再去看 PAC 指令里面，我自然而然就会找出，因为 PAC 要去做指针认证，肯定是在跟 load/store 相关的地方，就很容易看到 PAC 到底是哪两条汇编指令（PACIASP和AUTIASP）

但是这就有一个问题，本来持硬件支持一个 PAC 能力是为了支持我做一些更安全的事情，但是我又希望软件通用。例如我们不能一边支持 PAC，另一边硬件如果不支持 PAC，我直接死给你看，这也不合适是吧？所以我们应该做软件方案的时候，同时考虑到硬件支持或不支持 PAC？这就涉及到一个代码归一的问题。那么最近内核做了一个事情， shadow stack 里面的代码有个归一的动作，它不管你有没有支持 PAC，都能让系统跑起来。

我怎么去更好地在软件的执行流过程中，让软件的控制流不会被篡改？shadow stack 是其中的一个方法，它通过影子栈的方式去保证函数在调用过程中函数的返回地址是没有被篡改。

3.2 Intel通过FineIBT支持细粒度的间接跳转跟踪（Indirectbranch Tracking）

一旦我们想到这一点，会自然地想说，既然 shadow stack 是其中的一个方法，会不会有其他方法？说到其他方法，确实是有其他方法。比如大家知道这函数调用过程中，其实大概就有点两种非常典型：一种情况是固定的函数调用，比如说 A 函数调用 B 函数。还有一个情况是间接跳转，比如我在内核里注册一个 file_operations 结构体，并填了一堆指针去调用，这种其实就是一个间接跳转。

其实要去看寄存器是什么地址，跳到寄存器的地址，这种情况下本来就是动态可变的，运行时才知道跳转的位置。但如果别人去篡改这个东西，相对来说也比较容易，因为你本来就是一个变量。我怎么去防止别人去借助间接跳转去做一些攻击呢？

在 6.2 内核版本里面， Intel 就通过 FineIBT 方式去做细粒度的间接跳转跟踪。所以你看这些都是跟汇编语言相关，再往抽象的地方看其实是跟控制流相关的东西。

3.3内核增加了减缓Retbleedd补丁（Spectre的变种）

它是 18 年的 Spectre 的一个变种， 它跟 Spectre 2 其实是很类似的。它其实也是跟跳转相关的一个东西。所以如果我们想去看，Spectre 到底是怎么去修改的？其实我还是要去先了解，到底在跳转过程中有哪些问题。比如其中的一个问题，如果每一次要跳转时候，我才去做跳转的动作，并且跳转之后再去读取我后面跳转之后所需要的数据，这样很有很显然会造成一个性能的开销。

所以在所有 CPU 里面，它都会有一个叫 speculative（投机），在有跳转的时候，先猜一下你会往哪边调，跳的要访问的数据和指令先给读回来，这个叫 speculative，这本来是个性能优化。

但是这样就有个问题，猜对了和没猜对你的执行时间不一样，我就可以通过你的执行时间去知道到底你猜没猜对，也就是我可以通过你的执行时间去知道到底你的变量。比如我一个 if (a == 1) 执行什么， if (a != 1) 执行什么，通常不同分支的执行时间不同，这样我就间接我知道你变量多少了。也就是非法获得了原本没有权限看到的数据，这就变成一个攻击。这就是 Spectre 背景， Retbleed 其实就是也是 Spectre 的一个变种，这次内核针对x86的改动，是怎么去减缓这种攻击。

3.4 Intel TDX guest的支持

TDX 其实是一个为了可信计算做的一个东西，简单来说，我怎么在虚拟化的环境下面能够比较容易做可信计算。

一旦我们说到虚拟化，很显然它其实也涉及到虚拟机 guest 跟 host 是怎么去切换的？这个背后就是我们刚说的体系结构三个基础之一异常管理这个地方。你把这点搞清楚了，可能再去看这个特性就会比较清楚。比如 TDX 里面，它其实也有很核心的内容，有一个叫 virtualization exception(#VE) ,它是怎么去做的，包括它跟内存什么关系。其实你通过这个东西你就可以比较容易对 TDX 有一个了解。

3.5 Linux 6.2其他的更新

•龙芯的LoongArch架构支持了ftrace，休眠/环境，休眠到硬盘，栈保护机制。

•CXL继续改进对PMEM的支持。

•BPF的一些能力增强，例如可以操作task_struct，可以定义自己的数据类型；

•更多Rust支持的合入，离有实际功能的Rust驱动，越来越近了。

•共享匿名内存可以命名了。之前只有私有匿名内存才可以命名。

•squashfs（一个压缩的只读文件系统）可以通过threads选项，在运行时配置使用几个CPU做并行解压缩；支持了在文件系统挂载时的用户ID和组ID的映射。

•阿里的张天佳提交了fscrypt中CM4加密的支持。SM4在2016年成为国密算法。

•内核可以编译时不再支持NFSv2，后续会删除这个特性。NFS最新的版本是NFSv4。

•perf增加tasks-analyzer，可以分析进程运行时间或被调度走的时间。

•内核增加了单独的加速器驱动accel。Intel ivpu将是第一个使用这个框架的设备。

•裕太微的YT8521网络Phy芯片的驱动，而且用的是裕太微的邮箱，和只前面是社区的朋友贡献相比，裕太微的邮箱往往也意味着公司对社区的更加重视。

•瑞芯微和全志都有对IOMMU的fix。

审核编辑 ：李倩