微信公众号: mindshare思享
Meltdown概述
Meltdown破坏了位于用户和操作系统之间的基本隔离，允许恶意代码访问内核内存，从而窃取其他应用程序以及OS数据。这个漏洞“熔化”了由硬件来实现的安全边界。低权限用户级别的应用程序能利用它“越界”间接获取内存数据。
Meltdown 允许能够在存 在漏洞的处理器上运行代码， 获得整个内核的数据。 Meltdown 的根本 原因是推测性和乱序执行造成的。
有关Meltdown的介绍文章已经有很多，在本文中不再赘述.
本文主要说明arm64 Linux kernel是如何通过KPTI（Kernel Page Table Isolation 技术来解决Meltdown的问题。
需要说明的是，在Meltdown和Spectre问题爆发之前，Arm已经有计划利用KPTI (Kaiser)技术实现KASLR(Kernel Address Space Layout Randomization). Kaiser 防御机制具有阻 止 Meltdown攻击的作用.
Meltdown on Arm processor
Arm Cortex-A processors 中只有Cortex-A75受到Meltdown（Variant3) 的影响，Cortex-A75 DynamIQ处理器是目前Arm公布的最高性能的处理器（所以out of order最多). 在Arm的security whitepaper里Meltdown对应的是Variant 3 和 3a. KPTI是针对variant 3. 因为3a 只能读到部分更高EL的system registers（不能改写）, 到目前为止，还没有能利用这个实现攻击的办法. 并且Cortex-A75也不受3a影响。
White paper 可以从这里下到 https://developer.arm.com/support/security-update/download-the-whitepaper
问题描述：
Cortex-A75在更低的EL（比如user application in EL0)时，可以speculatively去访问更高EL(比如kernel in EL1）才有访问权限的数据，虽然最终application代码不能通过load/store指令得到kernel的data（最终如果这个load被architectually执行会触发MMU访问权限fault, 导致segment fault), 但是speculation已经将某些数据带到cache里，通过精心设计的cache FLUSH+RELOAD 侧边道攻击，可以通过间接手段得到kernel的数据。
所以这个问题的发生由 （在低特权级的ELspeculative access 更高EL数据）＋（精心设计的低特权级代码）＋（Cache FLUSH+RELOAD side channel attack）来触发的。
参考white paper 提供的代码
在EL0，有下面代码
1 LDR X1, [X2] ; 精心设计这个load产生cache miss, 以便CPU会speculative做 4和7的访问
2 CBZ X1, over ; 这个跳转按代码逻辑会跳
3 ; 但是CPU预测不跳
4 LDR X3, [X4] ; X4指向只能kernel访问的kernel space地址
5 LSL X3, X3, #imm
6 AND X3, X3, #0xFC0 ；移位成 probe buffer的offset
7 LDR X5, [X6,X3] ; X6 是user application可以访问的地址，用来做cache side
;channel attack 的probe buffer
8 over
1.首先 用Cache FLUSH＋RELOAD的办法讲probe buffer对应的数据都从cache 赶出去。
2. 制作条件（让上面1对应的load miss in cache）
3. 执行以上代码
3. 因为Speculation, CPU会speculatively load 以上代码的4和7,因为是speculation, 指令不会retire和回写到X3和X5. 但是数据可以带进cache.
比如如果kernel数据是1的话，在probe buffer 里offset 为0x1000对应的数据会进cache
如果kernel数据是0的话，在probe buffer 里offset 为0x0000对应的数据会进cache
4. 如果最终architectually 执行
4 LDR X3, [X4]
会导致访问权限segment fault.
5. 攻击者可以以cache line size 为stirde遍历访问probe buffer的数据, 并测量每个访问时间，如果那个访问时间短，说明其数据已经在cache 里面。再利用step3，可以反推出kernel data是 0还是1.
比如如果对probe buffer offset 为0x000的数据访问时间短，那么可推出kernel data是0
比如如果对probe buffer offset 为0x000的数据访问时间短，那么可推出kernel data是1
理解上面的内容需要对CPU设计有比较好的理解，因为本人一直支持Arm 构架和CPU, 所以理解并不费事。
为了帮助理解，贴一个我认为最接近的比喻，
我们把CPU比做学校食堂，把黑客比作两个男生A，B，用户则是女神。
这天，男生A，B总要想办法获得女神的一点私密信息——比如，女神今天午饭吃的啥~
中午，女神来到食堂打饭，点了一份小笼包。
男生A在女神后面跟食堂大娘说：我也来一份，跟她一样的~
然而这会食堂大娘表示，你等会，你前面还有人哦。
好吧，虽然说是这么说，但是后面的厨房师傅已经听到了对话，已经提前开始准备好了另一份小笼包.....
后来女神点好走了，轮到男生A点，他表示，我要一个跟她一样的...
然而这会，
食堂大娘表示，人家是人家，你是你，我们不能透露女神隐私喔，你可以走了，下一个！ （这就是目前CPU的内置的安全防线）
然而！
当下一个男生B走到食堂大娘面前，直接说：随便，哪道菜最快给我上哪道...
于是乎，既然之前厨房师傅已经提前多准备好了一份小笼包，就干脆直接把小笼包给了男生B....
这下男生知道了，女神中午吃了小笼包......
关键信息，就这么被泄露了，
虽然以上比喻中有很多不贴切
并没有关键的用kernel data作为 probe buffer index部分。。。
男生和女生的包子应该是隔离的
Meltdown 防御 on Arm64 Linux
接下来的内容假设大家对Arm Linux 比较熟悉。
通过以上分析，我们知道了这个问题最关键的地方是,
在EL0运行application时，application speculatively访问kernel address时, MMU可以做这个地址转换，MMU hardware并不检查访问权限，只做VA到PA的地址转换. 得到PA后可以做memory access到cache中。
有人会问，为什么MMU不做访问权限检查，地址转换同时做访问权限检查不是随便可以做的事情吗？对software engineer来说好像工作并不多，但是对CPU的设计者来说，在RTL关键路径（critical path）上作一些看似不多的工作会带来后端综合的timing收敛的问题，影响到CPU可以跑到的最高频率。
并且现代CPU的设计也不能禁止 speculation， out of order, 我们不能因噎废食，否则性能可能一夜回到解放前。
解决方案是什么呢？ 方法就是，
在运行user application 的时候，将kernel mapping 减少到最少，只保留必须的user到kernel的exception entry mapping. 其他的kernel mapping 在运行user application时都去掉,变成无效mapping, 这样的话，如果user访问kernel data, 在MMU地址转换的时候就会被挡掉（因为无效mapping).
设计方面就是设计一个trampoline 的kernel PGD给运行user时用。
Trampoline kernel mapping PGD只包含exception entry必需的mapping.
当user 通过系统调用，或是timer或其他异常进入kernel是首先用trampoline的mapping, 接下来tramponline的vector处理会将kernel mapping 换成正常的kernel mapping (SWAPPER_PGD_DIR), 并直接跳转到kernel原来的vector entry, 继续正常处理。
我们把上述过程称之为map kernel mapping.
当从kernel返回到user时，正常的kernel_exit会调用trampoline的exit，tramp_exit会重新将kernel mapping 换成是trampoline. 这个过程叫unmap kernel mapping.
相关代码请看Will Deacon 的patch set
| [v2,13/18] arm64: entry: Hook up entry trampoline to exception vectors | - - - | 2017-11-30 | Will Deacon | New | |
| [v2,12/18] arm64: entry: Explicitly pass exception level to kernel_ventry macro | - - - | 2017-11-30 | Will Deacon | New | |
| [v2,11/18] arm64: mm: Map entry trampoline into trampoline and kernel page tables | - - - | 2017-11-30 | Will Deacon | New | |
| [v2,10/18] arm64: entry: Add exception trampoline page for exceptions from EL0 |
https://patchwork.kernel.org/patch/10085275/
如果大家对Arm MMU, TLB工作原理比较熟悉的话，可能会进一步想到一个问题。User和kernel的translation是共享同一TLB 硬件的。
大家知道MMU会现在TLB里lookup, 我们需要避免user application发出的kernel address可以在TLB hit，因为TLB中可能已经有了用过的SWAPPER_PGD_DIR mapping的entry. 在KPTI之前kernel的mapping都是global(不匹配ASID). User application发出的kernel address translation可以直接在TLB hit。这样的话KPTI的translation table隔离机制就不work了。
这个问题可以用在kernel和user切换时对整个TLB invalidate，但是代价很高，我们要避免。
怎么处理呢？KPTI会
1. 给kernel space 也分配ASID，kernel mapping也变成和userspace一样的non global mapping.
2. kernel分配ASID的时候，分出一个奇偶ASID对，kernel用偶的，user用奇的，从2开始分。比如kernel ASID 2, user ASID3 或kernel ASID 4, user ASID 5.
这样的话因为运行在user时的ASID和kernel时的ASID不一样，user发出的地址没法hit到kernel的TLB entry。
这个问题会在后面的图示里表达比较清楚。
代码请参照 Will Deacon patch set
| [03/18] arm64: mm: Move ASID from TTBR0 to TTBR1 | - - - | 2017-11-17 | Will Deacon | New | |
| [02/18] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN | - - - | 2017-11-17 | Will Deacon | New | |
| [01/18] arm64: mm: Use non-global mappings for kernel space |
| [07/18] arm64: mm: Allocate ASIDs in pairs | - - - | 2017-11-17 | Will Deacon | New | |
| [06/18] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN |
需要说明的是，虽然trampoline是个聪明的办法，但是KPTI的开发还在演化中，以后可能会有变化。
Arm64 KPTI 图示
代码可以大家去看，但是看懂代码需要对Arm 构架和Linux kernel要比较了解。
为了帮助大家理解，我连夜画了几个图。
图1 没有KTPI时运行在user application的地址转换和访问
图2 没有KTPI时运行在kernel的地址转换和访问
图3 有KTPI时运行在user application的地址转换和访问
图4 有KTPI时运行在kernel的地址转换和访问
图5 Trampoline工作流程
总结
Arm64 Linux KPTI巧妙地通过trampoline以最小kernel改动实现了Meltdown的防御。
KPTI可以通过enable一下kernel configuration来开关。
UNMAP_KERNEL_AT_EL0
Kernel patch set可以在这里找到，
https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=will+deacon
Meltdown（variant 3) 只对Cortex-A75有影响。