英特尔再爆重大芯片漏洞,苹果谷歌微软相继中招

近两年间,想必作为全球知名的半导体公司 Intel 的研发团队承受着巨大的压力,先是经历了被诸多媒体称之为“史诗级行业芯片漏洞事件”之 Meltdown (熔断)与 Spectre(幽灵)的劫难;后又在 5G 调制解调器的研发上摔了跟头;如今又有最新的消息爆出,安全研究人员在英特尔芯片中再次发现一种严重的漏洞——微架构数据采样(Microarchitectural Data Sampling,简称 MDS),对此,不少人也将该漏洞叫做“ZombieLoad”(僵尸负载)。 01、再现“Meltdown 与 Spectre 身影”的ZombieLoad 之所以ZombieLoad 会引起安全研究人员的高度关注,是因为其与曾经影响了所有 iPhone、Android、PC 设备的Meltdown 与 Spectre 有着诸多的相似之处。 我们都知道彼时不少芯片厂商为了提高 CPU 性能,从而在芯片上引入了两种特性,一种叫乱序执行(Out-of-Order Execution),另一种为推测性执行(Speculative Execution),如今这两种特性是现代处理器工作方式的重要组成部分: 乱序执行:是一种应用在高性能微处理器中来利用指令周期以避免特定类型的延迟消耗的范式。在这种方式下,可以避免因为获取下一条程序指令所引起的处理器等待,取而代之的处理下一条可以立即执行的指令; 推测执行:采用这个技术的计算机系统会根据现有信息,利用空转时间提前执行一些将来可能用得上,也可能用不上的指令。如果指令执行完成后发现用不上,系统会抛弃计算结果,并回退执行期间造成的副作用(如缓存)。 其中,对于采用推测执行,最大的好处就是可以让应用程序或系统运行得更快、更高效。但让大家不容忽视的是,这也就造成了黑客可以利用Meltdown 或 Spectre漏洞,在应用软件未经任何授权下便可读取到英特尔处理器内核的信息,进而攻击者可获取到用户设备上的一些敏感数据,如密码、登录密钥、私人消息、邮件甚至是商业秘密文件。 如今,最新被研究人员发现的ZombieLoad 漏洞,针对的也是英特尔芯片在引用两种特性作设计的缺陷,即可以使用推测性执行来诱骗英特尔的处理器抓取从芯片的一个组件转移到另一个组件的敏感数据,不过这与使用推测性执行来获取内存中的敏感数据的 Meltdown 不同,MDS 攻击专注位于芯片组件之间的缓冲区。 据英特尔官方介绍,虽然 MDS 攻击也是通过侧信道攻击的方式,但它的实现是由四种截然不同的漏洞共同组成。 事实上,这四种不同的 MDS 攻击都利用了英特尔芯片如何执行省时技巧的捷径。在上文推测执行的解释中,我们看到 CPU 在程序执行请求之前或猜测程序正在请求数据的过程中,经常跟随代码中的命令分支,以便获得先机。如果指令执行完成后发现用不上,那么系统会抛弃计算结果。(在不同条件下,芯片可以从三个不同的缓冲区中获取数据,因此研究人员可以进行多次攻击。) 此前,英特尔的芯片设计人员可能认为错误的猜测,即使提供敏感数据的猜测也无关紧要。于是,他们将这些结果抛弃了。 但其实这个漏洞,如同Meltdown 和 Spectre 一样,攻击者可以通过处理器的缓存泄漏处理器从缓冲区获取的数据。整个过程,最多从一个 CPU 的缓冲区窃取几个字节的任意数据。但是倘若连续重复数百万次,攻击者可以开始窃取 CPU 正在实时访问的所有数据流。 与此同时,通过一些其他技巧,低权限攻击者可以发出请求,说服 … Read more英特尔再爆重大芯片漏洞,苹果谷歌微软相继中招

谷歌失败案例赏析:那些年在微服务上踩的坑

大家好,今天和在座的各位分享一些失败的经验教训。聊一聊这一类的话题要比那些成功案例更有意思。行业在进步,我们可以从过去的错误中吸取经验,并主动在未来的计划中避免,这一点很令人鼓舞。 背景信息 在开始之前,先介绍一下我在谷歌的经历。2003 年大学毕业后我直接加入了谷歌,在这之前我是一个音乐营地的营地顾问,营地顾问之前我在一家冰激凌店工作。我还记得在谷歌的第一天,第一个项目的技术负责人是 Andrew Fights,他现在是类似谷歌杰出的工程师的角色,我记得当时告诉他,我得去找人聊一聊因为实在不知道我在做什么,今天想起来还是很有趣的事情。在谷歌里我像海绵一样快速的吸收技术和其他的信息。今天我在这里谈论的一些事情其实要早于我在谷歌的时间,大约 2000 年和 2001 年左右。让我们从微服务,即谷歌的微服务版本开始讲起。 当时,谷歌的业务仍然押注在 GSA(谷歌搜索服务器)产品,其实最终 GSA 也并没有像想象中的那么顺利。当然了,其它事情也是这样,毕竟不能将一个虚拟的垄断产品与像广告这样数十亿美元的巨额业务相对比。不过,谷歌最开始是以搜索起家的,并专注在解决这一类的技术问题。 接下来要讨论的很多内容的原始驱动力来自于这张幻灯片。在经济危机之前,很多企业都将他们的基础设施构建在 Sun Microsystems 的硬件之上,并将 Solaris 作为操作系统。如果不考虑成本的话,这一套解决方案比现有的其它东西都要好,很多人买了很多这种 Sun box 也是基于这样的原因。但 Sun box 真的很贵,尤其是一个拥有庞大数据中心的企业,整个数据中心需要填满这种机箱以支撑业务的发展,成本就会影响到其业务渠道和活下去的底线。 谷歌当时就处在这样一个状况。当时的人会很自然的说:“Linux 虽然不够完美,不过功能也够用,它的硬件又很便宜,所以平衡下来我们可以选择 Linux 作为替代”。一定程度上,我也认同这些过往的事情是真实的,当时的人们成本意识很强,所以他们会不遗余力的去解决一系列 RAM、芯片等 Linux 出现的一切故障,以降低成本。而这就带来了一个结果 – 即 Linux 真的不可靠,特别是使用垃圾站硬件的时候,且问题很严重。我认为,谷歌从 Compaq DEC 并购中受益匪浅,这也是导致 90 年代一些真正令人难以置信的研究实验室死亡的原因。许多人比如 Jeff Dean 和 Sanjay Kumar 都来自那个世界,他们现在几乎都是质量工程师。当时的他们对如何在那些难以令人置信的不可靠硬件之上构建软件这个问题产生了强大的兴趣,后面发生的事情也是很多接下来要分享的内容。 然而在 2001 年并没有什么可以替代的方案,所以必须自己做。另一个问题是非常古怪的扩展要求。他们试图做一些当时非常大胆的事情,即索引每个网页的每个字。一些人将每个网页的每个单词收录并编入索引,其他人只是给它建立索引,然后丢弃那些限制竞争对手能力的原始数据。这是一项艰巨的任务,需要用到当时根本不存在的计算机软件。 因此,由于不可靠的 Linux 盒子,该软件必须横向扩展,并且必须在堆栈的任何组件中容纳频繁的例行故障。之前有一篇很棒的文章提出了“机器是牛而不是宠物”。我认为在这件事情上谷歌做对了。这些机器没有来自“星际迷航”的酷炫名字,它们只是 AB … Read more谷歌失败案例赏析:那些年在微服务上踩的坑