February 2010 Archives

FAST 2010第二天

| 3 Comments | No TrackBacks

今天的话题都是我比较感兴趣的。

开场的Keynote是eBay的Oliver Ratzesberger的 Enterprise Analytics on Demand。eBay每天的数据增量是50TB,而每天的数据处理量是50PB。这个presentation讲了相当多的规划方面的细节。

第一篇 DFS: A File System for Virtualized Flash Storage 介绍的是一个把卷管理(并不完全是:包含了Flash的wear leveling)和文件系统集成在一起的设计。FusionIO公司提供了一种直接在PCIe接口上插的存储设备。类似这样的设计,感觉是未来Flash文件系统必须要走的一条路。

第二篇 Extending SSD Lifetimes with Disk-Based Write Caches 是一个很有意思的设计:现时磁盘的反复擦写寿命要远好于Flash,因此,在磁盘上做一个顺序写入的日志,然后再择机将数据擦写回Flash。不过这篇论文讨论的具体方案还有一定的改进余地。

第三篇 Write Endurance in Flash Drives: Measurements and Analysis 是关于 Flash 寿命的衡量方法。

FAST 2010第一天

| 1 Comment | No TrackBacks

今天去参加了在San Jose举行的 FAST '10 第一天的 Tech Session,FAST是 USENIX 主办的关于文件和存储技术的学术会议。记上几笔。

开场的Keynote其实讲的还算精彩,不过感觉跟会议本身关系不大(讲的主要是发展中国家的手机等设备的发展),就不介绍了。

Build a Better File System and the World Will Beat a Path to Your Door部分。第一个是本次的获奖论文 quFiles: The Right File at the Right Time ,具体来说是实现了同一份data(文件)的不同view(例如,将其表现成不同分辨率、码流等)的一种通用的存取方法。个人对Semantic File System持保留态度,不过这个talk还是可以帮助拓宽一下思路。

第二篇是介绍在 WAFL 类型的文件系统(具体举例是 btrfs) 中实现倒排索引的 Tracking Back References in a Write-Anywhere File System。具体来说,是在 inode -> 块这样的单向关系基础上,增加了块->inode(包括inode版本、回收时间等)的倒排索引。paper值得看但是性能比较做的稍微有些瑕疵(用做B-Tree的时间去比较在FS中查询的时间,而没有比较建立倒排索引之后更新与在block中插入信息所引起的开销,以及两者对应的查询时间)。

第三篇指出了内存故障可能导致的问题,指出 ZFS 的 end-to-end 检查只能检测出磁盘介质或控制器偶然故障引起的问题,而系统主存中存在的问题则无法发现并可能导致数据损坏甚至系统崩溃,并提出了在 ext2 FS 中增加运行时checksum检查的方案。这篇的试验方法和结论受到了很多人的质疑。

午饭时间。

车棚该漆什么颜色?

| 1 Comment | No TrackBacks

很多争论其实是源于沟通和理解。人们的理解能力往往是有限的,这些限制很可能来自于不同的教育背景、知识面等等,因此,为了更好地理解对方,人们往往习惯于使用 自己熟悉的 知识去设法理解对方所说的。

这带来的一个现象,在技术人员之间的讨论中,就会是这样:例如,讨论应该怎么造一枚火箭,往往不会有人去随便做评论,因为他们很清楚自己并不是这个专业的人,而这件事明显需要许多非常专业的知识;而如果讨论火箭发射基地的车棚应该漆成什么颜色,则几乎每一个人都会去发表自己的意见,因为车棚的颜色是什么样子,在多数人看来往往没有造火箭那么重要,并且,似乎每个人都能够胜任这样的决策。

将讨论如何造火箭的话题,阴差阳错地变成一群人争论火箭发射场外面的车棚应该漆成什么颜色,就是我们所说的 Bikeshed 现象。

我在这一天时间里遇到了两次这种问题。第一次是我自己把冯牛说的税的算法问题想错了,第二次是我的关于什么时候该用线程的问题被另一个人活活 扯成了 线程 vs 进程的开销问题。

解决 bikeshed 是需要时间的。不过,每一个参与讨论的人,其实都可以尝试使用一些方法来减少这种情况的发生。例如:

