选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
指望硬盘不挂掉是 很拼人品的事情（附带说一句，从某种意义上说，21世纪的硬盘质量并没有下降，只是单位容量出现故障的概率没有显著提高，而硬盘容量的扩大使得单块硬盘的故障率看起来提高了，但是如果我们从单位容量的故障率来看，坏损率并没有非常显著的增长）。所以想要长久地保存数据，就必须采用各式各样的冗余和备份手段。冗余和备份是不一样的，前者往往会采用同样的访问控制逻辑，提供在线或近线的数据存储，强调的是数据访问的及时性；而后者则强调的是数据的可恢复性。
关于访问控制
一般来说，不希望备份与原始数据采取相同的访问控制机制。例如，对网站来说，可以读写数据库的那个 Web 访客的数据库账户，很可能并不能直接读写网站的备份数据。有时，备份甚至是以一种"外科手术"的方式进行的：对文件系统做快照，然后将快照打包发到异地的另一套系统。
采取不同的访问控制机制有很多好处。备份的目的之一是保护先前版本的数据不受影响。举个现实生活中的例子，公司的账簿可能会影印之后放到档案寄存机构，而公司会计可能并不负责，甚至没有权限去调出账簿副本。在这个例子中，由于副本和正本由两个角色分别负责，为确保其不被其中任何一个人恶意篡改提供了一定的保障。
对于服务器或桌面系统，这种控制也同样重要。例如，用户可能有权限删除自己的文件，但不应有权限以同样的方式删除或修改备份。这种限制可以缓解由于误操作或入侵（例如木马、或特权提升）导致的损失。这一点是备份与冗余之间的重要区别。
推 or 拉？
两种方式各有利弊，但我个人比较倾向于使用拉（即备份机登录原始数据的机器）的方式而不是推的方式。原因是备份机往往可以设置更为严厉的安全策略，例如放在防火墙后面，等等，而攻击者在入侵成功之后，想要找到备份机在什么地方也需要一些时间，从而给检测入侵创造条件。推的方式的优点是可以比较方便地控制何时备份，以及备份的I/O占的比例，不过，通过合理地设计备份系统，并不是拉的方式并不是完全不能实现这类功能。
关于异地备份
将备份与原始数据放在同一个物理位置（例如同一个机房、同一棟建筑、同一座城市，甚至同一个省或同一个国家/大洲）很可能是有风险的。一般来说，副本与原始数据的距离越远，从备份的可靠性角度考虑便越有把握，同时，将备份设在电费和托管费用较低的二三线城市，也可以在一定程度上降低整个系统的运营成本。
离线备份
离线备份往往用于保存非常有价值并且不经常改变的数据。例如将数据刻录成光盘邮寄给不同大洲的人，等等。不过，离线备份的问题是其访问控制很可能不太容易，想要解决这个问题，可以采用门限加密的方法（例如，将数据分成三份，密钥也分成三份，给三个备份点分别发第其中的1，2；1，3；2，3，在这个方案中，攻击者必须掌握三份备份中的至少两份才能够恢复密文内容）对数据进行处理。
Read more...今天看到一则消息说，百度搜索支付宝会找到一个钓鱼网站（现在应该已经撤掉了）。去那个钓鱼网站看了一眼，发现居然是装的正版支付宝插件。
相信插件能保护客户的安全的人可以洗洗睡了，你们根本__不配__说"安全"两个字，除了供一两个三流技术人员拿大量客户计算机的安全开玩乐和练手之外，这些控件没有价值。
Read more...续前。
除了硬件上直接采用的降噪措施之外，一些软件方面的配置也可以提高其效果。
首先是BIOS中的配置。风扇转速最低可调整为"Energy Saving"（即使用30%的频率）。启用Active Power State之后，可节省大约2W左右的耗电（这个选项的默认值是Disabled）。
然后是FreeBSD本身的配置。我个人采用的配置包括：
上述设置，除了ahci部分之外，可将系统闲置时的功耗降低到17W左右。
以下是实现中采用的loader.conf相关的部分：
hint.apic.0.clock=0
hint.atrtc.0.clock=0
hw.pci.do_power_nodriver=3
hint.ahcich.0.pm_level=5
hint.ahcich.1.pm_level=5
hint.ahcich.2.pm_level=5
hint.ahcich.3.pm_level=5
hint.ahcich.4.pm_level=5
hint.ahcich.5.pm_level=5
最近遇到一些奇怪的bug，因为是对恢复时间有比较高要求的系统，所以顺便研究了一下用FreeBSD的textdump来代替更早前出现的minidump的方法。
minidump是2004年初提出的，FreeBSD 6.2-RELEASE开始加入了这个功能，并且在7.x开始默认启用。具体原理是在panic时做dump的时候只存储那些映射为内核内存的物理内存页。这种做法实际上是赌VM的页表在崩溃的时候没有被写坏（绝大多数情况下这是成立的，除非在调试VM本身）。
UPDATE: 杨总 说，Solaris上有一个叫 Fast Crash Dump 的功能。看了一下介绍，是在dump的时候用指定的压缩算法去压缩再转存。先记一笔。
textdump是Robert N. M. Watson在2008年提出的一个新概念，从7.0-RELEASE开始引入：
在编译内核时，需要加入内核调试器。
指定的 ddb 脚本可以挂在某个特定的事件上，比如 panic 进入 kdb 时自动执行
系统提供一个默认的ddb脚本，保存下面这些信息：
启用textdump是需要内核调试器的，因此有一定的安全风险，例如可以从控制台进入ddb。使用时的内核编译配置是options KDB、 DDB和SC_DISABLE_KDBKEY（禁止在控制台热键呼出调试器），然后在 /etc/rc.conf 中加入 ddb_enable=“YES” 令系统在引导过程中将ddb脚本汇入内核，并指定dumpdev。
需要注意的是目前textdump与KDB_UNATTENDED不兼容，因为后者会令内核不调用调试器而直接重启。
textdump保存的内容非常少，因此可以大大减少dump所需的时间。
Read more...最近找时间做了一个家用的路由器。用基于 Intel Atom 处理器的解决方案并不便宜（与传统的嵌入式解决方案相比），但因为软硬件都是 x86，因此开发起来会方便一些。另一方面，Atom的计算性能要远高于其他的传统嵌入式方案。
配置：
SMCI这款X7SPA-H主板采用的是ICH9R芯片组，有6个SATA接口，支持AHCI。采用4G内存的原因主要是希望使用ZFS，同时作为存储服务器使用。由于空间原因，这款CPU使用被动散热片。
PC-781机箱可以配置外接的直流电源（类似笔记本的电源）。采用这种配置的考虑是外接电源不需要使用风扇散热，整个机箱总共只有1个小风扇（题外话：因为功率不大，实际上这个风扇并不是必须的），从而减少噪声。
由于没有光驱，因此使用U盘以memstick映像来安装。在 sysinstall 中选 FixIt » USB 之后就可以手动安装了。
关于磁盘布局：WD AV-25使用的是WD的"Advanced Format"，即4k扇区的格式。由于对系统而言扇区仍然是512字节，因此在分区时应以8扇区对齐。这块硬盘的GPT分区为：
34开始，94扇区：boot
128开始，16777216扇区：swap
16777344开始到结尾：zfs
（待续）
Read more...早期版本的 FreeBSD 有一个问题是，如果使用 ntpd 来校准系统时钟的话，如果长期开机，则在重启之后，时间会差很远，之前一直没仔细研究这个问题。最近突然发现 FreeBSD 8.1-RELEASE 里面没有这个问题了，于是翻看了一下代码和之前的一些邮件才明白是怎么回事，总结一下：
一般来说操作系统在引导以后会自行维护时钟，简单地说，就是操作系统根据某个时钟源，例如单CPU系统中的TSC，或多CPU系统中比较常用的高精度事件计时器HPET等等，计算出时间的流逝并修改系统时间。只有在系统刚刚引导的时候，才会直接取 RTC 时间（在关机时，主板上的电池仍可维持 RTC 电路的计时功能）。
我们知道，任何测量工具都是有误差的，普通的 PC 系统上配置的计时装置肯定不会做的非常精密，这也是我们为什么要运行 ntpd 的主要原因。在系统运行的过程中，这些误差不断地积累，使用 ntpd 时，系统可以计算出所采用的时钟源与实际的时间之间的误差，并逐步调整时间源的计数周期与实际时间的比例，从而维持系统时钟的精确性。
在重启时，在内存中维护的系统时刻数据便随之丢弃了，操作系统再次启动时读取的是先前未经修正过的、继续在积累误差的 RTC 时间数据（注意：RTC是不依赖于OS运行的；OS可以修改其时刻数据，但无论开机还是关机，只要维持其需要的电流即可确保 RTC 继续自行更新，而无需 OS 干预）。
FreeBSD先前的实现中，只有非常少的地方调用了 resettodr(9) 来修正 RTC 时间，这些地方主要是settimeofday()之类的直接设置内核时刻数据的点，而对于 ntp 的情况，则没有相应的处理。
新的实现 (以r207360为主体，包含r207359, r207362）则增加了一个callout，每半小时将系统时钟刷回RTC一次，从而解决了这个问题。
关于为什么不应该使用 ntpdate 来对时（ntpdate会使用settimeofday()），请参考 A core 的 这篇 介绍 NTP 的文章，以及我的 这篇 文章。
Read more...这几天改 FreeBSD 的 coretemp(4) 遇到了一个问题。直接使用 rdmsr 的话，如果那个 MSR 不存在，则会触发 #GP(0)，不了解 CPU 型号的情况下直接去杵肯定是不行的。后来翻了一下 cpuctl(4) 的代码发现 FreeBSD 上也有 rdmsr_safe。它的实现并不复杂（ sys/amd64/amd64/support.S）：
movq PCPU(CURPCB),%r8 // %r8 = PCPU(CURPCB); 将当前CPU的编号保存到r8。
movq $msr_onfault,PCB_ONFAULT(%r8) // 设置发生异常时调用msr_onfault。
然后是翻译 AMD64 ABI：
movl %edi,%ecx // 参数1放到ecx
rdmsr // 实际执行rdmsr（将ecx指定的MSR的高、低32bit结果放到edx、eax中）
salq $32,%rdx // rdx <<= 32
movl %eax,%eax // 将rax最高32 bit清零
orq %rdx,%rax // rax |= rdx
movq %rax,(%rsi) // rax 存入 *rsi
xorq %rax,%rax // 返回值默认为0
最后恢复先前的异常处理状态。
Read more...SSH提供了很多种不同的身份验证，其中最常用的两种便是密码验证和基于公钥/私钥的身份验证。
基于公钥/私钥的身份验证有非常多的优点。
首先，公钥/私钥可以从根本上挫败监听来截取验证信息的企图。
公钥/私钥验证本质上是一种 零知识证明。即，在身份验证的过程中，服务器并不需要知道用户的私钥是什么。【注：公钥/私钥验证并不是零知识证明，感谢 snnn 指正。】
公钥/私钥验证在身份验证的过程中，服务器只需要知道用户的公钥，而用户则使用自己的私钥对一组数据签名，并在服务器端进行验证。服务器并不需要知道用户的私钥。目前为止，还没有有效的方法能从这些信息推导出私钥。
与密码相比，这种方法有显著的优点：在验证身份的那一方，没有任何办法可以拿到用户的私钥，即使获得了那台机器的root权限。验证信息只能使用一次—-这意味着，也没有办法把这个验证信息用于在其他地方再次验证身份。
其次，公钥/私钥要比密码长的多，因而可以挫败通过穷举的方式破解的可能性。
典型的密码是8位字符，假设可以使用大小写字母、数字和特殊符号，可选的范围无非是96^8而已，我们不妨算它128^8。典型的私钥有2048个bit，如果按7个来分组的话，有128^(2048/7)。当然，最高位和最低位一定是1，但向下取整，也有128^292种。
最后，除了吃点带宽之外，SSH口令穷举对于仅采用公钥/私钥验证的服务器安全不构成任何威胁。
通过适当的配置sshd，可以让其直接明确地告诉对方此处不支持口令验证，并且能够容易地将攻击者记录在案，并将数据反馈给防火墙来减少带宽的占用。
Read more...本文主要是笔记，不保证其正确性，也不保证其不导致死机、崩溃或任何其他问题。
CPU的Tj(max)值可以通过读 MSR IA32_TEMPERATURE_TARGET，即 0x1a2 来获得【1】。目前，Intel正式的开发文档中并没有明确对这一MSR进行说明。早期的CPU中，Tj(max)值需要加上40到50摄氏度，目前不清楚具体哪些CPU必须如此，但从公开文档来看，已知：
Xeon 7100系列需要加修正值。其中，150W TDP的CPU需要加50摄氏度；95W TDP的CPU需要加40摄氏度。【2】
Xeon 5200系列不需要加修正值。【3】从文字上推测，5200以后的系列都不需要加修正值。
Xeon 5400系列不需要加修正值。【4】
使用LGA771 SMT socket、L3 cache不超过8M的Xeon MP系列需要加修正值50摄氏度。【5】
双核 Xeon 2.8G 处理器（根据文档推测，Prescott、Nocona和Potomac系列）需要加修正值50摄氏度。【6】
系统总线800MHz的Xeon处理器需要加修正值50摄氏度。【7】
双核Xeon 5000系列需要加修正值60摄氏度（没错，是60摄氏度，不是50摄氏度）。【8】
Xeon 7400系列不需要加修正值。【9】
支持超线程的Mobile Pentium 4处理器需要加修正值50摄氏度，同时，这个值的范围是0-30摄氏度。【10】
姑且推断5200系列之后不需要修正值？（model 0x17之后）能够公开获得的文献中，提到这个寄存器最早的一份是2004年6月出的第一版。
FreeBSD目前不支持从这个MSR直接搞Tj(max)温度出来，我做了个patch，测试了Xeon L5630和Core i7 CPU，不过其他的暂时还没测过。
Linux驱动这部分逻辑很让人费解（drivers/hwmon/coretemp.c）：如果读MSR得到了有效的值（80-120之间，而文档【1】上说的至少70度是存在的。如果读MSR失败，或驱动认为值无效，则用了一套相当奇怪的逻辑去猜测实际的数值，某些型号的Atom使用旧的逻辑去判断，等等。问题是(1)这段相当的混乱，而且与文档有很多不一致的地方；(2)为什么不先判断CPU型号再访问MSR呢？
参考文献
【1】CPU Monitoring With DTS/PECI。Intel 文档编号322683。
【2】Dual-Core Intel® Xeon® Processor 7100 Series Datasheet.Intel 文档编号314553。
【3】Dual-Core Intel® Xeon® Processor 5200 Series in Embedded Applications, Thermal/Mechanical Design Guidelines。Intel文档编号319012。
【4】Quad-Core Intel® Xeon® Processor 5400 Series, Thermal/Mechanical Design Guidelines。Intel文档编号318611。
Read more...“如果我当年去问顾客他们想要什么，他们肯定会告诉我：‘一匹更快的马。’” 这告诉我们：顾客的意见虽然重要，但是只问用户的意见是做不出突破性的新产品的。
Read more...