最近数天内实在欢乐异常，拜Google Project Zero计划背书之所赐，持续“炎上”火势越烧越大，还一路延烧“好厝边”AMD和ARM的Intel处理器漏洞事件，应该是资讯业界时下最夯的热门话题，为崭新的2018年打响了扰人清梦的第一炮，而Intel首席执行官在这极度敏感的心里关键时刻，将手上的持股出清到公司董事会规定的低标，所引发的争议，更是跳到太平洋也洗不清，反正现在太平洋也没多干净。
总之，唯一可以肯定的是，一路观察下来，真正有看懂Google那篇官方部落格文的媒体，恐怕仅为凤毛鳞爪，但惟恐天下不乱大肆散播恐慌，东拼西凑出一篇篇看似连笔者都看不懂的“有字天书”报导者，绝对有如过江之鲫，然后又一票科技文青继续一如往昔的惊呆了。
但相信各位科科们绝对不会满足于坊间多数媒体捉风补影绘声绘影的报导中，仅仅那句比较有意义的“利用处理器预测执行机制，先斩后奏提前存取内存，又没做好权限安全性检验的漏洞”和一票看不懂的圣经密码像KPTI KASLR KAISER Spectre Meltdown等，而是希望能在脑中描绘出整个命案现场的全貌与画在马路上的人形粉笔圈，所以你才会勉力爬文爬到这里。
我们先回到原点，从基本观念—近代操作系统的两大重要元素“保护模式”与“虚拟内存”—为起点，一步一脚印的踏入迷宫的最深处，最起码了解为何操作系统修正此漏洞后，那号称造成最多30%的效能损失，到底凶手是谁，人是谁杀的，谁是在画面中全身一直涂成黑色还不停奸笑着的黑衣人。
多工操作系统或任何虚拟化环境的两种基本运作权限
如同现实世界对公用资源的保防措施，为了确保多工操作系统 (或虚拟机器) 的正常运作，隔离不同应用程序 (或操作系统) 所使用的系统资源，免于来自错误程式的破坏，确保使用者不会互相干扰，我们必须保护操作系统核心与虚拟机器Hypervisor、系统档案与共用资源，所以至少需要两种不同的运作权限：“使用者模式 (User Mode)” 与“系统模式 (System Mode)”。
先回顾操作系统的启动流程：按下开机按钮，处理器先从Boot ROM撷取并执行系统自我检测程式 (也就是BIOS和UEFI的工作)，然后从大型储存媒介读取OS Loader，再将操作系统核心 (Kernel) 载入至内存，接着在系统模式执行操作系统核心，开始载入装置驱动程式，直到操作系统已经可以完全管理电脑的底层硬件装置，就进入应用程序执行阶段，启动使用者模式。
此外，可能“动摇国本”更动系统底层状态的指令，都应该被定义为只能在系统模式执行的“特权指令 (Privileged Instruction)”，如在使用者模式执行，则将触发处理器的例外处理机制，再经由操作系统的“设陷 (Trap，或称为软件中断)”，决定是否执行该指令，如应用程序透过“系统呼叫 (System Call)”，要求得到更多的内存空间或进行I/O存取。
奠定多工操作系统精巧内存保护的虚拟内存
一般电脑玩家对“虚拟内存”的认知多半仅限于“主内存不够时，电脑将塞不下的东西丢到硬盘，然后就开始听着硬盘发出阵阵的哀号”，但这就太过小看虚拟内存对近代多工操作系统那举足轻重的重要性了，甚至说虚拟内存是当代汎用型操作系统的地基也不为过。
由小到大，虚拟内存的重点如下：
- 程式不再受限于可用的实体内存总量，并将实际上四散各处的实体内存位址 (Physical Address)，转化为一整块连续可用的虚拟内存空间，简化程式开发的工作。
- 所谓的“虚拟位址 (Virtual Address)”也就是应用程序眼中所看到的内存位址。值得注意的是，越接近处理器核心的快取内存，越倾向使用虚拟位址进行索引 (Index)，原因不言可喻。
- 主内存只须包含被程式使用到的部分，不必整个塞进去，意味更多程式可一起独乐乐不如众乐乐。
- 允许大量的应用程序同时在同一台电脑上执行，并减少载入与置换每个程式的I/O负担。(不过在内存贵的要命的年代，没事一直听硬盘惨叫的老玩家可能感受不到)
- 每个行程 (Process) 都享有自己的虚拟位址空间，不同的虚拟页 (Page) 会映射到不同的实体内存位址。
- 提供更精巧的内存保护，如透过前述的保护模式、系统呼叫，与虚拟分页中的权限位元，操作系统可透过改变分页表 (Page Table) ，对执行中的众多应用程序号令天下“朕给你的，才是你的，朕不给你的，你不能抢”。如发生分页错误 (Page Fault)，应用程序所需要的分页不位于主内存，此时就须启动例外处理以中断执行中的行程并“处理后事”。
换言之，经由虚拟内存的管理，操作系统核心和应用程序所占用的实体内存位址与分布方式，并非井水不犯河水，现实上是有可能“水乳交融”在一起的。
此外，为了加速虚拟位址与实体位址之间的转换，处理器通常内建了一个称为TLB (Translation Lookaside Buffer)的小型快取内存，不同的分页表管理策略，如同迥异的内存存取模式，对其命中率都会产生极大的影响，而且因为TLB算是分页表的子集合，TLB误失和分页错误一样的不好应付，频繁的“刷洗 (Flush)”TLB内容对整体效能的伤害，有如深度指令管线发生预测执行错误般的“火烧摩天楼”一样的可怕，甚至有过之而无不及。
开始冒烟但尚未起火的关键线索
科科们也许已经抱怨著“这些不都是尔孰能详”的计算机组织基础知识吗？但恭喜各位，你们其实已经开始误入真正的雷区了。
- 既然系统权限已经受到重重保护，为何还会被“僭越”？
- 要如何旁敲侧击出享受分页表庇荫的操作系统核心的实体内存位址？
- 为何这些操作系统的补洞程式会造成大量TLB Flush，并增加执行系统呼叫的成本？
后面我们就来开始踩地雷，瞧瞧Google团队是如何对当代非循序执行 (Out-Of-Order Execution) 处理器上下其手，祝各位科科不要被炸上天呀。ㄎㄎ。