头脑空白原则:如果对方讨论的是一个你认为自己很熟悉的话题,不要首先根据自己的理解去下结论,而要先看清楚对方到底在说什么。许多时候,我们自己的知识背景会限制我们能够看到的问题的范围,很可能对方想要讨论的并不是这些东西。

在发现争论持续了很长时间,双方各执己见时,暂时停止讨论,而不是继续论证自己的观点。一个观点的对错取决于观点本身,而不是争论双方所说的话。

避免情绪化的语言----那不会增加你的说法的说服力。

很多事情都有Do's and Don'ts,这里试着整理一下与安全有关的。

本文版权所有 © 2010 Xin LI <delphij@FreeBSD.org> 保留所有权利;非商业转载请注明出处 http://blog.delphij.net/, 谢绝商业转载。

安全不能建立在"别人不知道"的基础上

"别人不知道"是一种非常常见的安全 假象,举例来说,一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等,都属于这一类。

将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像,这会直接导致与系统交互的人放松警惕;其次,这样的设计往往留有"后门",甚至是设计者不知道的后门(因为往往他们并不对这类设计进行充分的、专业的审计),容易被攻击者利用;最后,这种做法存在第三方泄密问题,即,使用这种系统的人,需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。

延缓攻击的手段不能用来阻挡攻击

有许多延缓攻击的手段,例如改变服务的端口(比较常见的如将 ssh 改为 tcp/22 以外的端口),或禁止服务程序显示自己的版本等等,或仅仅简单地启用防火墙,这些手段起到的作用只是延缓攻击,而不应作为一种安全屏障。对于多层次式的安全设计来说,采取这些措施有助于提高检测到入侵的机会,但是它们本身并不会提高安全性。

与前一种情况类似,这种做法也只是让管理员放松警惕。例如以 ssh 为例,有人认为将端口改为一个非知名端口可以避免相关的攻击,但事实是,攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中,包括简单的 port knocking 一类的保护手法,都可以使用类似分组重放这样的方法来逐步攻破。

采用层次式的安全设计

所谓层次式的安全设计,说的是在一套安全系统中包含不同层次的、存在层次式监控关系的安全结构。例如,将本地包含执行文件的那些文件系统通过一定的方式导出给监控网段的机器,就可以让那些机器在攻击者不知情,或至少不太容易注意到的情况下对入侵进行检测;通过将一些重要日志发到以不同的访问控制机制,甚至不同网络协议的记录设备上,则可以有效地检测入侵者的入侵行为,并为日后的分析留下更多的有用信息。

层次式安全在现实中也有应用。例如产品的质检,除了制造商自己进行的质量控制之外,有时分销商或政府也会进行一些抽样的检查。我们注意到,这些设计中的一个重要的特点是在不同的系统中使用不同的访问控制逻辑。例如,日志服务器必须从特定的客户端,甚至只能从某些隔离的内网登录。此时,延缓攻击的手段可以作为它的一项辅助设施,即其目的并不是阻止攻击,而是吸引攻击者在攻击目标上花费更多的时间,从而帮助入侵检测机制更容易地检测这些攻击。

不要轻信任何东西,包括X.509证书

安全系统的设计者必须对安全有全面的理解和认知。有一句很著名的话叫做 In God we trust, all others must submit an X.509 Certificate,需要注意的是,这里说的是 must submit,并没有说 submit 了就可以 trust 了。

和前面所说的层次式安全设计类似,我们的一个基本假定应该是,一个安全系统中的任何参与者,无论是用户还是计算机或程序,都是可能存在弱点的。安全系统,或用户,都不应轻信任何东西,例如,在特权隔离 (Privilege Separation) 这样一种设计中,特权进程除了完成那个非特权的子进程的请求之外,还有一个任务是维护一个"理性状态机"(Sanity DFA),这个状态机的作用是检测非特权进程的异常状况,如果发生这样的情况,则特权进程有拒绝提供服务,并杀掉非特权进程的责任。作为用户,对于系统给出的响应,除了验证对方的证书之外,也应有常识性的了解和适当的判断。

李献计历险记

| 2 Comments | No TrackBacks

法师推荐的一个 短片,有关好爱情和不朽,我们还有很多不知道的。

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.3