Spectre Meltdown新闻及各公司解决方案
News
比较好的几个新闻网址
- engadget
- the Register
- cnbc
- nytimes
- DoublePulser
- pcworld
- gartner
- cert
- googleblog
- cyber
2018/01/02 intel_cpu_design_flaw
- 由于Intel芯片级的安全bug，Linux、Windows、正在修改内核，这将带来严重的性能下降，目前估计为5%~30%，PostgreSQL的评估
- 许多芯片采用PCID来降低性能损失
- Intel芯片的漏洞还未公布(under wraps)，我们目前知道的有
- 从数据库应用到Web上JavaScript，都有可能从kernel内存区域中获取数据
- 修复这个bug，采用Kernel Page Table Isolation(KPTI)。Linux内核设计团队仔细考虑(mull)过Forcefully Unmap Complete Kernel With Interrupt Trampolines(FUCKWIT)，说明这种方法给开发者带来的困扰
- 当程序需要做些useful的事情时，比如写文件或者打开网络连接，就需要暂时将控制权交给kernel，为了尽快完成kernel到user，user到kernel状态的转换，kernel在所有进程的虚拟地址空间内（页表中），尽管这些进程是看不见的。当需要kernel执行时，通过system call切换至kernel mode进入kernel，完成操作后，切换回user mode。KPTI就是完全隔离kernel和user，事实上，这是不需要的，但是很明显Intel的漏洞使得在某些场景下，可以绕过访问保护。而且采用KPTI切换上下文会引起频繁的上下文切换，这需要dump cache & reload memory，严重影响了性能。
- 一旦黑客利用漏洞，就可以访问敏感信息，如passwords/login keys/files cached from disk等。想象浏览器上的JavaScript，或者云服务器上的软件，能sniff内核上的敏感信息会是什么样的后果
- 最好的情况下，这会导致defret KASLR(kernel address space layout randomization)，这种机制使得kernel的内容随机放置在虚拟空间中，攻击代码(exploit code)，如ROP攻击，就是利用已经在内存中的代码(computer instructions in known locations in memory)。如果kernel的代码随机放置，那么攻击者想要完全comprise a system就很难找到想要调用的gadget。而这一漏洞就导致kernel的数据/代码的位置暴漏给攻击者，所以还需要软件上的补丁。
- Intel芯片上存在的攻击可能不只这种。AMD给Linux kernel的邮件中提到他们的处理器不受这个漏洞的影响，但提到关键字”speculative”。
- 从AMD的软件工程师Tom Lendacky的发言中，Intel很有可能就是没有在预测执行是做权限检查。这会导致ring-3-level的用户代码访问ring-0-level的kernel数据
- 考虑到Linux和Windows改动如此之大，说明不仅仅是绕过KASLR这么简单
- Linux上隔离kernel和user地址空间基于KAISER（由Graz University of Technology in Austria开发）补丁的一系列修复。论文提到通过侧信道攻击CPU虚拟内存提取存储器信息可能绕过KASLR，Graz University of Technology in Austria的团队提出隔离kernel和user来防止信息泄露。
- 提到Anders Fogh2017年7月写的博客，虽然没有有力的代码佐证（come up with any working proof-of-concept code），但说明预测执行的确可以打破kernel和user之间的隔离
- 一个软件开发者评论：这个bug会影响到包括Amazon EC2，Microsoft Azure和Google Copmute Engine的云计算环境
- 之前就有流言Xen可能有严重的bug，现在看来可能是因为硬件bug
- 更新：Vrije Universiteit Amsterdam系统与网络安全组的PhD发现了proof-of-concept program来窥探chipzilla flaw，实验从用户态读取内核态的数据
2018/01/03 meltdown-spectre-microsoft-intel-google-apple
- Google列出Android上可能受到攻击的服务，保护措施也被添加到最新的更新中
- Microsoft正在努力降低漏洞的影响，针对Intel/ARM/AMD的处理器上的Windows都发布了补救方法。针对Azure云服务平台，公司称已全部更新，绝大部分的用户将感受不到性能影响
- Apple提出macOS 10.13.2已经解决了这个问题，10.13.3还有surprises
- AMD说目前为止还不受攻击的影响，后续跟进，白皮书
- 值得注意的是(One thing to be aware of is that)，只有在用户运行兼容的杀毒软件时才会更新，如果没有出现，就有问题了
- 还有另一点需要注意(Another consideration is that)，恶意代码可能通过浏览器上的网页下载，所以IE也提供了更新；Google提出了Site Isolation，后期将发布包含保护措施的Chrome 64；Mozilla也[确认](https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/了可能受到攻击，在Firefox 57开始保护
- Vmware也在更新
- 2018/01/03 intel-kernel-memory-flaw
- 研究者发现普通进程可以决定内核存储空间的内容或者布局。修复此bug代价应该非常大(steep)，目前知道的方法是完全隔离kernel和普通进程，但带来的存储空间切换（系统调用或硬件中断），会引起严重的性能损失
- 性能损失多少完全取决于运行什么程序，最大的性能损失大概是虚拟系统，比如Amazon’s EC2和Google Compute Engine
- The Register声明性能大约损失5%~30%，但有证据说明可能有更高的损失。
- Linux最近有了一次重大的改动，PTI被引入作为标准，并被回退（being backported）。官方的回复是合并KASLR，虽然大多数专家认为没有用
- 也有奇怪的情况发生：文件缺失，部分内容重新编辑(redacted)，Intel/Amazon/Google被也收到相关信息
- 其实AMD与ARM并不需要PTI
- grsecurity的Brad Spengler说i7-6700有29%的损失，i7-3770s有34%的损失
- Microsoft早在2017年12月就已经更新
- 此链接有各个性能损失的测试结果、补丁、各公司的回复
- 至于是否会对每个任务都带来性能影响，还有待实验考究
- 芯片级别的bug将影响近乎所有的操作系统，包括Linux，MacOS和Windows，软件上的修复就如Linux和Windows，但是要在解决问题的同时保证性能，就需要在CPU级别上做改动
- AMD申明由于memory handling不同，所以不受攻击的影响
- 解决此次问题有两大问题：1. 改动设计（design tweak）；2. 性能损失
2018/01/03 intel-says-security-issue-is-not-specific-to-its-cpus
- Intel回复
- 说明问题不仅仅出现在Intel的CPU上，AMD和ARM也都存在问题，如Ryzen rig
- 性能损失是workload-dependent，普通用户注意不到
- Intel有义务公开不安全漏洞，但是本计划在周末公布（软件和固件上的更新将完成），但由于一些媒体不准确的新闻，所以提前公布
- Intel宣称芯片是世界上最安全的芯片，将与合作伙伴一起为用户提供安全的解决方案
- 声明这不是一个flaw，而是一种可能抓取敏感信息的软件分析方法，不会导致死机、删除、修改数据。尽管存在风险，但是还未出现数据被盗取的案例
- Intel和其他公司计划在下周尽快解决，如果确实只是Intel独有，那么对于与AMD和Qualcomm的竞争就会处于劣势
AMD认为这个问题并不是与硬件毫无关系的，该公司声明(CNBC新闻)，由于架构上的不同，AMD的处理器目前”near zero risk”，并列出不受影响的处理器
- 这条新闻中提及，Meltdown只存在于Intel，Spectre在AMD和ARM中也存在
- Rambus的Paul Kocher告知CNBC，AMD其实也受到Spectre的影响
Meltdown是通过预测执行打破app与OS间的functional isolation；Spectre采用类似的方法打破secure app的保护膜
- 事实上，在某些程序中，处于安全目的的边界检查更容易被攻击，Spectre很难被发现，但却很难被阻止
- Google声明，Android手机在更新后就安全，诸如Google Apps，Google App Engine和smart phone devices，如Google Home，Chromcast和Google Wifi。最好打开Chrome的Site Isolation
- 声明中提到：There is no single fix for all three attack variants; each requires protection independently.
- Microsoft公布-bloomberg了更新日期
- 新闻中Intel发言：Our process is, if we know the process is difficult to go in and exploit, and we can come up with a fix, we think we’re better off to get the fix in place
- Intel股票降低了3.4%( 45.26)，AMD涨了5.2 45.26 ) ， A M D 涨 了 5.2 11.55)
- Frorester Reserch公司的一名分析员Frank Gillett称：对于漏洞的软件修复，在保证安全的前提下，代码行数、计算能力、功耗等性能的考量也十分重要；云供应商可能在关闭服务器以修复这些漏洞时，必须限制访问数据中心的新用户量；另外服务器需求量将增加，价格将上涨。
- Intel回复
- 2018/01/04 intel-patching-exploitable-processors
- 下周前更新5年内90%受影响的处理器
- 发现的缺陷使得近10年来生产的电脑（包括Intel/ARM/AMD）中普通进程可以决定kernel memory的布局，从其他的app中偷取（swipe data from）敏感信息
- 打补丁后，可能会带来严重的性能下降，但这些影响都是”highly workload-dependent”，普通用户(average consumer)看不到
- 2018/01/04 meltdown-spectre-questions
- 漏洞发现者们认为，Spectre目前不能完全解决，但在某些特殊场景下可以解决，Intel和Microsoft同意
- Intel的vice president，Donald Parker说，没有必要替换所有的设备以抵御攻击，with software patches and “firmware updates” — a way of updating code on the chip itself — Intel and other companies could “mitigate the issues.”
- 2018/01/04 intel_meltdown_spectre_bugs_the_registers_annotations
- 这篇文章对Intel的发言进行了评价
- 利用Meltdown攻破在半虚拟化的Docker和Xen后，如果获取了kernel-sharing sandbox的秘钥，就有可能corrupt/modify/deleta数据
- 2018/01/04 googleblog more-details-about-mitigations-for-cpu_4
- 公布Retpoline，已与合作伙伴共享，Google系统也已采用这种方法更新
- 在整个Google Linux产品服务器中采用KPTI(Kernel Page Table Isolation)，包括Search，Gmail，YouTube，Google Cloud Platform。预计KPTI对性能的影响会很大，但它与系统调用的频率是密切相关的，在我们的环境下，包括云设施，仅看到很小的(negligible)影响
- 在microbenchmarks测试中，性能损失是扩大的，但是建议在采用之前还是实际测量为好
- 针对1月3日提到的Meltdown和Spectre，There is no single fix for all three attack variants; each requires protection independently.
- Variant 1 bounds check bypass主要攻击编译后程序的特定序列，每个binary可能都需要解决
- 让操作系统在进程内运行不可信的代码，限制进程中哪些存储空间可以被不可信代码访问都很困难
- 在内核中，eBPF(extended Berkeley Packet Filter)从用户空间代码中提取packet filters，JIT编译packet filter code，在kernel状态运行。JIT采用边界检查来限制packet filter可以访问的空间。但是Variant 1使得攻击者可以绕过这个限制。
- –> 分析、重编译使得易受攻击的代码不被emitted，包括执行不可信代码的操作系统或者程序
- Variant 2 branch target injection或者通过更新CPU微码，或者采用Retpoline。这种方法可以按需应用到内核、系统程序库或各自的程序中
- 这个变种主要影响在同一个物理CPU上运行的其他程序的预测执行行为，因为同一个CPU上共享相同的预测表，进程间或者进程与操作系统之间都可能相互影响
- 这样一来，攻击者可以预测执行其他进程的process/hypervisor/kernel，或采用Variant 1读取其他保护空间的数据，这个variant很难被使用，但是有巨大的潜力，因为可以穿过arbitrary protection domains
- –> 需要更新CPU微码（Intel的IBRS）或者采用软件方法（Google的Retpoline）至hypervisor/system programs/libraries/user applications。
- Variant 3 rogue data cache load需要操作系统打补丁，Linux的补丁为KPTI，其他采用类似的方法
- 这个变种使得用户模式下的进程可似内核模式下访问虚拟内存。
- 采用Variant 1，程序可以从预测执行的痕迹中获取信息。现在的操作系统中，一个进程的页表几乎囊括了整个系统的所有内存空间，但限定在内核态运行时才能访问
- 变种3使得用户态也能这样访问，违背了硬件防护
- –> 需要更新操作系统，Linux增添KPTI，其他操作系统需进行类似更新。
- 更多更新信息请参考此网址
2018/01/04 intel_amd_arm_cpu_vulnerability
- 这篇文章文笔很有趣，列出了各大公司是否受到两种攻击的影响
- AMD对漏洞轻描淡写(play down)
- 针对V1，Microsoft和Linux都在做补丁；
- 针对V2，AMD将更新微码，而且在努力实现retpoline
- 不受V3的影响
- This is, essentially, a mega-gaffe by the semiconductor industry. As they souped up their CPUs to race them against each other, they left behind one thing in the dust. Security.
- One way rival processors differentiate themselves, and perform faster than their competitors, is to rely on speculative execution.
- The chips in our desktop PCs, laptops, phones, fondleslabs, and backend servers do not completely walk back every step taken when they realize they’ve gone down the wrong path of code.（预测执行，不完全回退）
- Doing some Flush+Reload magic on the cache reveals which cache line was touched and thus the content of the kernel memory byte.
- windows上可以攻击的代码
- Spectre is a very messy vulnerability that is hard to patch, but is also tricky to exploit.
- 对于浏览器，Mozilla降低了时间统计的精确度，从长远来看，有可能Web平台会使能精确时间统计，故更需要找到避免数据泄露的方法
- AMD宣称对Spectre V2免疫（AMD insists its processors are practically immune to Variant 2 Spectre attacks, which siphon data from the kernel.）
- An AMD Pro running Linux in a non-default configuration – the BPF JIT is enabled – also lets a normal user process read from 4GB of kernel virtual memory.
CERT(Community Emergency Response Team)开始时说replace CPU，后来改为apply updates
- Reference有比较重要的链接
- While the Spectre attack itself does not cross a user/kernel memory privilege boundary, depending on the configuration of the target platform, the Spectre attack may indirectly allow a user-space application to access kernel memory. For example, the Project Zero blog post describes a scenario that uses eBPF to exfiltrate kernel memory contents into user-space code. This is made possible because eBPF JIT allows for userspace applications to inject code that is executed in kernel space. While this code is verified by the kernel, eBPF-compliant code will be allowed to execute with kernel permissions. The exploit described by Project Zero leverages eBPF to execute the Spectre attack in kernel space, while exfiltrating the data to user space. It is possible that other technologies that allow in-kernel code execution may also possibly be leveraged to leak kernel memory using Spectre.
- The Linux kernel mitigations for Meltdown are referred to as KAISER, and subsequently KPTI, which aim to improve separation of kernel and user memory pages. Because the Spectre attacks do not cross user/kernel boundaries, the protections introduced with KAISER/KPTI do not add any protection against them.
Spectre Meltdown CPU mechanism for triggering Speculative execution from branch prediction Out-of-order execution Affected platforms CPUs that perform speculative execution from branch prediction CPUs that allow memory reads in out-of-order instructions Difficulty of successful attack High - Requires tailoring to the software environment of the victim process Low - Kernel memory access exploit code is mostly universal Impact Cross- and intra-process (including kernel) memory disclosure Kernel memory disclosure to userspace Software mitigations Variant 1: Compiler changes. Web browser updates to help prevent exploitation from JavaScript;
Variant 2: Indirect Branch Restricted Speculation (IBRS).Note: The software mitigation for Spectre variant 2 requires CPU microcode updates Kernel page-table isolation (KPTI) - Windows上如果不运行兼容的杀毒软件，不会提示安全更新
- 某些杀毒软件采用某种技术绕过kernel patch protection，注入hypervisor，来抓取syscalls，并对存储位置进行猜测。–Meltdown的修复中这些位置将被修改
- 事实上，杀毒软件采用了类似rootkits的方法，Microsoft在10年前引入Kernel Patch Protection来对抗rootkits。由于很多杀毒软件采用问题技术造成很多重启，最新的操作系统中就很少了，但杀毒软件提供商又将自己提到hypervisor或hardware assisted的级别。杀毒厂商其实不应该吧系统搞成这样。
- Microsoft为了抵制这种软件，在每次开机时都添加了注册表项（registry key），来确保他们的产品与目前的更新兼容
- Microsoft称：如果使用的杀毒软件没有改变这个注册表项，说明杀毒软件已经过期或者病毒已经破坏了PC，所以无需再进行修复。
- 客户们面临：
- 购买next gen security product，替换掉现有的杀毒软件，以检测未知的病毒
- 不再接收到Microsoft的安全更新
- 检测不到Meltdown病毒
- 手动修改注册码以更新
- 呼吁杀毒软件提供商不要采用hacky方式来预测存储位置，导致syscall混乱，有5家这么做，而且有很多OEM提供商许可，请整理代码(tidy up the code)
- 呼吁Microsoft不要再这么做(it needs an end of life date)，长期来看(in the long term)，这会导致每个人都不安全，杀毒软件终有一天在终端崩溃，他们将不再进行安全更新。简而言之，注册码检测必须去掉。那些笨蛋提供商若也要这么做以绕过KPP，那么也要承受我的抨击(take the heat)
- Microsoft的指导
- This isn’t as black and white as the world is melting.
- 2018/01/05 meltdown-and-spectre-are-wakeup-calls-for-the-tech-industry
- It’s not hyperbole to say that Meltdown and Spectre CPU vulnerabilities are a disaster.他们导致近20年以来所有的设备都存在泄露敏感数据的风险。
- 虽然大部分公司都先解决Meltdown（用户态访问内核态数据），但是Spectre更加顽强，可能直到下一个架构出来才能完全解决，这个过程可能持续好多年
- 这是目前遇到的最致命的漏洞，在极端条件下，所有的技术公司都需要合作起来以解决这两个漏洞
- 值得注意的是(Notably)，不允许黑客访问诸如硬盘存储设备中的数据。而且Gold在报告中说明，访问到片上存储器中的数据难度很大，因为需要深入地了解数据位置之间的关系，而位置却是不定的，需要大量的processing/decoding。虽然攻击很难实现，但是使用起来就危险了。
- By next week, Intel says it’ll have patched 90 percent of its affected CPUs released within the past five years. ARM has released patches for several of its chips affected by Spectre, and AMD says there is “near zero risk” to its products at the moment. Microsoft, Google, Apple and the Linux community have also released patches to protect against Meltdown.
- Google Project Zero和Rambus之前的队员Paul Kocher，也是漏洞的发现者之一，在the New York Times上提出，“Spectre的出现说明了技术的发展相对于安全更关注于性能”。但是Gold不同意这种说法，他说：“这是芯片架构设计时候出现的问题，谁都不可能遇见会有什么漏洞。芯片和操作系统都在Meltdown和Spectre带来的安全问题中挣扎，而且，自1995年，即受攻击芯片上市以来，从没有人提出这种架构的不安全因素，所有厂商都认为这是安全的实现方法”
- Spectre不容易修复，Meltdown的修复可能带来将近30%的性能损失
- Meltdown主要影响云计算平台，Amazon告知AWS上的用户需要更新自己在服务器上的软件
- 云平台中，客户之间大多是共享硬件资源的，单个用户用一台机器并不太现实，尽管现有软件做保护，但是最新漏洞暴漏出还是存在问题
- 个人电脑也易受到攻击，但黑客首先需要在个人电脑上运行软件，这可以通过欺骗客户通过邮件、app store或者访问钓鱼网站下载
- Windows/Linux(占所有服务器系统的30%)/Apple都提供了补丁
- Andres Freund在测试新的Linux代码后，性能损失了近20~30%，漏洞的发现者也存在同样的担心
- 研究者本计划封锁消息，这样黑客就不能在修复之前进行攻击，但是在1月2日，英国一家科技网站The Register发布了关于Meltdown的消息，所以研究者们在1月3日发布了论文，在黑客攻击前发布。
- 目前，计算机安全使用去年发布的，叫做Kaiser的补丁
- Rambus的一个司-Cryptography Research的首席科学家，Kocher先生说，Spectre是基于现有处理器设计缺陷的，它将在接下来很多年阴魂不散(going to live with us for decades)。
- Meltdown的解决比较紧急，但是Spectre将影响几乎所有的高性能处理器。性能和安全未能兼得。
- A fix may not be available for Spectre until a new generation of chips hit the market.但这是一项耗时的工程，非一日之寒。
- 云厂商受漏洞的影响比较大，因为攻击者可能利用Meltdown来访问客户在共享服务器上的数据。谷歌提出已经有两种解决方案，仅有negligible的性能影响
- True to its name, Spectre will haunt the technology world for years
- 我们必须对潜在攻击保持警觉(vigilant)
- 从某种程度上（In some form），自己管理服务器设备即昂贵又不方便，所以几乎所有用户服务都依赖于云。
- 相对更迅速地流片，提出能高效抵御Spectre的新架构对于Intel/AMD/ARM更为重要
- 2018/01/05 intel-faces-multiple-lawsuits-spectre-meltdown-vulnerabilities
- Intel面临3个诉讼：California, Oregon and Indiana，控诉Indel几个月后才通知漏洞，以及在打补丁后性能的损失
The Register reported提到PC大约带来30%的性能损失，但是Intel说只有在高负荷时才会有那么多的损失，对于普通用户(typical user)来讲性能损失是可忽略的。
- 90%受影响的芯片在本周末将被打上补丁
- Intel面临3个诉讼：California, Oregon and Indiana，控诉Indel几个月后才通知漏洞，以及在打补丁后性能的损失
- 2018/01/07 intel-chip-security
- 1994年，Intel出现一次影响计算精度的漏洞（Pentium），花高价把信息止住
- 1994年，Intel的Pentium几乎占领了运行Microsoft操作系统的PC，现如今，Intel的处理器也踏足Apple的Macintosh，云服务和计算中心的芯片95%都采用Intel的芯片
- Intel的vice president Steven L. Smith说道：黑客攻击方法就像一个房间的门或者窗，抢劫者可以利用，但是建造者肯定不会不加门或者窗
- Linux Torvald却态度不好，建议Intel认真反省(take a long hard look)芯片设计，承认有问题，而不是说一切ok
- Meltdown在操作系统上打补丁即可，但是Spectre需要修改芯片自身存储的，或者浏览器的代码，Intel建议在安全专家提到的地方插入特殊的指令，而这些地方都难以辨识
- Smith说：在chip上解决这些问题会更加有效
- 2018/01/08 intel-meltdown-spectre-flaw-security-patch
- hardware和software公司都在迅速对Meltdown和Spectre打补丁
- 之前说对5年内90%的受影响处理器进行修复，在CES上Intel 的CEO Brian Krzanich说在一个1月将完成对剩余10%的修复
- 性能损失是workload dependent，有些运行时间可能会不只30%，现在Intel和各个合作伙伴都在尽力减小性能影响
- Krzanich说目前还没有用户数据被窃取，各公司都在尽力保证现在这种情况
- 至于5年前的处理器合适被修复仍未有timeline
- 2018/01/09 microsoft-halts-meltdown-spectre-amd-patches
- 根据the Verge提供的信息，由于不能启动的原因，Microsoft已暂停了针对AMD电脑的Meltdown和Spectre安全补丁的更新
- Microsoft把此问题归结于AMD的文档
- 2018/01/09 microsoft-meltdown-spectre-performance-hit
- Microsoft的测试结果
- Spectre V1和Meltdown的性能影响损失较小，Spectre V2的影响较大（主要是2015年及以前的芯片）
- 如果采用第六代处理器，那么就仅有single-digit percent损失，如果采用第四代或者以前，将有很明显的下降；win7和win8可能会感知到性能损失；Windows Server由于大量的IO，也会有严重的性能损失
- 新版本的处理器受到漏洞补丁的影响较小，是因为Intel可以限制分支预测指令的执行（在攻击中snoop被保护的存储区）；Win10由于裁剪了之前的很多方法，导致user核kernel切换很快，因此损失也较小
- 由于大部分用户都有PC，出货量减少
- Win10目前仅占PC的27%
- 2018/01/10 nvidia-gpu-meltdown-and-spectre-patches
- 针对Meltdown和Spectre，不仅仅是处理器核操作系统需要打补丁，显卡其实也需要。NVIDIA也发布了对显卡驱动的更新。所有GeForce，Quadro，NVS，Tesla和GRID芯片都不受Meltdown和Spectre的影响，但是在CPU中的软件可能会收到Spectre两种变种的攻击。目前仅mitigate了一个，后一个将尽快跟进
- 现在还没有声明说NVIDIA的修复是否影响性能，Microsoft的声明说Spectre的修复可能影响PC的性能，但未提及显卡。NVIDIA自己保证了对Shield设备的更新
- NVIDIA’s fixes illustrate just how much of a headache Meltdown and Spectre have become. 尽管不是攻击目标，也可能需要更新
- 2018/01/11 intel-reveals-meltdown-processor-benchmark-slowdown
- fix后性能损失比例（小于10%）
- 2018/01/12 intel-meltdown-spectre-fixes-bugs-of-their-own
- Wall Street Journal报告，之前发布的补丁会导致reboot，Intel发布了一个博客说明只有Broadwell和Haswell的CPU会出现问题
- AMD用户声明在下载补丁后，不能开机；微软也暂停了更新
- Intel想很快解决Meltdown和Spectre，但补丁发布后，仅告诉了部分厂商技术细节，哪些场景不能更新，导致很多产品出现重启问题（Intel的某个Partner提供）
- Intel发言人说明，所有的信息都在patche的notification process中说明
- 2018/01/12 google-spectre-meltdown-protection-details
- Google提出了抵御Spectre和Meltdown的方法，但这种方法可能会降低系统性能，包括Gmail，Google Drive and Serch及云服务等
- Google用几个月发现Spectre V1和Meltdown，并采用上面的方法更新后，并没有收到用户对性能损失的报告
- 对于Spectre V2，Google最初认为只能采用关闭易被攻击的功能，但会造成严重的性能损失。故tech titan必须找到unusual或“moonshot”解决方案，最终由Google Senior Staff Enginner提出了Retpoline，再更新后，没有收到用户的support tickets，但潜在的缺陷还有待挖掘
- Google认为这几个攻击近10年来最难以修复的问题，一个公司能尽快解决这些问题能说明这个公司的强大。庆幸的是，tech titan将研究结果公开，这种方法将被广泛使用，提升业界的服务能力。
- 2018/01/14 spectre-meltdown-ces
- Intel CEO及AMD在CES上的回复
- 其他应用场景的畅想
- NVIDIA免疫，Qualcomm已打上补丁
- 2018年CES
- 2018/01/18 intel-spectre-reboot-problem-affects-newer-cpu
- 出现reboot问题后，Intel说仅存在于Broadwell and Haswell，但后来发现Skylake & Kaby Lake（新）、Ivy Bridge- & Sandy Bridge-based systems（旧）也存在
- Intel的two-socket服务器上，运行Java程序不会导致能耗和速度下降，但对于某些IO操作，能耗有2~4%的下降，运行速度大幅度减慢
- 当处理器100%读取数据时，性能不下降，但是，100%写数据时，性能损失近18%
- 单核运行用户模式下写操作密集型程序时，性能降低达25%
- 采用Google提出的retpoline来降低性能损失，针对titan系统上Spectre V2
- 2018/01/26 intel-spectre-meltdown-chips
- 依据Intel第四季度报表，Intel的chief executive今年将要发布针对Spectre和Meltdown的built-in mitigations
- 但带来的问题相对答案更多，比如PC World就说：Intel并没有说芯片什么时候上市；他们是否针对Spectre或者Meltdown；性能损失有多少
- Intel/ARM/AMD都收到Spectre和Meltdown的影响；tech titans诸如Apple/Microsoft/Google都在全力寻找解决方案
- We’re working to create silicon-based changes to future products, that will directly address the Spectre and Meltdown threats in hardware. And those products will begin appearing later this year
- 尽管收入基本持平，但是PC的销售额下降（Notebook revenue was flat, while sales into desktop PCs declined by 8 percent.）
- 2018/01/22 intel-spectre-patch-reboots
- Intel告知用户停止采用最初的补丁，正在测试新补丁，等最终版本
- Intel Data Center group的vice president说公司已找到Broadwell和Haswell（系统不稳定）问题的根源（identified the root cause）
- 就不定不仅带来reboot问题，还带了不可预知的系统行为
- 承认新的CPU lines也收收到reboot的影响
- 2018/01/28 intel-told-chinese-firms-of-meltdown-flaws-before-us
- Intel最开始选择告知部分合作企业，包括中国的Alibaba和Lenovo，但未告知美国政府。While the chip giant does have to talk to those companies to coordinate fixes, the Chinese government routinely monitors conversations like this – it could have theoretically exploited the holes to intercept data before patches were available.
- Intel发言人说，Meltdown和Spectre发现的较早，但是不能及时的告知所有人。Lenovo是签了保密协议（non-disclosure agreement）。Alibaba说任何accusation说与政府共享信息都只是推测，毫无依据，但是不排除（doesn’t rule out）官方在Alibaba不知情的情况下获取细节
- 其实先告知谁无所谓，问题是US政府促进漏洞的公开，使得所有公司都知道了问题的存在，但需要尽快将漏洞修复，否则就存在被攻破的危险
- Intel现在进退两难（Intel is between a rock and a hard place in situations like this）。有告知合作伙伴的义务，但是又必须限制消息的范围以降低信息泄露的风险
- 2018/01/29 windows-spectre-meltdown-unpatching
- Microsoft针对Spectre V2，为Win7/8.1/10发布out-of-band补丁，需要自己下，不能自动更新。Microsoft说明此更新仍处于测试阶段，在等Intel最后更新。Intel建议用户不要采用原来的补丁，但是对于Windows用户不行，因为这些fix都是捆绑在Microsoft自己的security update中
- Intel躲过一劫（dodged a bullet），财务报表中显示仅有微小的影响。但是被一些安全专家批判，因为没有良好的预见性，比如认为旧补丁对新架构没有影响
- Intel也遇到麻烦（took another knock），因为先把Meltdown和Spectre漏洞告知给中国的客户，比如Lenovo和Alibaba，后来才告知美国政府。其原因是因为（The concern was）中国政府可能已经发现了这个漏洞并攻击
- Intel通知针对Meltdown和Spectre的新的补丁马上就会发布
- 2018/01/29 you_can’t_ignore_the_spectre_pressing_its_nose_against_your_glass
- Spectre论文提到：健全的解决方案需要处理器设计上的修改以及对ISA的更新，来告诉硬件工程师和软件开发者对于当前CPU所处计算状态最直观的理解，来管理那些信息允许或禁止被leak
- 尽管有微码更新，Spectre不经过对现在处理器显著的改变就完全修复是不可能的，也就是说需要替换掉现有的硬件。遗憾的是，能完全房主Spectre的CPU还没上市。
- 顺序处理器不受Spectre的影响，但是其性能远远不如OoO处理器
- there probably aren’t enough in-order x86 CPUs on the planet to replace the requirements of even a tier-two public cloud provider
- 原理上，Spectre可以使得VM上运行的代码读取物理CPU上的信息，如果有黑客找到entry，就能访问到另外VM上的信息
- 自2010年以来，价值几十亿美金的加密货币被盗，仅2017年就有￥225m的Ethereum coin被盗。
- Yes, Spectre patches exist that mitigate the problem. And as soon as a new attack is discovered, patches will emerge to mitigate those attacks too. The problem is that everyone now knows where to look for guaranteed exploits, and there are likely to be more people trying to come up with new attacks than there are people trying to create new mitigation patches. 目前mitigate Spectre的补丁已经存在，而且一旦新的攻击被发现，补丁也会及时更新。但问题是所有人都知道guaranteed exploits。而且相对设计mitigation patches的设计者，会有更多的人尝试发现新的攻击。
- 需要法律的压力（regulatory pressure）
- 一些法律机构对现在仅通过打补丁假装一切没事的做法很不满意。他们认为所有的机构都应该尽最大努力保护现在已知的缺陷。对Spectre讨论的越多，就越难对Spectre的影响置之不理。
- 云服务提供商，Intel和软件供应商都强烈希望不会再有Max Schrems和挑战，知道他们能够替换CPU。他们希望保持冷静，来确保云服务不被中断。
- 很多顶级分析公司预计到2020年，公共云将占最大的IT企业份额。注意不是大多数workloads，而是很多企业依赖公共云来处理真正巨大的workload，如大数据分析、机器学习、人工智能。Bulk Data Computational Analysis(BDCA)
- 所以，对于Specture的讨论在政治上争议很多。CERT删除了他们对Spectre CVEs中的一个论定为，只有替换CPU硬件才是唯一的解决方案。确实是，尽管完全解决Spectre需要替换CPU，但是这样说会引起公众恐慌。公共云服务不仅时US政府的经济打头，而且还是战略需要。
- 攻击者不能简单地与受害者运行的程序共用一台硬件设施就能获取秘钥、密码等。攻击者仍需要以原始的方式，穿过防火墙、应用安全机制和其他更深层的防御手段。But malicious actors can no longer simply rent time on the same physical box that your workload is executing on, and try to get at your encryption keys, passwords, and other goodies. The bad guys would have to break in the old-fashioned way: through your layers of firewalls, application security and other defence-in-depth measures.
- 在很多场景下，AWS上提供的VMware或许是最终解决方案，毕竟硬件是完全独立的。但完全用VMware来替代，除了Google，没人能支付得起。
- 对于大多数人，针对Spectre，除了采用patch外没有其他的方法。公共云服务正在缓慢的进展，但不太可能slowed或者暂停。但是Security-concious组织可能延迟公共云平台上的移植。
- 2018/02/08 intel-spectre-cpu-patch
- 公布了针对Skylake-based的补丁，当然也包括之前的Broadwell和Haswell，其他平台的将尽快完成
- 2018/02/14 intel-expands-bug-bounty-to-catch-spectre-like-security-flaws
- Intel正在努力扩大bug bounty program，3月-12月开放给所有的安全研究专家，并给予丰厚的奖励
- bounty的时限不是固定的，总之是要更快更多的找到处理器相关的漏洞。
- 2018/02/15 meltdownprime-spectreprime-research
- NVDIA与Princeton University发现了一种新的工具来exploit未知的Metdown和Spectre，工具可以用来explore攻击者如何利用CPU缺陷并发现获取类似密码的敏感信息的方法
- pit two CPU cores against each other to dupe multi-core systems
- 论文中提及：
- 在Spectre和Meltdown的context中，leveraging coherence invalidations使得Prime+Probe能获得Flush+Reload一样的精度，获取相同的敏感信息。通过exploiting cache invalidations，MeltdownPrime和SpectrePrime在使用Prime+Probe时和Meltdown/Spectre timing侧信道获取相同粒度的敏感信息。
- Meltdown和Spectre在预测的时候pollute了cche，MeltdownPrime和SpectrePrime是在invalidation-based coherence protocol的系统中，预测写操作时引起的。
- 虽然现有的Intel和其他chipmakers的software patches足以保护现有的、新发现的技术，这些方法可能轻微的降低系统的性能（slow down systems a bit），但可以保证隐私数据不被泄露。但Intel和chipmakers计划做Spectre- & Meltdown-proof，作者认为是不够的，还需要考虑新的问题在进行mitigation
- 2018/02/16 intel-face-32-lawsuits-spectre-meltdown
- 目前，Intel面临32起诉讼，控诉Intel违反了安全法（需要保证产品的安全性，显然Meltdown和Spectre的出现违背了Most argue that Intel violated securities laws when it assured its products were safe to use, which the Meltdown and Spectre flaws revealed to be untrue.）。要求Intel给予经济赔偿或同级别的补偿
- 2017年7月谷歌告知Intel存在漏洞，直到2018年1月才公布，Intel迅速提供补丁，但补丁太过粗糙(crude)，使得客户必须停止更新，直到新的补丁完成。
- 虽然Intel对不同的chip line都做了修补，但如新研究，仍存在被攻击的可能。幸运的话，他们可能被修复，但是很有可能只会在Intel声称的Meltdown-and-Spectre-proof芯片中才存在。
- 2018/03/05 sgxpectre-sgx-enclave
- Ohio State University
- SGX enclave内部的分支预测受到外部程序的影响，使得SGX预测执行了外部期望其执行的代码
- 攻击者可以采用这种方法窥探enclave memory或者寄存器，打破了SGX的安全性
- resercher观察SDK为SGX引入的重复性的代码模型，以及对cache size的影响
- 几乎所有的SGX runtime libraries（Intel SGX SDK，Rust-SGX，Graphene-SGX）都有被攻击可能，所以Sgxpectre几乎能窥探所有的enclave
- Intel将于March 16发布解决方案
- PoC攻击代码
2018/03/15 mitigating-speculative-execution-side-channel-hardware-vulnerabilities
- The Case of Spectre and Meltdown
- BlueHat
- transient instructions: 执行后会在微体系结构上留下trace，但指令不被提交
RedHat FOSDEM 2018 presentation: Exploiting modern microarchitectures Meltdown spectre and other attacks
预测执行侧信道攻击的framework
- 侧信道攻击包括三个phase。这三个phase，可以在architecturally或者speculatively两种情况下发生。
- Priming phase，置系统至期望的最初的状态，比如刷新cache line；
- Triggering phase，通过侧信道传输信息；
- Observing phase，监测侧信道传输过来的信息。
预测执行侧信道攻击包含四个组成部分：
Speculation primitive，使进入non-architectural下的预测执行路径；
Spectre和Meltdown利用3中不同的speculation primitives：
1) conditional branch misprediction, aka V1
2) indirection branch misprediction, aka V2
3) exception delivery or deferal, aka V3Windowing gadget，为传输信息提供足够的预测执行时间窗口；
预测执行会有race condition：引起预测执行的uop和预测执行uop之间的竞争关系
攻击者必须赢得race condition来预测执行，定义了3中windowing gadgets
1) 产生从内存中读取数据的non-cached loads，通用CPU中一般需要几百个cycle
2) 几条相关的loads链，很有可能non-cached
3) 几条相关的需要多cycle的ALU计算链Disclosure gadget，在预测执行时通过侧信道传输信息；
读取的信息包括memory content，register state等
与ROP类似，有很多可能的disclosure gadgets，多种形式Disclosure primitive，读取disclosure gadget阶段获取到的信息
监测从disclosure gadget传出来的信息，与传输信息的channel连接（如data cache）
prior research
– 是否cached的差别为80clk vs. 200clk
– Cache侧信道攻击的方法：Evict+Time，Prime+Probe，Flush+Reload，Flush+Flush
- 侧信道攻击包括三个phase。这三个phase，可以在architecturally或者speculatively两种情况下发生。
software security models
- 基于虚拟化的隔离
- kernel/user隔离
- 进程隔离
- 语言隔离（如JS运行时沙盒）
- 这些安全模型也都强烈依赖于硬件保证security domain之间不能互相读写，除非有特殊权限（如hypervisor，kernel或者managed runtime）
- 预测执行侧信道可以穿过security domains，violating现有的软件安全模型
Intre-VM：这个范围主要针对基于虚拟化隔离的攻击，依赖于硬件对虚拟化安全扩展的支持
Hypervisor-to-guest：guest试图读取hypervisor的数据
Host-to-guest：guest试图读取特权guest的数据，比如Xen中的Hyper-V或者dom0
Guest-to-guest：试图读取其他guest的数据Intra-OS：这个范围主要针对传统的操作系统
Kernel-to-user：user试图读取kernel
Process-to-process：process读取其他process的数据
Intra-process：读取自己进程的数据，比如web浏览器提供JS来访问，可以用来创建预测执行侧信道- Enclave（如Intel的SGX）：enclave-to-any，enclave外部访问enclave内部的数据
预测执行侧信道攻击的Mitigations方法，现总结出3种通用的tactics，软硬件都可以使用：
Prevent speculation techniques：阻止speculation primitive，基本上从源上阻止了这个攻击
- Speculation barrier via execution serializing instruction
- AMD / Intel -> LFENCE
- ARM -> conditional select/move(CSEL/MOVS) + 新显示barrier指令 CSDB
- 添加/Qspectre flag至Visual C++中，支持简单的编译时静态分析，来识别有风险的代码片段。但不保证完全覆盖。
- Edge和IE上都包含了code generation的mitigation
- Security domain CPU core isolation
- 现在的CPU中，per-core和per-SMT都有独立的分支预测器，所以将workload分到不同的core中可以用来mitigate会分支冲突的预测攻击。MS已公布了minimum root将core分配到Hyper-V root partition，和CPU groups如何为guest分配多个核
- Indirect branch speculation barrier on demand and mode change
- 避免security domain影响另外一个security domain的间接分支预测，可以采用Intel、AMD、ARM提供的附加的硬件接口。微码更新，修改features，操作系统可以访问这些features。
- 这些feature使得软件可以flush间接分支预测状态，限制低权限security domain的分支预测，保护hardware thread prediction interference
- Non-speculated or safely speculated indirect branches
- Intel中far JMP不被预测，同样，Near CALL和JMP也可以不预测，来mitigate。
- Google提到的retpoline其实也是将间接call和jump转为安全的return错误预测。
- Intel说明：不要完全信任retpoline，因为near-return预测不依赖软件上对RSB下溢保护就不具备安全性。
- 在复杂的环境下，比如多厂商供的云平台、PC和服务器采用多个厂商的软件，我们不能信任所有软件都被rebuilt。
- 在未来，硬件上提供的安全防御改进，如Intel的CET，将会与软件开发者要考虑到retpoline存在兼容性问题。
- Speculation barrier via execution serializing instruction
Remove sensitive content from memory：从内存中删除敏感信息，在预测执行时不会访问到敏感信息。但这种方法不能保护读取寄存器状态或者非敏感的内存内容，如地址空间信息
- Hypervisor address space segregation
- Microsoft Hyper-V hypervisor历史上对所有的物理地址采用相同的内存映射表，来加速内存访问。为了减少会暴露给预测攻击的信息，删除hypervisor中全内存映射表，以mitigate预测执行跨VM的信息泄露
- Split user and kernel page tables
- Windows上这种方法称为Kernel Virtual Address(KVA) Shadow，通过为每个进程创建两张页表：第一张为user，仅包含用户mapping和少量的kernel transition pages；第二张为kernel，包含此进程中user和kernel的所有可访问空间。在user 状态下执行时，采用user页表，切入到kernel时，采用kernel page。这会使得敏感的kernel memory content从进程的虚拟空间中移走，从而mitigate Meltdown。
- 尽管KVA Shadow不是为了提高KASLR的鲁棒性，但这种mitigation会想起之前的KAISER(https://gruss.cc/files/kaiser.pdf)
- 各公司的mitigation：Linux kernel的KPTI，Apple的MacOS和IOS，Google的Chromebook
- Hypervisor address space segregation
Remove observation channels：删除communication channels，从而不能再用disclosure primitives。这种方法独立于speculation primitive，提供了一种broad mitigation。
- 在root extended页表中标记为guest memory为uncacheable
- 虚拟化软件常标记guest memory为privileged guest（如Hyper-V中的root或者Xen中的dom0）来快速交换共享内存中的信息。
- 在预测执行攻击中，这些共享区域被用来建立侧信道。
- 解决方案就是在root的table中将这些区域标识为noncachable的
- 在所有的CPU中，noncachable的存储区是不能被预取的，所以避免了对于共享cache line的预取。
- Do not share physical pages across guests
- 在某些情况下，虚拟化软件中各guest间可能共享物理页，这些共享区域可能会被用来传递信息。这为预测执行的guest-to-guest的攻击提供了便利。
- 这种mitigation事最直接的不允许不同security domain中guests之间共享信息的方法。
- Decrease browser time precision
- intra-process攻击场景，web浏览器上支持JS，从而可能通过JIT构造攻击。Edge和IE都降低了时间精度，从而提升了反窥信息的难度。
- 在root extended页表中标记为guest memory为uncacheable
- The Case of Spectre and Meltdown
- 2018/04/04 intel_spectre_microcode_updates
- 部分处理器由于too tricky，不能消除Spectre V2
- 4月2日公开的微码更新手册中，部分产品已标注为Stopped。Intel称经过对位架构和微码能力的仔细研究后，Intel决定不再对这些产品进行更新。3点原因：
- 微体系结构不适合加入Spectre V2的mitigation特性
- 有限的Commercially Available System软件支持
- 基于客户的需求，大部分产品都被用到“封闭系统”中，所以受攻击的可能会很小
- 新添加的Stopped的CPU，包括2007年至2011年的大部分产品，包括Core、Xeon等很多都正被使用。
- Intel没有说明哪些Stopped CPU根本不能被mitigate，哪些Chipzilla不能兼容现有的补丁。
- 好消息是，之前称不能修复的系列现在已经在修复。
- Intel目前需要解决一系列lawsuits，确保未来的产品中不会出现类似问题，在数据中心中与AMD和Qualcomm对抗。重新为PC消费者找到新的kit，关注billion-a-year的移动CPU市场中的IoT和5G市场。
- 2018/05/03 Spectre-NG
- 在manufactrer可以采用各种安全更新来解决安全漏洞时，才有一切都会很好的希望
- 但是最近，发现8个新的安全漏洞。细节在厂商能处理后猜公布细节。这8个漏洞和Spectre漏洞原理是相同的，可以将其称为Spectre Next Genration
- 目前为止，只有确切的消息是Intel处理器受到影响，以及他们的补丁计划。但是也有一些证据说明部分AMD CPU也受到影响。
- Intel已为Spectre-NG开发补丁，并与操作系统厂商共同合作开发其他方案。据消息，Intel有两波补丁计划，一个在五月完成，第二个在八月完成。
- 第一个补丁公布尽管已经开发出来，但是Google Project Zero仍坚持在deadline后公布技术细节。5月7日将为截止日期，是Windows下一个补丁日。Intel称可以早点公布第二个补丁了。所以目前猜想，很快就可以看到两个补丁。
- Microsoft也有在为CPU打补丁的迹象，打算通过更新微码来解决问题，目前卡那里，似乎是放置到Windows更新中了。
- PC厂商还不能及时提供BIOS更新。
- Spectre-NG共有8个变种，Intel将其中四个标为high risk，其余四个标为medium。研究看来，其中7个与Spectre的风险和攻击场景类似。
- 一个变种简化了across system boundaries的过程，即显著降低了攻击的难度。攻击者可以在VM中发起攻击代码，渗入host系统，比如云主机服务器。或者，也可以攻击相同主机上的其他客户。云平台上secure数据如密码和secret keys的传输就很危险。即使是SGX，也不能保证安全。
- 原理上，虽然在VM或者其他主机系统中，采用Spectre就有可能攻击成功。但是实际复现时，需要大量的先验知识，这其实是非常困难的。但是通过Spectre-NG就很容易的across system boundaries
- 而且，个人和共享的PC面临的危险相对比较小，因为被攻击的点很少。但是，仍然需要严肃考虑Spectre-NG的更新，并及时更新。
- 从历史上的更新看，事情不会进展的很顺利。尽管Spectre的更新已经有了，但是仍有大约6个月的间隙。另外，这些补丁也会降低性能，部分公司拒绝对近几年的电脑进行BIOS更新。这都使得情况变得更糟。
- 总的来看，Spectre和Meltdown不是完全独立的，不是通过插上几个补丁就能解决，相反，当一个解决后，可能会产生更多的问题。归其原由，是因为在过去的二十年里，在处理器开发过程中，对于安全的考虑总是落后于性能。during the past twenty years, safety considerations have only played second fiddle to performance in processor development.
- 对Spectre类似的硬件问题设计终极补丁显然不可能，但是neverending flood的补丁显然也是不可取的。我们无法摆脱这样一个事实，即整个IT基础架构的核心组件存在一个根本的安全问题，这将继续导致更多的问题。
- Intel必须尽快解决这些问题，当然这正在进行。同时，必须重新思考CPU的设计CPU design needs to be fundamentally rethought。德国Cyberus Technology公司（spectre/meltdown的合作发现者）Werner Haas认为，必须为HPC处理器添加solid security design。这就需要在体系结构设计初期就将security因素考虑进来
- Intel自一月以来，一直承诺security first。现在必须提供更透明的解决方案，比如公布潜在的风险评估。到目前为止，Intel总是以这样一种姿态：我们是专家，我们做的是对的。这种信心依赖于Intel的Management Engine和Software Guard Extensions。当涉及到我们的IT基础架构的核心组件时，我们不应再被模糊的承诺所迷惑We should no longer be fobbed off with vague promises when it comes to central components of our IT infrastructure.。
- 2018/05/07 Specter NG：英特尔转移其第一批补丁 - 推迟协调发布
- 第一个补丁原计划于5月7日发布，但是，Intel似乎准备不足，因此推迟发布时间-一次为期14天，如果可能会延迟更长。
- Intel现计划于5月21日发布，微码也于当天发布，同时，关于至少两个Spectre-NG的技术信息也很可能会发布。然而，这个日期并不固定，据消息，Intel已要求进一步延期至7月10日。
- Spectre NG不仅会影响所有Core I系列处理器（自2010），这些是Intel台式机。基于Atom（自2013）的Pentium，Celeron和Atom处理器也很容易受到攻击。因此平板电脑、智能手机和嵌入式设备都有可能受到攻击。
- 为消除最危险的Spectre-NG，Intel的客户必须等待更长的时间，它还会影响Core I和Xeon处理器。并允许他们从虚拟机攻击主机或者其他虚拟机，这是在云系统上致命的。Intel计划在第三季度进行补丁，大约在8月14日。
- 为了确保体系结构的安全，Intel计划将硬件更新组合为操作系统厂商必须实施的新微码和软件改进。
- 2018/05/09 spectre_ng_fix_delayed
- 最近公布的Spectre-like缺陷在12天之内不会被补丁修复。
- Intel现在计划在5月21日公开，新的微码更新也会在当天发布。
- 2018年1月，Anders Fogh写了一篇关于滥用预测执行的文章；紧接着公布了Spectre/Meltdown；后来CISPA的研究组基于2017年对于Spectre和Meltdown的研究详细地分析了预测执行。
- 4月份的时候，Intel称在早期的架构中，Spectre问题很难被修复。
- 2018/05/21 Side-Channel Vulnerability Variants 3a and 4
- Variant 3a Rogue System Regitster Read - 攻击者可以通过预测读取system parameters，通过侧信道分析，获取敏感数据
- Variant 4 Speculative Store Bypass - 当被利用时，攻击者可以读取CPU’s stack或者其他存取区中older memory values。尽管实现比较复杂， 但这种侧信道攻击使得低特权代码得以：
- 读取arbitary privileged data
- 预测运行older命令，使得通过普通的侧信道方法就可以从cache布局中提取隐私数据
- 邮件speculative execution, variant 4: speculative store bypass
- load操作一般会等待前面store指令的原地址都准备好后，判断依赖关系再发射
- memory disambigutor预测哪些不依赖于前面store的load操作，当disambigutor预测load没有依赖关系时，将从l1 DCache中读取数据
- 最终，预测被验证后，如果发生冲突，load和后面的指令将被重新执行
- 根据实验，预测执行很长一段代码，找到类似于Spectre-style的gadget，从memory中读取数据，但这个空间之前的store指令被忽略，从而错误预测执行。
Microsoft: 2018/05/21 analysis-and-mitigation-of-speculative-store-bypass
- Speculative Store Bypass(SSB)由Microsoft Security Response Center的Ken Johnson和Google Project Zero(GPZ)的Jahn Horn
- general guidance:
- windows server
- windows client
- microsoft cloud services
- 受影响的处理器包括AMD/ARM/Intel
- 对于Microsoft的用户来讲，软件商面临的风险很小，也不清楚这个变种是否有其他扩展。希望可以继续研究，作为Speculative Execution Side Channel Bounty的一部分。对于这个变种，我们将及时更新mitigation策略。
- Mitigation:
- 降低Edge和IE的精度
- 开发软件时，引入speculation barrier指令，详见C++ developer guidance for speculative execution side channels
- MS正与CPU厂商一起努力，打造新的硬件特性来解决SSB。这些特性可能会要求更新Microcode或者firmware代码。这些更新将在未来的Windows Update中提供。
- 在mitigating speculative execution side channel hardware vulnerabilities中，描述了三种预测原语，来为预测执行侧信道创造条件。这三种原语为进入non-architectural path预测执行，提供了最基本的方法，包括：条件分支预测错误、间接分支预测错误，例外提交或者延迟。
- SSB产生的原因就是潜在的load指令能在靠前的store前预测执行。 如果预测错误，就会load到以前的数据，并将其forward给后续的未操作。这会引起潜在的泄露隐私数据的风险。
- 示例代码如下，假设rdi和rsi指向同一个地址，但是第一条指令由于rdi未准备好，第二条指令先执行，将信息带入r8，如果是敏感信息，在第四条指令中又将其影响共享区的数据，那么就可以通过Cache侧信道的方法，如Flush+Reload和Prime+Probe来反推敏感信息。
01: 88040F mov [rdi+rcx],al 02: 4C0FB6040E movzx r8,byte [rsi+rcx] 03: 49C1E00C shl r8,byte 0xc 04: 428B0402 mov eax,[rdx+r8]- 这个例子虽然简单，但是仍有普遍性，比如可能存在序列产生越界读、type confusion、间接跳转和其他等等。
- C++ Developer Guidance for Speculative Execution Side Channels包含了产生此攻击的示例代码。
- 要触发此类漏洞，攻击者必须辨别这样的指令序列：
- 在可信的区间内，这段代码能被访问到，比如user mode可以通过system call出发kernel mode下的指令；
- load操作在architectually上依赖于先前的store操作；
- load读取的数据是敏感信息，而且能被创造出来对non-architectural path上的侧信道，如数据
- 在load和后续以来指令之前的store指令被先执行，gadget被预测执行
- MS自己的代码中尚未发现类似的代码片段
- 通过JIT，比如在现有的web浏览器上通过JS，可能构造类似的片段。Edge和IE上timer的精度被降低，所以极大地增加了侧信道的难度。
- 之前有一个博客mitigating speculative execution side channels，描述了可能会有潜在风险的软件安全模型，和多种mitigate预测执行侧信道的方案(tactics)。
| Attack Category | Attack Scenario | Conditional branch misprediction | Indirect branch misprediction | Exception delivery or deferral | Speculative Store Bypass |
|---|---|---|---|---|---|
| Hypervisor-to-guest | √ | √ | × | √ | |
| Inter-VM | Host-to-guest | √ | √ | × | √ |
| Kernel-to-user | √ | √ | √ | √ | |
| Kernel-to-user | √ | √ | √ | √ | |
| Intra-OS | Process-to-process | √ | √ | × | √ |
| Intra-process | √ | √ | × | √ | |
| Enclave | Enclave-to-any | √ | √ | × | √ |
- 与Spectre V1类似，SSB可以通过插入同步指令来穿行执行，比如x86/x64上的LFENCE、ARM上的SSBB。在上面的代码片段中可以在第二场插入LFENCE来串行化
01: 88040F mov [rdi+rcx],al
02: 0FAEE8 lfence
03: 4C0FB6040E movzx r8,byte [rsi+rcx]
04: 49C1E00C shl r8,byte 0xc
05: 428B0402 mov eax,[rdx+r8]- 通用的mitigation：从内存中清除敏感数据、删除observation channels
- mitigation和攻击场景之间的关系：
| Mitigation Tactic | Mitigation Name | Inter-VM | intra-OS | Enclave |
|---|---|---|---|---|
| Speculation barrier via execution serializing instruction | √ | √ | √ | |
| Security domain CPU core isolation | √ | × | × | |
| Prevent speculation techniques | Indirect branch speculation barrier on demand and mode change | √ | √ | √ |
| Non-speculated or safely-speculated indirect branches | √ | √ | √ | |
| Speculative Store Bypass Disable (SSBD) | √ | √ | √ | |
| Remove sensitive content from memory | Hypervisor address space segregation | √ | × | × |
| Split user and kernel page tables (“KVA Shadow”) | × | √ | × | |
| Map guest memory as noncacheable in root extended page tables | √ | × | × | |
| Remove observation channels | Do not share physical pages across guests | √ | × | × |
| Decrease browser timer precision | × | √ | × |
- Mitigation和变种之间的关系
| Mitigation Tactic | Mitigation Name | V1 | V2 | V3 | V4 |
|---|---|---|---|---|---|
| Speculation barrier via execution serializing instruction | √ | × | × | √ | |
| Security domain CPU core isolation | √ | √ | × | × | |
| Prevent speculation techniques | Indirect branch speculation barrier on demand and mode change | × | √ | × | × |
| Non-speculated or safely-speculated indirect branches | × | √ | × | × | |
| Speculative Store Bypass Disable (SSBD) | × | × | × | √ | |
| Remove sensitive content from memory | Hypervisor address space segregation | √ | √ | × | √ |
| Split user and kernel page tables (“KVA Shadow”) | × | × | √ | × | |
| Map guest memory as noncacheable in root extended page tables | √ | √ | × | √ | |
| Remove observation channels | Do not share physical pages across guests | √ | √ | × | √ |
| Decrease browser timer precision | √ | √ | √ | √ |