4.31. 6.17

4.31.1. 我关注到的修改

漏洞修补配置调整：之前的侧信道攻击其实一直都没有特别好的办法彻底解决，每个缓解手段基本上都是增加攻击成本，缩小攻击窗口，而且每个都带来很大的性能下降。所以基本上是一个个独立的修改手段和配置。这么搞用户也不大能接受，毕竟不是每个人都是安全专家。所以现在统一了一下这些配置手段，用内核命令行参数mitigation=进行配置，可以选择no_user_kernel/no_user_user/no_guest_guest/no_cross_thread，选择以后，对应的攻击防御手段就放弃了，可以提升性能，但首先你得不在意那个攻击。

增加了两个系统调用file_getattr/setattr()，可以用于get/set针对文件系统的扩展文件属性，原型如下：:

SYSCALL_DEFINE5(file_getattr, int, dfd, const char __user *,
    filename, struct file_attr __user *, ufattr, size_t, usize,
    unsigned int, at_flags)
SYSCALL_DEFINE5(file_setattr, int, dfd, const char __user *, filename,
    struct file_attr __user *, ufattr, size_t, usize,
    unsigned int, at_flags)

输入直接就是filename，不需要open文件就可以用。相当于ioctl(FS_IOC_FSGETXATTR/FS_IOC_FSSETXATTR)。

修复一个Core-dump漏洞，这个漏洞的攻击方法是这样的：先触发一个进程coredump，然后理解创建一个sid的进程，让这个进程占据原来的pid，这会导致coredump的分析hook主动去读新的进程的内容，导致新进程的内容被读出来，而这个进程有sid权限，里面可能都包含了敏感的信息。我觉得这种复杂的组合漏洞，就留给具体的操作者玩吧，我们得个知字。（lwn评论区有人说这个问题的根本不是coredump，而是为什么怎么容易构造pid复用的进程，为什么不是把pid升级到64位，让攻击者根本复用不了原来的pid？）
CONFIG_SCHED_PROXY_EXEC：一个优先级反转修复方案。我还以为优先级反转这种问题是Linux这么成熟的解决方案中的默认特性呢，原来一直都是没有的，这个版本合入了一个叫Single RunQueue Proxy Execution的特性补丁解决这个问题。策略也是标准的：把被高优先级等待的线程提优先级。我没有看具体实现，但修改不但修改了rt.c，还修改了fare.c，core.c，deadline.c等多个调度器。

修改者来自Google。
这个不算什么改动，只是有点意思：这个版本开始没有CONFIG_SMP这个配置了，因为只有SMP了，单CPU就是CPU的数量等于1的SMP。这也算是给老头子对于时代变迁的感叹提供一个话题了。我还记得十几年前我们煞有介事地讨论到底多CPU是未来还是多核是未来，还吵了一年都停不下来，都不知道吵个啥。

Per-NUMA也回收接口，类似这样：:

echo 512M swappiness=10 > /sys/devices/system/node/nodeX/reclaim

引入Runtime Verification框架，接口提供在/sys/kernel/tracing/rv/上，功能类似ftrace。也是先看available_monitors看有些什么跟踪器，然后把跟踪器写到enabled_monitors中使能。

它可以做类似LTL（Linear Temporal Logic，线性时态逻辑）这样的验证手段。这个LTL是一种形式验证方法。可以通过定义状态机预测在时间线上状态的可能变化，预测系统的运行是否超出预期。这个内核实现只是对特定的算法（比如实时应用在所有执行路径上是否可以产生pagefault）引入了这个统计并输出可能的时延。

我觉得这个实现更多是学术上的，我关注它主要是最近在做一个内存序的形式化验证，我发现这种验证方法的可用范围非常有限，因为验证成本非常高（甚至高到很多场景根本不能验证）。但这个特性提醒了我，其实这样验证不一定要用在事前，完全可以放在运行系统上，这样至少我们通过一些低成本的统计，在运行中可以尝试发现我们一般测试发现不了的问题。
rust目录下现在还是在建基础设施，没有看见有什么驱动或者功能是用这个东西写的。

4.31.2. 相关特性的深入分析

Contents:

4.31.2.1. delay_accounting