delphij's Chaos
选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
截止到目前为止, FreeBSD 基金会共募得本年度捐款 $461,119,距本年度的预定目标 $500,000 还差 $38,881 美元。今年 FreeBSD 基金会资助了相当多的项目,包括 Pawel Jakub Dawidek (pjd@) 的 Capsicum 框架、分布式审计服务 auditstd、与我厂一起资助了 Bjoern Zeeb (bz@) 对 FreeBSD IPv6 协议栈的性能剖析、Edward Tomasz Napierala (trasz@) 的在线 UFS 扩容,作为中介机构接受了 Semihalf 的 NAND 闪存文件系统和存储棧,并资助了与此相关的移植工作。此外,FreeBSD 基金会也资助了全球范围内与 FreeBSD 开发有关的一系列会议,包括欧洲的 EuroBSDCon、亚洲的 AsiaBSDCon、加州 MeetBSD、加拿大 BSDCan、澳大利亚的 BSDDay 等,并在硅谷和剑桥大学分别举行了 Vendor Summit 和 Developer Summit。
FreeBSD 基金会每年会增加 10% 到 25% 的资金投入,这些投资的成长离不开广大 FreeBSD 用户和开发人员对于基金会的直接资助支持。作为符合美国税法 501(c)3 条款的公益非盈利慈善法人,在美国境内的捐款人通常都可获得全额联邦应税收入抵免。
捐款网址: http://www.freebsdfoundation.org/donate/。
其他信息请参见 捐款将用来做什么、基金会2012年12月公告、如何申请资助、基金会财报。
Read more...我回国之前, FreeBSD 安全团队内部正在准备一项重要的安全公告,不过这次不是由于 FreeBSD 的代码本身,而是由于 FreeBSD 项目集群中的一部分受到了入侵。这份公告后来于 11 月 17 日正式 发表。
经过事后分析,这次入侵,最早可以追溯到在今年大约9月的时候的一次针对某家公司的入侵。攻击者通过穷举的方式获得了这家公司一台机器的 root 账户,并获得了对应的 master.passwd 文件。根据事后的日志分析,攻击者应该是通过离线破解的方式得到了这台机器上所有用户的密码明文(旧式 FreeBSD 系统预设的散列方式是 salted MD5),并以这台机器为跳板扫描了一系列的其他系统,并找到了一位 committer 的未经保护的 ssh 私钥。这个私钥令攻击者获得了另外一台服务器的权限(其中包括一台机器上的 root 权限),并在那台服务器上进一步获得了另外一位 committer 的未经保护的 ssh 私钥。
那位 committer 的 ssh 私钥拥有 FreeBSD 用于联编预编译包的 Pointyhat 集群的 root 权限,而这个集群尽管和 FreeBSD.org 集群在一定程度上是隔离的,但在最初建立时,为了方便,以只读方式挂载了 FreeBSD.org 集群所有用户 /home 目录的 Filer。由于两组集群上都启用了内核审计机制 (audit),集群管理员发现,有人以 root 的身份访问了部分用户的 /home 目录,并很可能复制走了一些私钥文件。
至此,我们认为整个集群已出现了重大安全风险,应立即停止有风险的服务器的运行,并根据备份对全部文件进行审计。除了切断了大部分服务器的电源之外,扫描并停用了所有在 FreeBSD.org 集群上存有私钥的公钥的登录权限,对某些系统上运行的操作系统替换成了经过审计的 -CURRENT。
由于时间关系,不可能对每个二进制包都重新做审计,因此比较简便的办法,便是全部删去,从备份中恢复没有问题的,并重新联编其他的二进制包。为了尽快恢复服务,这次经过讨论还做出了准备提前淘汰 CVSup 的计划。
公众可见的变化包括:
我从这次事件中学到的教训是:
Read more...这次回北京之前的周末,FreeBSD安全团队发表了内部通知,发现 FreeBSD.org 有些机器被入侵,最近终于做了全面披露了。目前,基本的代码审计和攻击检查已经做完,部分机器还在重装的过程中。
对 FreeBSD 这样的开源项目来说,在基础设施遭到攻击之后,首先必须被怀疑的便是有可能有人在代码库中植入了新的后门。由于代码量十分巨大,逐行审计是非常不现实的。由于 FreeBSD 在 BSD 时代即采用了版本控制系统(最早 BSD 时代是 SCCS,FreeBSD早期是CVS,现在是 subversion),因此,每一行代码的来源,包括作者、具体的修改时间,以及为什么那样修改等等,都可以很容易地查找到。
FreeBSD 采用了许多种不同的方法来同步修订历史,这包括了旧式的 CVSup、通过邮件的 CTM,以及 svnsync。CVSup类似于rsync,但是是为 CVS 优化的。FreeBSD 的 CVS 代码库之前是通过 SVN export 出来,然后通过CVSup发给所有的下游镜像,其好处是比rsync节省带宽和时间(因为CVSup会记录修改的文件信息,两相比较便不必完全传送文件的 stat 数据了),缺点和 rsync 一样,如果源站点的数据出了问题,备份也会被修改,而且是不可逆的。CTM和svnsync都是类似会计记账的方式,也就是说一旦有了修改便不可反悔(CTM更通过邮件发出,从而可以被第三方备份服务永久性记录),从而便于审计。
所幸的是,目前为止的调查中,并没有迹象显示 CVS 代码库或 subversion 代码库中混入了任何未经授权的变动。为了保险起见,FreeBSD.org 的管理员将 cvs 改为从 subversion 完全导出(因为 svn 的审计比较容易)覆盖,以避免某些没有检测到的问题给用户带来影响。
我们能够从这个事情中学习什么教训呢?我想,最重要的是,备份应该采用和源数据不一样的更新、删除逻辑,因为这样才可以知道具体发生了什么变化。也就是说,数据源这边在备份那边的权限应该是不能改变历史记录数据的,比如只允许添加,等等。
关于这次入侵的具体情况,等有时间再写出来。
Read more...FreeBSD Vendor Summit 是定期举行的使用 FreeBSD 的公司的交流会,这次是在 Yahoo 总部举办。不过,早上因为没有注意收听广播,结果在 237 上堵了半个小时,到会场的时候已经在演示 VTune 了。
Intel 的 VTune 是 Intel 非常好用的一套性能剖析工具。经过将近两年的不断努力,目前 Intel 已经可以提供用于 FreeBSD 的探测模块了,把生成的文件复制到安装了 VTune 的机器上,即可完成各种分析工作。Intel 的 Jim Harris 做了详细的演示,如果对购买和授权感兴趣,可联系 Intel 的销售 Greg Anderson (greg.anderson%intel.com)。预计2013年发布的 VTune 版本更新将内建相关驱动的源代码(BSD许可;如果现在就需要的话请和 Jim 联系),今天我们还讨论了关于把这些驱动直接放进 FreeBSD 的可能性,但估计需要另外走 Intel 内部的审批流程批准。这一进展相当令人振奋。
Warner 今年没有来参加 Vendor Summit,所以 Adrian 向大家介绍了近期 FreeBSD 在嵌入式方面的进展。内容和前几天 MeetBSD 的 Dev Summit 区别不太大。Robert Watson 强调了 Raspberry Pi 和 FreeBSD 之间有良好的关系,而且 Raspberry Pi 非常适合做教学用途。目前,FreeBSD 已经有了可以适用于不同 ARM 平台的、类似i386的通用内核,未来希望进一步发布不同的image来帮助新手完成安装。MIPS方面,现在有 zRouter 项目,目标是做一套完整的、类似 OpenWRT 的平台,其成果也正在逐渐合并到开发主线。
下午,后藤大地 (Daichi GOTO) 介绍了他的公司在日本推广 BSD 的情况,虽不明但觉厉。他提到了一些遇到的问题,例如 InfiniBand 性能等等,我想等段时间和他联系看看是不是有什么可以共享的资讯。
Read more...昨天是会前的开发人员峰会,参加的人基本都是 src/ committer。我参加的讨论是 安装、虚拟化和存储。关于安装程序,目前基本的共识是 bsdinstall 需要重做(基本上 bsdinstall 是个 drive-by commit,作者现在态度是管杀不管埋,bug很多),而先前 Devin Teske 所做的 bsdconfig (目前未接入 world 联编,试了一下太 XX 复杂和强大了)和 DruidBSD 有很多东西可以添到安装程序中,而一票 committer 也已经为他撑腰,所以应该问题不会太大。
虚拟化方面,主要讨论了目前的现状。 Yahoo 在这方面做了一些工作,并将继续跟进。Sean Bruno 大致介绍了目前可用的驱动,NetApp 的开发人员着重介绍了他们的 BHyVe 的成果(普遍的意见是这些成果应尽快合并进 -CURRENT 主线)。此外, NetApp 和我们还讨论了关于微软 HyperV 支持的合并问题,目前微软的 HyperV 代码已经较为成熟,但合并还有一些非技术问题需要解决。
存储方面,讨论了目前遇到的一些问题。我同时处理了一个 mfi(4) 在操作超过 2TB 容量硬盘时的数据损坏问题,不过,这个修正已经来不及合并到 9.1-RELEASE 了,目前的想法是通过 Errata 方式先列出,等过一段时间以二进制更新的形式同代码一起发布。
今天是 MeetBSD CA 2012 的第一天。早上第一段是 NetBSD 的 David Maxwell 主持的讨论,实际的技术讨论不多。之后 Adrian Chadd 介绍了近期 FreeBSD 嵌入式方面的发展,目前 ARM 已经有了类似 x86 的通用内核(主要是 Warner Losh 的成果),并推荐大家尝试 Raspberry Pi。MIPS 方面,新加入的一批 committer 也有了相当多的成果,其中, zRouter 是 D-Link 的 Aleksandr Rybalko 主持的项目,目前已经支持多种无线路由器,等等。目前的问题是基本系统中仍有很多可以优化的空间,而高通 Atheros 也会继续支持相关的开发活动,包括 FreeBSD 的 wifi 支持。
Read more...多年之前,老贾说过,对什么人都不能太好了,认识的,不认识的,都是这样。我觉得这方面我就是一直不觉悟。
最近有个人没事就在MSN上问我一堆问题,而这些问题完全是文档写得清清楚楚,或者稍微试一下就能知道答案的。我觉得我之前纯粹就是犯贱,照说,对这种问题应该直接假装看不见,本来咱也不认识,何必呢?
今天这哥们总算把我惹毛了,我这边改着patch,那边一条一条拼了命的发,当然,我的口气也不怎么客气,原文照登如下:
我擦,你丫不能自己查下文档么?要不付我点咨询费?有问题发到论坛去,别没事老跟im上问,我没义务支持私人的请求
嗯,是不太客气,于是,这哥们教训了我:
厚道点儿,你没亏吃
说到厚道嘛……只好先拉黑两天了,什么时候出来,看心情。另外:
总算是 命名了……现在 re@ 已经开始拒绝所有的变动请求,包括前几天的 High Point Technologies 驱动更新。不出意外的话,两周之内应该会正式 release 了。
Read more...前几天做一个解离散对数的题用到了 gmpy,它是 GMP 的 Python 封装,用来算大数。
这里记两笔。首先是大整数需要用 mpz 对象,例如:
p = mpz(13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084171)
判断大数是否是质数:is_prime(p) (求离散对数其实用不着)
求逆元 (x^-1):invert(x, p)。例如, y = invert(x, p) 则 x*y % p = 1
幂取模:pow(x, n, p),即 (x ^ n) % p。结果仍为 mpz。
mpz对象可以直接用在dict中做键值。
题目中提供的方法是分治,将解 x 拆成两部分 x0*B+x1,其中B是2的整数次方幂(约为x上限的开方,例如如果x的范围是2^40,则B=2^20)。这样 x0, x1 分别小于 B,将方程整理成 x0, x1 分别在等式左右(其它部分都是常数了),然后穷举 x0 对应的值(计算2^20次,保存所有结果),然后穷举所有的 x1对应的值,如果发现之前保存的结果中有匹配,则输出对应的 x0, x1,从而算出x。由于将搜索范围变成了sqrt(N),所需的时间也就大大减少了。
Read more...注意:这是我个人对于相关资料的理解和整理。具体问题请咨询专业人士。
1983年7月1日生效的加州法律规定,核税官需要在所有权发生变动,或有新增建筑时重新评估房地产价值。发生这种情况时,纳税人可能会收到一份或两份补充税账单。
补充税账单是由于少缴了一部分税。以账单附带的例子来说,如果交易发生之前房子的税基是 $360K(加州 1978 年公投通过的 Proposition 13 规定,除变更所有权或新建建筑之外,每年的税基增加不得超过2%,而由于人口的迅速增加,多数房屋的税基会比实际的估值要低很多),而交易价格是 $460K,则纳税人需要为增加的这 $100K 额外补充缴税。应缴金额应该是这 $100K * 税率。
不过,由于地产税是每半年缴一次,而交易不一定在什么时候发生,因此补缴税款要按交易的月份去折算。地产税的财年是每年7月1日到第二年的6月30日,为了方便描述,我们姑且把1-6月所在的那个财年称作"上一财年",也就是去年7月到今年6月的那个财年,而把7月到12月所在的那个财年称作"下一财年",也就是今年7月到明年6月的那个财年。
如果交易发生在7月之前,则对上一财年的补缴额系数是 (6-月份)/12。由于纳税人在7月份之前获得了产权,因此也就有责任补缴下一财年的全部税差(郡政府发出的第一份下一财年的地产税账单仍然是按照不超过2%递增的)。
如果交易发生在7月或7月以后,由于不涉及上一财年的税,因此无需为上一财年补税。而相应的,对下一财年的补税,则是按 (18-月份)/12 来计算。
实际操作中,这些系数只取两位有效数字。
Read more...