Yasuoka's hack log (2012年)
2012-05-14
- Android L2TP/IPsec トンネル内の TCP がおかしい::
- 12:35:50.235719 10.0.0.43.44265 > 10.0.0.1.80: S 2846766254:2846766254(0) win 5040 <mss 1248,sackOK,timestamp 5398432 0,nop,wscale 1> (DF) 12:35:50.235749 10.0.0.1.80 > 10.0.0.43.44265: S 2199195960:2199195960(0) ack 2846766255 win 16384 <mss 1260,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2597316971 5398432> (DF) 12:35:50.654491 10.0.0.43.44265 > 10.0.0.1.80: . ack 1 win 2520 <nop,nop,timestamp 5398468 2597316971> (DF) 12:35:51.711359 10.0.0.43.44265 > 10.0.0.1.80: P 1:517(516) ack 1 win 2520 <nop,nop,timestamp 5398468 2597316971> (DF) 12:35:51.711640 10.0.0.1.80 > 10.0.0.43.44265: . 1:1237(1236) ack 517 win 2163 <nop,nop,timestamp 2597316974 5398468> (DF) ..... (a) 12:35:51.711670 10.0.0.1.80 > 10.0.0.43.44265: P 1237:2232(995) ack 517 win 2163 <nop,nop,timestamp 2597316974 5398468> (DF) 12:35:52.122338 10.0.0.43.44265 > 10.0.0.1.80: P 1:517(516) ack 1 win 2520 <nop,nop,timestamp 5398576 2597316971> (DF) 12:35:52.122362 10.0.0.1.80 > 10.0.0.43.44265: . ack 517 win 2163 <nop,nop,timestamp 2597316975 5398576> (DF) ..... (b) 12:35:52.360947 10.0.0.43.44265 > 10.0.0.1.80: . ack 1237 win 3768 <nop,nop,timestamp 5398664 2597316974> (DF) .... (c) 12:35:52.381020 10.0.0.43.44265 > 10.0.0.1.80: . ack 2232 win 5004 <nop,nop,timestamp 5398665 2597316974> (DF) 12:35:52.460760 10.0.0.43.44265 > 10.0.0.1.80: P 517:1057(540) ack 2232 win 5004 <nop,nop,timestamp 5398667 2597316975> (DF) 12:35:52.460955 10.0.0.1.80 > 10.0.0.43.44265: P 2232:2601(369) ack 1057 win 2163 <nop,nop,timestamp 2597316976 5398667> (DF) 12:35:52.659641 10.0.0.43.44265 > 10.0.0.1.80: . ack 2601 win 6240 <nop,nop,timestamp 5398690 2597316976> (DF)
(a) のパケットが落ちたのか? と思われるので、(b) で再送すると、即効で (a) の ack が返ってくる。生ネット上で TCP すると発生しない。
OpenBSD の ipsec は、たくさんのソケットオプションをもっている:
#define IP_AUTH_LEVEL 20 /* int; authentication used */ #define IP_ESP_TRANS_LEVEL 21 /* int; transport encryption */ #define IP_ESP_NETWORK_LEVEL 22 /* int; full-packet encryption */ #define IP_IPSEC_LOCAL_ID 23 /* buf; IPsec local ID */ #define IP_IPSEC_REMOTE_ID 24 /* buf; IPsec remote ID */ #define IP_IPSEC_LOCAL_CRED 25 /* buf; IPsec local credentials */ #define IP_IPSEC_REMOTE_CRED 26 /* buf; IPsec remote credentials */ #define IP_IPSEC_LOCAL_AUTH 27 /* buf; IPsec local auth material */ #define IP_IPSEC_REMOTE_AUTH 28 /* buf; IPsec remote auth material */ #define IP_IPCOMP_LEVEL 29 /* int; compression used */
しかしこれを使っているプログラムは、src 以下に見つからない。 IPsec policy の id だけ get して別インタフェースで取得したほうが 良いような気がする。
2012-05-05
happy birth day to me.
wchar_t 対応の nvi が更新された。 Experimental: editors/nvi 2.0.3 (UTF-8 vi) FLAVOR=iconv が足されていて、euc-jp なファイルも編集できる。 起動時にファイルエンコーディングを切り替えたい場合があるので、 次のようなシェルスクリプトを作って使っている:
% cat ~/scripts/eucvi
#!/bin/sh
#
FILE_ENCODING=euc-jp
EXINIT0="set fe=$FILE_ENCODING"
if [ -f ~/.exrc ]; then
EXINIT0="$EXINIT0 $(sed 's/set[ ]*//' < ~/.exrc | tr '\n' ' ')"
fi
EXINIT="$EXINIT0" exec nvi "$@"
%
2012-05-03
このページをモバイルデバイスでみた場合の見栄えを改善してみた。
3月下旬から、4月上旬にかけて accept() のエラーハンドリングが修正されていったが、 この問題は、accept(2) に追記された CAVEATS がわかりやすい:
CAVEATS When EMFILE or ENFILE is returned, new connections are neither dequeued nor discarded. Thus considerable care is required in select(2) and poll(2) loops.
accept() が EMFILE や ENFILE で失敗する場合は、 新規接続は、取り出されたり破棄されたりはしないので、select や pool の ループに手当てが必要となる。
2012-05-02
OpenBSD 5.0 の pthread は 1 コアしか使わない のプログラムを rthread 化された 5.1-current で実行してみた
load averages: 1.47, 0.78, 0.38 xxxx.xxxxxxx.com 15:19:18 28 processes: 26 idle, 2 on processor CPU0 states: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle CPU1 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU2 states: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle CPU3 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Memory: Real: 17M/101M act/tot Free: 134M Cache: 44M Swap: 0K/510M PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 14806 yasuoka 64 0 876K 716K onproc/2 - 0:02 86.04% a.out
CPU は 2 つ使えてるようだ。
2012-05-01
docomo SO-01C (Sony Ericsson XPERIA arc) を中古で 17,500 JPY で購入した。 購入後に知ったのだが、2011 年 3 月発売ということで、SIM ロック解除が行えないモデルである。 少し興味があったので SIM ロック解除方法について調べてみた。 (docomo または IIJmio の SIM で使うので、ロック解除の必要は個人的にはない)
SIM ロックを解除する「コード」は、 インターネットで $44.99 で販売されている のだが、docomo のファームウェアの場合、そのコードを入力するためのダイアログが表示されないように設定されているため解除できない。 その設定とは /system/etc/customization/settings/com/android/phone/custom_settings.xml の setting/disable-sim-network-pin-dialog で、これをエディタで true から false にしておけば、SIM 差し替え後にダイアログが現れるようになるらしい。 しかし /system 以下のファイルを編集にするには root 権限が必要となる。 Android では利用者に root 権限が与えられていないので、「root 化」と呼ばれる行為(たぶん違法) を行う必要がある。 root 化は、UNIX の local exploit で root を取得するのと同じストーリーで行う。 そして、攻撃に必要な一式はネットに堂々と出回っている。本日時点では DooMLoRD の v4 が最強っぽいが、(残念ながら?) docomo が 3/28 から配布し始めた firmware で穴が塞がれているらしい。 (突かれては塞ぎ、塞いでは突かれる、のいたちごっこ状態なのでは? と思われる) DooMLoRD の中身をみると、攻撃手順どおりのわかりやすいスクリプトになっていて、UNIX を知る人であれば、容易に理解できる内容となっている。
2012-04-26
- npppd。経路でハマる人結構多い。arp とか DHCP Inform とかやるべきか。
2012-04-25
- common-comment.html などの CAPTCHA は、あれこれ考えた結果、無意味な質問をしてみることにした。回答をチェックする関数は超ザルにしてあるのだが、 calendar.html への最初の書き込み (もう消した)は、不正解だけどザルはとおるような回答だった。
- gyazo の Linux 用クライアント 。ImageMagic が必要なのはイマイチ。スクラッチから書いても 1000 行いかないのでは? と思うんだが。
2012-04-24
calendar.html 用に、コメントを受け付ける CGI を書いた。
OpenBSD の jail 内の CGI なので、超特殊な感じである。 お名前とコメントを受け付けて表示する CGI で、受付時にメールでお知らせする機能も頑張って作った。 まだ CAPTCHA がないのでスパマーに対しノーガードだが、設置 1 日で、怪しげなリクエストが 2 件来ている。しばらくノーガードで相手の出方をみる。
2012-04-18
budydns が月 30 万クエリ以上の場合に有料になるらしい 。ダッシュボードを見ると、
なので、今は 58/300 Kqr/mo で、まだ大丈夫。
料金は月額で、10ドメインごとに 2USD、3Mqr/mon までが 1USD。3USD/月ということになり、36USD/年。これなら、友達に頼んで、飯おごったほうがいいな。
2012-04-12
新しいシステムコール getdtablecount(2) http://marc.info/?l=openbsd-cvs&m=133422896830004&w=2
2012-04-11
2003年に samba.org にバグ報告したのに無視されたことを思い出したので、ここに記録しとく。 報告はコレ http://lists.samba.org/archive/samba/2003-July/070700.html 。
2012-04-09
https://twitter.com/uebayasi/status/189143228879093760 から。
-0 を使うと input record separator を変更できる。 -0x20 とすると
% echo -n "hoge hoge" | perl -0x20 -ne 'print $i++ ." $_\n"' 0 hoge 1 hoge %
スペース (0x20) を区切りとして使えるようになる。-0 と -0777 は特殊で、-0 はヌル文字が区切りとなり、-0777 は「区切り文字なし」(slurp mode) を示す。実際には -0777 が特殊なのではなく -0400 (8進数で 1 バイトがオーバーフローする値) 以上を指定した場合 undef という意味らしく、 そういう用途では一般的な慣用として 0777 を使うらしいので、man perlrun などでも 0777 で説明されている、ということのようだ。
2012-04-07
bpf の pcap ファイルは、異なるシステム間で互換性を持っているか? 持つべきか
下の表のように、キャプチャデータの書式を決める DLT 型の値が OS ごとに異なるので、ここで互換性がなくなる。
| DLTラベル | OpenBSD | tcpdump.org |
|---|---|---|
| DLT_LOOP | 12 | 108 |
| DLT_ENC | 13 | 109 |
| DLT_RAW | 14 | 12 |
これだけでなく、FreeBSD の bpf.h では、:
struct bpf_ts {
bpf_int64 bt_sec; /* seconds */
bpf_u_int64 bt_frac; /* fraction */
};
struct bpf_xhdr {
struct bpf_ts bh_tstamp; /* time stamp */
bpf_u_int32 bh_caplen; /* length of captured portion */
bpf_u_int32 bh_datalen; /* original length of packet */
u_short bh_hdrlen; /* length of bpf header (this struct
plus alignment padding) */
};
と、bh_timesamp に 64bit 固定の時刻情報を持っている。しかし、 NetBSD では、:
struct bpf_timeval32 {
int32_t tv_sec;
int32_t tv_usec;
};
struct bpf_hdr {
struct bpf_timeval bh_tstamp; /* time stamp */
uint32_t bh_caplen; /* length of captured portion */
uint32_t bh_datalen; /* original length of packet */
uint16_t bh_hdrlen; /* length of bpf header (this struct
plus alignment padding) */
};
32bit 固定である。さらに tcpdump.org 版では、:
/*
* Generic per-packet information, as supplied by libpcap.
*
* The time stamp can and should be a "struct timeval", regardless of
* whether your system supports 32-bit tv_sec in "struct timeval",
* 64-bit tv_sec in "struct timeval", or both if it supports both 32-bit
* and 64-bit applications. The on-disk format of savefiles uses 32-bit
* tv_sec (and tv_usec); this structure is irrelevant to that. 32-bit
* and 64-bit versions of libpcap, even if they're on the same platform,
* should supply the appropriate version of "struct timeval", even if
* that's not what the underlying packet capture mechanism supplies.
*/
struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};
あくまで struct timeval であると主張していて、互換性を確保しているようには見えない。
2012-04-06
read error が多発して、file system へのアクセスが刺さった。 再度 ATA の attribute を記録しておく:
% sudo atactl wd0 readattr Attributes table revision: 16 ID Attribute name Threshold Value Raw 1 Raw Read Error Rate 62 99 0x000000030000 2 Throughput Performance 40 100 0x000000000000 3 Spin Up Time 33 176 0x001100000001 4 Start/Stop Count 0 100 0x0000000001c5 5 Reallocated Sector Count 5 100 0x000000000000 7 Seek Error Rate 67 100 0x000000000000 8 Seek Time Performance 40 100 0x000000000000 9 Power-On Hours Count 0 96 0x00000000080e 10 Spin Retry Count 60 100 0x000000000000 12 Device Power Cycle Count 0 100 0x0000000001c2 191 G-Sense Error Rate 0 100 0x000000000000 192 Power-Off Retract Count 0 100 0x000000000037 193 Load Cycle Count 0 43 0x00000008c2a7 194 Temperature 0 142 0x002e000a002a 196 Reallocation Event Count 0 100 0x000000000000 197 Current Pending Sector Count 0 100 0x000000000008 198 Off-Line Scan Uncorrectable Sect 0 100 0x000000000000 199 Ultra DMA CRC Error Count 0 200 0x000000000000 223 Load/Unload Retry Count 0 100 0x000000000000 %
2012-03-01
OpenBSD って、まだ IPv6 で NFS 使えないっぽい。
2012-02-28
OpenBSD の arp のタイマーって、monotonic じゃなく realtime を使ってる。 NetBSD も以下同文。FreeBSD は monotonic。
2012-02-21
Started using the rthread:
% ls -l /usr/lib/libpthread.so.* -r--r--r-- 1 root bin 813680 Jan 10 11:43 /usr/lib/libpthread.so.13.1 -r--r--r-- 1 root bin 822508 Feb 7 19:48 /usr/lib/libpthread.so.13.3 -r--r--r-- 1 root bin 183080 Feb 21 22:36 /usr/lib/libpthread.so.14.0 %
2012-02-15
http://marc.info/?l=openbsd-misc&m=132922427000548&w=2 で知ったけど、 bind10 は python が必要 らしいので試してみたら、:
% pwd /source/yasuoka/misc/bind10-devel-20120119 % ./configure checking for a BSD-compatible install... /usr/bin/install -c : (snip) checking for a Python interpreter with version >= 3.1... none configure: error: no suitable Python interpreter found %
本当っぽい。
2012-02-14
tar でファイルを展開している時に、他のプロセスが軒並み I/O 待ちになってシステムがハングしたような状態になって気になっている。 まだちゃんと読んでないけど misc@ の "long hangs with heavy IO" と 関係するかもしれない。勘違いかも知れないけど、昔は気にならなかったので。 OpenBSD 5.0 => 5.1 またはディスク交換のどちらかが原因になっているかもしれない。
2012-02-10
OpenBSD の chrome (chomium) でプラグインを使う方法。gnash (SWF player) や mozplugger (よろずプラグイン) のパッケージは、firefox 用に作られているので、 これを chrome で使えるように、
# ln -s /usr/local/lib/mozilla/plugins /usr/local/chrome/plugins
としている。
mozplugger は、どうもそのままでは、プラグインがクラッシュしましたという メッセージが表れて、そのまま使えず、次の patch をあてて使っている。:
--- mozplugger.c-ORIG Wed May 11 12:05:42 2011
+++ mozplugger.c Wed May 11 12:07:01 2011
@@ -1072,9 +1072,14 @@ static int read_config_cb(const char *fname)
pid_t pid;
int fd;
FILE *fp;
+ sigset_t set, oset;
D("READ_CONFIG(%s)\n", fname);
+ sigprocmask(SIG_BLOCK, NULL, &set);
+ sigaddset(&set, SIGCHLD);
+ sigprocmask(SIG_BLOCK, &set, &oset);
+
fd = open(fname, O_RDONLY);
if (fd < 0)
{
@@ -1126,6 +1131,7 @@ static int read_config_cb(const char *fname)
fclose(fp);
int status;
+ sigprocmask(SIG_BLOCK, &oset, &set);
waitpid(pid, &status, 0);
D("M4 exit status was %i\n", WEXITSTATUS(status));
設定を読み込むプロセスが終了した時に SIGCHLD が発生すると、ダメっぽいのだが、 これは mozilla と chomium でプラグインを呼び出した時のシグナルマスクの状態が 異なるために発生しているのでは? と予想しているが...
2012-02-08
OpenBSD の vi が .exrc を読み込まず困っていたが (2011-10-24 とか 2012-01-06 )、原因は OpenBSD デフォルトの .login (/etc/skel/.login => ~/.login) に EXINIT 環境変数が設定されているからだった。
2012-02-07 の chromium の問題は、そもそも libevent の問題ということで、 http://archives.seul.org/libevent/users/Feb-2012/msg00009.html と報告されている。
ports の mew-6.4 も nvi も 5.1 に入らなかった... push しとけば良かった。
2012-02-07
NetBSD 5.1-beta -> mew.org 80/tcp が SYN_SENT で刺さる。 net.inet.tcp.rfc1323=0 で回避できる。たぶん linux の time-wait ソケットの インチキ回収と {OpenBSD,Net}BSD の timestamp option の問題だと思うが、 時間があれば packet capture したい。発生した時のネットワーク構成的は、 横取りプロキシが挟まってて、mew.org とは直接 TCP してないのかもしれない。
生活環境の chrome が頻繁に Segmentation fault となる。 OpenBSD 5.1-beta (2/3 snapshot) + chromium-16.0.912.77 という環境だが、 このまま 5.1 になりそうな雰囲気なので、なんとかしたい。落ちる時の stacktrace
#0 0x1af81265 in base::MessagePumpLibevent::OnLibeventNotification ()
from /usr/local/chrome/chrome
#1 0x074e50b2 in event_base_loop (base=0x8950cc00, flags=2)
at /usr/src/lib/libevent/event.c:402
#2 0x1af7f555 in enterprise_management::protobuf_ShutdownFile_old_5fgeneric_5fformat_2eproto () from /usr/local/chrome/chrome
#3 0x1afb4659 in MessageLoop::Quit () from /usr/local/chrome/chrome
#4 0x1afb470d in MessageLoop::Quit () from /usr/local/chrome/chrome
#5 0x1afb4874 in MessageLoop::Quit () from /usr/local/chrome/chrome
#6 0x1afedabd in base::DefaultLazyInstanceTraits<base::ThreadLocalBoolean>::Delete () from /usr/local/chrome/chrome
#7 0x1afede6e in base::LazyInstance<base::ThreadLocalBoolean, base::DefaultLazyInstanceTraits<base::ThreadLocalBoolean> >::OnExit ()
from /usr/local/chrome/chrome
#8 0x1afed7bc in base::subtle::TaskClosureAdapter::Run ()
from /usr/local/chrome/chrome
#9 0x03b6da2e in _thread_start ()
at /usr/src/lib/libpthread/uthread/uthread_create.c:242
#10 0x0000002b in ?? ()
#11 0x00000000 in ?? ()
robert@ さんに報告したら、 http://marc.info/?l=openbsd-cvs&m=132791695512275&w=2 じゃね? ってことになり、この変更を revert したら直った。さすが。 自分も、libevent かも? とは思ってたので、次回は自力で解決したい。
2012-02-01
- base64 decode::
- perl -e 'use MIME::Base64; print decode_base64(<>) . "n"'
2012-01-31
npppd またもや 5.1 リリースには間に合わない感じなので、頭を切り替えて 5.2 狙いとするか。
NetBSD に取り込まれた IPFilter 5.1.1 によると http://mail-index.netbsd.org/tech-net/2012/01/30/msg003082.html
One of those is a "divert" action that takes a packet and puts an IP + UDP header on the front, allowing "raw packets" to be delivered to any socket.
IP + UDP ヘッダを足して divert 相当を行う拡張が入った。
2012-01-23
xlock してても ctrl-alt-f? で、ロックされてない端末にアクセスできるという話 http://marc.info/?l=openbsd-misc&m=132731150004416&w=2 今後はアクセスできなくなるのか。
2012-01-14
github/openbsd の話 http://marc.info/?l=openbsd-misc&m=132650695213810&w=2 自分も 自作スクリプト で、cvs => svn 変換を行っている。 原理的に cvs から svn などに完璧に変換するのは不可能だと思うが、 この自前のスクリプトでは、 原理的に不可能なこと以外にも何点か変換をあきらめることで、 シンプルな実装 & 処理を軽くしている。いつか詳しく書きたい。
2012-01-13
npppdctl あらため npppctl の件 実行結果は次のような感じ。:
% npppctl -n session brief
Ppp Id Assigned IPv4 Username Proto Tunnel From
---------- --------------- -------------------- ----- -------------------------
1 10.0.0.100 yasuoka L2TP 125.30.2.102:1701
% npppctl -n session packets
Ppd Id Username In(Kbytes/pkts/errs) Out(Kbytes/pkts/errs)
---------- -------------------- ----------------------- -----------------------
1 yasuoka 17.6 194 0 1.4 65 0
stm1: {401} % npppctl -n session all
Ppp Id = 1
Ppp Id : 1
Username : yasuoka
Realm Name : local
Concentrated Interface : tun0
Assigned IPv4 Address : 10.0.0.100
Tunnel Protocol : L2TP
Tunnel From : 125.30.2.102:1701
Start Time : 2012/01/13 09:07:23
Elapsed Time : 13404 sec (3 hours and 43 minutes)
Input Bytes : 17976 (17.6 KB)
Input Packets : 194
Input Errors : 0 (0.0%)
Output Bytes : 1429 (1.4 KB)
Output Packets : 65
Output Errors : 0 (0.0%)
% npppctl clear ppp-id 1
Successfully disconnected 1 session.
%
2012-01-12
OpenBSD 5.1 に向けてガリガリやってます... parse.y 含めて... 間に合うかなぁ..
2012-01-11
『UNIX ファイルシステムの歴史』 http://www.slideshare.net/magoroku15/unix-9720732 を読んだ。
最近 OpenBSD/luna88k が活発なのは、 http://mail-index.netbsd.org/port-m88k/2011/12/thread1.html#000025 このへんの流れか。
2012-01-10
cvs server の /tmp の空きがたりなくて cvs up できない場合:
env CVS_SERVER="/usr/bin/cvs -T /var/tmp" cvs update
2012-01-08
IPv6 でも、実環境では Path MTU Blackhole だらけだから、やっぱ tcp mss 書き換えちゃおうという意見があるみたいだが、 IPv6 は Path MTU Blackhole があるとプロトコル的に辻褄があわないと思っていたので、 そのあたりをどう理解すべきかよくわかっていない。たぶん不勉強なだけだと思うけど。 あとで http://www.potaroo.net/ispcol/2009-01/mtu6.html を読んでみよう。
2012-01-07
2007 年 3 月のセキュリティアドバイザリ OpenBSD's IPv6 mbufs remote kernel buffer overflow を復習。修正である kern/uipc_mbuf2.c に対する diff を読んでみる。 M_DUP_PKTHDR が MGETCL した後だったがこれは誤りだったということ。 MGETCL で確保したメモリ領域を示していた m_data を struct mbuf 内の領域に上書きしてしまう。このため、 struct mbuf の領域をはみ出して書き込んでしまう。あとは、当該関数を呼んでいる IPv6 の処理や、メモリの状態でこの不具合の影響が決まる。はみ出した領域も mbuf であることが予想されるし、 mbuf には mbuf 解放のための関数ポインタが格納されているので、その関数ポインタを書き換えて、任意のコードを実行させることが可能だったということ。
そもそも IPv6 (kame) の実装で m_pulldown() という関数が作られ、 その関数で必要となった m_dup1 という関数に不具合があった。 現在の OpenBSD でも、 m_pulldown は、IPv6 スタックでしか使われていない。そもそも m_pulldown を作ることなく実装できたかもしれない、と思う。 IPv6 拡張ヘッダで使用されている部分は、 そもそもネットワークプロトコルのヘッダなので、 小さいと考えて全体を連続領域に載せてしまい、 その仮定で実装した方がシンプルだと思われる。 それ以外で使用される箇所は、 m_copy{data,back} で代用できる、というか m_copy{data,back} のほうがむしろふさわしいと思う。
- (2012-01-12 追記)
- ↑の m_pulldown が「IPv6 スタックでしか使われていない」というのは大嘘でし た。 net/ 以下では sppp や pf でも使われてました。m_pulldown が kame 由来というのももしかすると間違ってるかも。
ついでに CVE-2008-3584 も復習。 NetBSD のアドバイザリ に名前がクレジットされている。発見したのは僕じゃないじゃないけど。 OpenBSD では、 NetBSD のアドバイザリ直後に commit されていた。
よく見ると、NetBSD のアドバイザリ間違ってて、cvs up すべきは、if_spppsubr.c じゃなく if_pppoe.c。いまさら時効だと思うけど。
2012-01-06
以前、 OpenBSD の vi が .exrc を読み込まないと書いた が、普通に読み込んでいる。勘違いだったか...
~/ 以下を暗号化して保護しても、vi.recover で編集中の文書が丸見えという問題 があることに気づいたので、~/.exrc に set recdir=/home/yasuoka/.vi.recover を追加した。
swap は暗号化可能か、されているのか知らなかったが、 OpenBSD では、swapencryptという仕組みが入っていて、
vm.swapencrypt.enable=1 vm.swapencrypt.keyscreated=0 vm.swapencrypt.keysdeleted=0
デフォルトで有効なようだ。 vm.swapencrypt.keys{created,deleted} は、swap が実際に使われると増えていくらしい。詳細は、 Encrypting Virtual Memory - Niels Provos というペーパーがあるので、これに書いてあるっぽい。
NetBSD の場合は cgd(4) で、 FreeBSD の場合は geom(4) 上の gbde(4) で暗号化できる。 OpenBSD 以外は、暗号化している仮想ディスクを swap として使う、という考え方。 OpenBSD は uvm の機能として実装されている。
phk が作った HTTP キャッシュサーバ varnish から、 それで使われてるらしい B-Heap をななめ読み。
ghostscript-fonts をインストールすると、xfe が文字化けする。
2012-01-05
reStructuredText では、取り消し線付きテキスト、HTML の strike タグ相当は利用できない。自前で role を追加して HTML の CSS クラスでスタイルとして定義することで実現する方法が、 http://stackoverflow.com/questions/6518788/rest-strikethrough に書かれている。しかし、この方法では HTML でスタイルが適用されない場合や HTML 以外の出力形式を使う場合に、取り消されずに出力されてしまうため、文章の意味が変わってしまう。当面はあきらめることにする。
本番環境で初期不良の SSD を踏みました - mura日記 (halfrack) を読んで、自分のノート PC のカウンタも調べてみた。 昨年末に換装したばかりの新品 HDD だが、将来、現在の値が参考になるかもしれないので、張っておく
% sudo atactl wd0 readattr Attributes table revision: 16 ID Attribute name Threshold Value Raw 1 Raw Read Error Rate 62 100 0x000000000000 2 Throughput Performance 40 100 0x000000000000 3 Spin Up Time 33 181 0x001100000001 4 Start/Stop Count 0 100 0x000000000057 5 Reallocated Sector Count 5 100 0x000000000000 7 Seek Error Rate 67 100 0x000000000000 8 Seek Time Performance 40 100 0x000000000000 9 Power-On Hours Count 0 100 0x00000000012a 10 Spin Retry Count 60 100 0x000000000000 12 Device Power Cycle Count 0 100 0x000000000054 191 G-Sense Error Rate 0 97 0x000000060001 192 Power-Off Retract Count 0 100 0x00000000000d 193 Load Cycle Count 0 91 0x000000016593 194 Temperature 0 153 0x002d000a0027 196 Reallocation Event Count 0 100 0x000000000000 197 Current Pending Sector Count 0 100 0x000000000000 198 Off-Line Scan Uncorrectable Sect 0 100 0x000000000000 199 Ultra DMA CRC Error Count 0 200 0x000000000000 223 Load/Unload Retry Count 0 100 0x000000000000 %
OpenBSD日本語入力の怪（というより知識不足）- OpenBSD日記 に、 30分でできる OpenBSD 日本語デスクトップ環境 を読んでハマったポイントが書いてある。要改善ポイントまとめておく。
- xdm の画面に至る部分の説明
- xdm じゃなく startx の場合のフォロー
- .xsession の書き方をに関するフォロー。解説ページへのリンクなど
- やっぱり emacs や vim で使いたいはずなので、そのフォロー
その他、自分で見直しての要改善ポイント
- OpenBSD は、amd64 じゃなく i386 で説明しているところも言及すべき