日渐颓废的我们 日渐颓废的我们
关注数: 36 粉丝数: 1,510 发帖数: 78,247 关注贴吧数: 93
【转帖】开源项目难道就真的是安全的吗? 1984年的时候,UNIX 创造者之一Ken Thompson 获得了ACM图灵奖。他的获奖演讲叫做 Reflections on Trusting Trust(反思对信任的信任)。 在这个稿子只有三页纸的演讲中他分三步描述了如何构造一个非常难以被发现的编译器后门。这后来被称为 the Ken Thompson Hack(KTH),有人说它是 the root password of all evil。 在第一步里,Thompson 展示了一个可以输出自己的源代码的 C 程序。这需要一定技巧,但很多人作为编程练习都做过。 在第二步里,Thompson 在 C 的编译器里增加了一段代码(后门),让它在检测到自己在编译 UNIX 的 login 命令时在输出里插入一个后门。这个后门会允许作者用特定密码以 root 身份登录系统。 在第三步里,Thompson 在第二步的编译器里使用第一步的方法加入另一段代码(后门生成器),使得这个编译器在检测到它在编译自己时自动把第二步的后门和第三步的后门生成器插入到输出里。 在得到一个第三步的编译器后,就可以把第二、三步新增的代码从源代码里删除,因为这个新的编译器在编译它自己原来「干净」的源代码时会自动把后门和后门生成器加上。很多语言的编译器都会使用「自举」的方式编译,也就是会用一个编译器的旧版本可执行文件来编译新版本的源码,所以这样一个高危的后门完全可以在一个开源项目里存在。通过阅读这个编译器的源码是无法发现这个后门的。 KTH 还可以被加强,让它更难被察觉。比如这个编译器可以污染它编译的调试器、反编译器等开发过程中使用的工具,使得即使程序员反编译这个编译器后看到的仍是干净的代码,除非他使用的是 KTH 注入前的版本。所以当这个带有 KTH 注入的编译器来自于官方渠道时,它的后门是几乎不会被发现的,而且会影响所有用户。 最近的 XcodeGhost 最多只能算是 the Ken Thompson Hack 的一个简化版本,没有试图隐藏自己,并且修改的不是编译器本身,而是 Xcode 附带的框架库。 Thompson 在演讲里的结论是:即使开源项目也无法保证安全。在不考虑硬件或 microcode 后门的情况下,只有当运行的每一个程序都完全是自己写的时才能确保安全。可是谁的电脑上能只运行自己写的程序呢?恐怕只有 Ken Thompson 和 Dennis Ritchie 能在用自己发明的语言写的操作系统上用自己写的编译器编译自己写的操作系统吧。 Ken Thompson 从贝尔实验室退休几年之后加入了 Google。在 Google,他和原来贝尔的老同事一起发明了 Go 语言。Go 从 1.5 版开始以自举的方式编译。
[转】各品牌ssd的slc cache的算法区别,不知道苹果用的哪一种 同样是slc cache也是有很大的不同的哦。 东芝SLC Cache: 测出的性能高,家用使用方式下实际性能也高。在用户使用容量不足半盘容量时,东芝使用全盘SLC Cache,用户使用容量过半盘容量之后SLC Cache容量受限。东芝Q Pro 256GB使用空间30GB时东芝在用所有空闲MLC空间模拟SLC写入。从写入曲线可知此时SLC Cache容量大约为5GB。可见东芝Q Pro在用户使用容量超过半盘容量之后,SLC Cache空间就被限制到5GB左右,应该是仅使用OP容量内的MLC闪存进行SLC Cache了。东芝Q Pro写入在SLC Cache中的数据不会被主动释放. 三星SLC Cache: 测出的性能高,实际性能比测试成绩要低,因为测试中的读取成绩都是从SLC Cache里直接读出的,但实际使用中SLC Cache会在写入停止后立刻被释放清空,几乎没有用SLC Cache加速读取的机会。840Evo的SLC Cache容量是固定的。840Evo的SLC Cache仅用于临时承接写入压力,在写入压力停止后会立刻开始从SLC形态向TLC形态的释放,释放后SLC Cache即刻被清空。如果数据写入后立刻进行读取,则会直接从SLC Cache中返回结果 OCZ SLC Cache: 最大化利用了全盘容量进行SLC Cache加速,动态调整SLC区域,技术水平和实现难度都是最高的。在用户使用容量超过半盘容量后可以很快进行调整,仍然能够充分利用剩余的全部空闲空间进行SLC Cache加速。不管用户使用容量多少,OCZ都会拿出全部剩余空间用作SLC Cache。一直到颗粒容量不足以支持SLC Cache后才会切回MLC写入。 影驰SLC Cache: 固定SLC Cache容量,家用轻负载可享用SLC速度,遇有写入空闲会主动释放SLC Cache内容,在不间断写入的情况下,SLC Cache用完之后会缓速强制释放SLC Cache。 闪迪SLC Cache: nCache1.0:特定针对于随机写入的SLC Cache,且容量十分有限,仅能容纳几秒的随机数据写入量,作为一个提升爆发性的功能,还能降低特定情况下的写入放大率。nCache 1.0仅对随机写入应用SLC Cache来处理。Ultra II上所用的nCache被称之为nCache 2.0,闪迪针对Ultra II的TLC写入速度慢的问题,将nCache的策略调整为对所有写入数据进行SLC Cache加速,而不再区分随机写入和持续写入。
首页 5 6 7 8 9 10 下一页