X86 CPU特性之(2)-eagerfpu

1. 从一个漏洞说起

被称为LazyFP的安全漏洞与浮点单元 (FPU) 相关, 也称为数学协处理器。FPU 在进程间切换时由操作系统使用-它保存当前进程的状态并还原新进程的状态。

FPU有两种类型的切换, 惰性 fpu 和热切的 fpu 切换。惰性 FPU 转换为性能提供了一些好处, 但在现代系统中, 增益已变得微不足道, 这导致了越来越多的使用渴望切换。

研究人员最近发现, 如果使用惰性方法, 攻击者可能会访问 FPU 状态数据, 其中可以包含敏感信息 (如加密密钥)。LazyFP vulnerability found in Intel processors

"系统软件可以选择使用惰性 FP 状态恢复, 而不是在上下文切换时对状态进行热切的保存和恢复。当一个进程通过推测其值的投机执行方通道推断其他进程的寄存器值时, 惰性恢复状态可能容易受到攻击。

作为 CVE-2018-3665 跟踪的漏洞类似于崩溃, 具体来说是变型 3a, 但该问题仅被指定为 “中等” 严重性等级。

2. 研究进展

朱利安 Stecklina 从亚马逊德国, 托马斯 Prescher 从 Cyberus 技术和 Zdenek Sojka 从 SYSGO AG 被称赞了为发现弱点。科林. 波斯也被誉为, 但研究员说, 他只是写了一个漏洞的利用。

Cyberus 发布了一个LazyFP 漏洞的博客帖子, 但它在英特尔的请求中隐瞒了一些细节。

每个关于 LazyFP 的咨询、博客文章和讨论都提供了一些关于哪些系统可能受到影响的线索。

英特尔表示, 此漏洞会影响其核心处理器, 它们将作为服务器的至强销售。该公司声称该问题已由操作系统和管理程序软件开发人员处理多年, 而且仍受到影响的供应商应该在未来几周内发布更新。

使用 AMD 或 ARM 处理器的系统似乎不会受到影响。“根据我们迄今的分析, 我们不相信我们的产品会受到最近在惰性 FPU 切换中发现的安全漏洞的影响,” AMD 告诉SecurityWeek.

微软还没有确切地说出哪些版本的 Windows 是易受攻击的, 但该公司指出, 默认情况下, 在操作系统的所有版本中都启用了 “惰性还原”, 并且无法禁用。该技术巨头向客户保证, 在 Azure 运行的 vm 没有风险。

AWS告诉客户, 其基础结构不受影响, 但建议他们确保其操作系统始终是最新的。xen 项目说运行任何版本的 xen 的系统都是易受攻击的。

3. 开启eagerfpu 特性

在 Linux 的例子中, 内核的最新版本使用了热切的 FPU（x86/fpu: Default eagerfpu=on on all CPUs）。在使用较旧处理器的系统上, 通过使用 “eagerfpu = on” 参数引导内核以启用急切的 FPU, 可以减轻此漏洞。红帽, DragonflyBSD和OpenBSD发表了建议。

那么FPU eager和lazy mode到底有什么区别呢？

lazy：对于早期的CPU，FPU context的save/restore是一件非常耗时的动作 – 要把多个128/256bit的寄存器写到内存或者从内存取回。如果每次进程（在内核态所有的线程也都是进程形式存在）切换都去做这一工作，则会很耗时。但是，另外一个事实是，很多进程根本就没有进行过浮点运算，也就没有使用到FPU。对这种进程也去执行FPU save/restore显然是一种浪费。所以，一个变通的方法是，直到进程执行了第一个浮点指令时，才去执行FPU的restore操作，这就是所谓的lazy，跟Linux kernel里其它的lazy概念是一致的。同样，只有一个进程曾经执行过浮点指令，才需要在进程切换save它的FPU context。lazy FPU依赖于kernel及CPU的exception处理机制，即Device Not Available trap，参见其handler，do_device_not_available()。
eager: 现代CPU为FPU context切换进行了优化，所以save/restore的开销不再是一个问题。因此，新kernel的做法就是在每次进程切换时都执行FPU context switch。但是，新kernel还是做了一些优化：线程被换出时，只有它使用过浮点计算，它的FPU register才会save下来；对于被换入的线程，只有它上一次使用过浮点寄存器，其FPU context才会被restore。eager与lazy 模式最大的区别就是eager没有使用exception机制，减少了一次context switch。另外，eager模式中，在判断线程是否使用过FPU寄存器时使用了很技巧性的方法(依赖于fpstate_active和fpregs_active变量)：所有的用户线程都会设fpstate_active；在restore时，会调用fpu_want_lazy_restore来决定是否preload新线程的FPU。正是这些eager模式的变化引起了测试结果的变化。

不管是eager还是lazy模式，我们都会发现，FPU context的save/restore都是发生在进程切换时。如果进程在kernel态时，比如在一个系统调用中执行了浮点运算就会使用浮点寄存器，进程从kernel态返回用户态时可能根本没有意识到自己的FPU context已经发生改变，这就破坏了进程的FPU context。所以，无论如何，如果kernel函数里使用了浮点运算，都应该进行保护，保护的方法就是调用kernel_fpu_begin/kernel_fpu_end。恰恰是这一点的疏忽，导致了eager模式在新kernel里不能正确地工作。通过仔细地分析，最终发现是kernel里的一个driver使用了-msse/-msse2编译选项，GCC在此情况下会尽可能地使用浮点寄存器进行数学运算，查看汇编代码可以发现，即使非浮点运算也会用到浮点寄存器如xmm, ymm等。去掉这个编译选项，把引起问题的浮点运算转换成定点运算，所有这一切问题都消失了，即使eager模式下也能很好地工作了。

参考：
https://www.cesafe.com/html/5527.html
https://blog.csdn.net/weixin_42094175/article/details/80520124
https://stackoverflow.com/questions/15883947/why-am-i-able-to-perform-floating-point-operations-inside-a-linux-kernel-module