关于关闭 x86 CPU 漏洞修补以获取性能提升的讨论

2018-02-05 10:48:52 +08:00
 iwtbauh

起因:我的笔记本漏洞修补后 I/O 性能下降接近 4 倍!!(测试数据在下面)导致 虚拟机( KVM )卡顿、VIM 偶尔卡住、编译性能下降等等

发行版:Ubuntu 16.04 LTS

CPU:Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz

我听到风声,立刻在未打补丁的内核上进行的 IO 性能测试

测试方法是

time dd if=/dev/zero of=/dev/null bs=1 count=100000000

大致就相当于疯狂的执行 100000000x2 次系统调用,结果是

记录了 100000000+0 的读入
记录了 100000000+0 的写出
100000000 bytes (100 MB, 95 MiB) copied, 19.3005 s, 5.2 MB/s

real	0m19.303s
user	0m4.728s
sys	0m14.572s

升级到 4.10.x 内核后,测试结果惨不忍睹

记录了 100000000+0 的读入
记录了 100000000+0 的写出
100000000 bytes (100 MB, 95 MiB) copied, 73.8429 s, 1.4 MB/s

real	1m13.846s
user	0m30.031s
sys	0m43.879s

我通过向内核命令行传入 nopti 参数,关闭 KPTI (内核页表隔离),禁用了修补,成功使性能还原

我自以为万事大吉了,可是万万没想到啊,前几天升级了 4.13.x 内核,速度又卡出翔啊,退回 4.10.x 内核一切正常

今天想到了测试了下,测试和之前一样了 1m14s !!!

但是 PTI 确实被禁用了(内核日志明确指出),我随后找到了这个 https://github.com/speed47/spectre-meltdown-checker

在 4.10.x 内核(禁用 PTI )测试结果如下

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel has array_index_mask_nospec:  NO 
* Checking count of LFENCE instructions following a jump in kernel:  NO  (only 5 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  VULNERABLE  (Kernel source needs to be patched to mitigate the vulnerability)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO 
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO 
    * IBRS enabled for User space:  NO 
    * IBPB enabled:  NO 
* Mitigation 2
  * Kernel compiled with retpoline option:  NO 
  * Kernel compiled with a retpoline-aware compiler:  NO 
  * Retpoline enabled:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
* Running as a Xen PV DomU:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

在 4.13.x 内核上(禁用 PTI ),发现了以下问题

我找到了这个: https://lwn.net/Articles/743019/ ,于是根据所说,传入 noibrs 参数成功禁用 IBRS 修补,测试性能结果如下

记录了 100000000+0 的读入
记录了 100000000+0 的写出
100000000 bytes (100 MB, 95 MiB) copied, 26.1775 s, 3.8 MB/s

real	0m26.178s
user	0m5.396s
sys	0m20.745s

性能回升一些,但仍未达到最初的状态,我估计应该是 LFENCE instructions following a jump in kernel 达到 68 导致的,如何把这个值改回 5,没有找到有关资料,即使需要重新编译内核我也想这个改回去,但不想降回旧内核。

大家怎么看

4112 次点击
所在节点    Linux
9 条回复
we000
2018-02-05 10:57:40 +08:00
那就自己编译吧,其实锁定旧内核也没什么区别吧。。。

看法嘛,IO 性能降四倍是个什么表述? IO 用时多这么些不应该啊,而且那只是极限情况平时问题不大吧,自己笔记本这个补丁不打问题也不大吧。。。
iwtbauh
2018-02-05 11:05:33 +08:00
@we000 问题是我不知道如何才能将这个值改回 5 啊,内核编译选项里并没有找到,网上也没有找到有用的信息,只好求助各位了。

是真的能感觉出不如之前流畅了,很难受的,要不然我也不会为了无关紧要的性能牺牲安全不是

强迫症又想用新内核,唉。。
innoink
2018-02-05 11:13:59 +08:00
去看 git 记录,改了哪些地方,改回来
jyf007
2018-02-05 11:16:47 +08:00
还是 gentoo 方便,想怎么改就怎么改啊
对了 openbsd 在 2006 年已经补了.
h4lbhg1G
2018-02-05 11:35:03 +08:00
@jyf007 啥? 2006 年就发现问题了?可啪!
iwtbauh
2018-02-05 11:46:35 +08:00
@innoink 看不出是什么地方修改的,我这水平恐怕只能一个补丁编译一次一个补丁编译一次地试出来是哪个提交导致的,天哪
iwtbauh
2018-02-05 11:50:09 +08:00
而且独立主线内核之外再维护一套补丁的难度太大了,内核一更新我就可能需要跟进,这个值好象是内核执行某种跳转的次数,恐怕无法通过给用户一个编译选项,只能通过折中形式“硬编码”到内核中,这样看来我还是退回旧内核吧
Simontune
2018-02-05 20:56:41 +08:00
@jyf007 06 年?!这安全性还真不是吹的啊,佩服
jyf007
2018-02-06 09:00:37 +08:00
@Simontune
@h4lbhg1G
看走眼了,是 2007 年,不过也是远古巨坟
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/428504

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX