ddb
Table of Contents
Windows 11 with sudo
こんなビックリなニュースを知った。多分WSLを多用してる連中からの、突き 上げがあって、腰を上げたのだろう。便利ならばいいじゃないって風潮があり ありだな。
端末を起動する時、右クリックして、やっと管理者権限のコマンドを実行でき るって、面倒だけどそれなりに安全な方法だな。
それを、古いとぬかして、不確かなsudoでもいいよって、OpenBSDのあの人が 怒り出すぞ。
ddb
河豚板からddbを使って、そのセッションを記事に挙げようとしたんだけど、 msgを取得する方法が不明。そこで思い付いたのが、qemuにOpenBSDを導入して、 そこにシリアル接続出来るようにする。母艦側からは、cuを使ってアクセスす る。何なら、懐かしいkermitでもいいけど。
昔の事で、qemuにOpenBSDを入れる方法を忘れてしまっている。ググったら、 Debugging the OpenBSD kernel via QEMU なんていうジャーナルが出てきた。
qemu-system-i386 -m 256 -nographic -no-fd-bootchk \ -net nic -net user,hostfwd=tcp::2022-:22 \ -hda disk
これでXが不要な環境(sshしたPuTTyでも)起動して、シリアルな端末が出てく る。
Booting from Hard Disk... Using drive 0, partition 3. Loading...... probing: pc0 com0 apm pci mem[639K 254M a20=on] disk: fd0 hd0+ >> OpenBSD/i386 BOOT 3.65 switching console to com0>> OpenBSD/i386 BOOT 3.65 boot> : OpenBSD/i386 (qemu.my.domain) (tty00)
tty00 って、シリアルな端末だ。
これをrootの.profileに記述しておけばいいのだな。
alias inddb='sysctl -w ddb.trigger=1'
check loadavg
負荷チェックをしようと思って、それには余計なダエモン君は不要だろうと、 止めておいた。最低限のプロセスですよ。
qemu# ps awx
PID TT STAT TIME COMMAND
1 ?? I 0:01.38 /sbin/init
97694 ?? IU 0:00.36 /sbin/dhcpleased
50895 ?? Ip 0:00.28 dhcpleased: engine (dhcpleased)
33430 ?? IpU 0:00.27 dhcpleased: frontend (dhcpleased)
66697 ?? IpU 0:00.10 /sbin/resolvd
7692 ?? I 0:00.20 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups)
81878 00 Sp 0:01.26 -ksh (ksh)
79215 00 R+pU 0:00.09 ps -awx
82694 C0 I+pU 0:00.21 /usr/libexec/getty std.9600 ttyC0
4586 C1 I+pU 0:00.12 /usr/libexec/getty std.9600 ttyC1
16988 C2 I+pU 0:00.12 /usr/libexec/getty std.9600 ttyC2
19388 C3 I+pU 0:00.15 /usr/libexec/getty std.9600 ttyC3
89302 C5 I+pU 0:00.12 /usr/libexec/getty std.9600 ttyC5
動いてるプロセスは、こんぐらい。
qemu# inddb
Stopped at db_enter+0x4: popl %ebp
ddb> ps
PID TID PPID UID S FLAGS WAIT COMMAND
*75354 450847 27546 0 7 0x3 sysctl
27546 35314 1 0 3 0x10008b sigsusp ksh
89302 320048 1 0 3 0x100083 ttyin getty
19388 491507 1 0 3 0x100083 ttyin getty
16988 482225 1 0 3 0x100083 ttyin getty
4586 457379 1 0 3 0x100083 ttyin getty
82694 200001 1 0 3 0x100083 ttyin getty
7692 174233 1 0 3 0x88 kqread sshd
66697 360121 1 0 3 0x100080 kqread resolvd
33430 451837 97694 77 3 0x100092 kqread dhcpleased
50895 399023 97694 77 3 0x100092 kqread dhcpleased
97694 407659 1 0 3 0x80 kqread dhcpleased
19119 487863 0 0 3 0x14200 bored smr
62180 190814 0 0 2 0x14200 zerothread
51716 136139 0 0 3 0x14200 aiodoned aiodoned
60545 523191 0 0 3 0x14200 syncer update
85846 321198 0 0 3 0x14200 cleaner cleaner
51308 82522 0 0 3 0x14200 reaper reaper
60060 217625 0 0 3 0x14200 pgdaemon pagedaemon
37971 73061 0 0 3 0x14200 bored wsdisplay0
31604 455555 0 0 3 0x40014200 acpi0 acpi0
77343 70439 0 0 3 0x14200 bored softnet3
24404 93850 0 0 3 0x14200 bored softnet2
67489 28520 0 0 3 0x14200 bored softnet1
90443 372434 0 0 3 0x14200 bored softnet0
17658 498391 0 0 3 0x14200 bored systqmp
10792 447780 0 0 3 0x14200 bored systq
85735 8858 0 0 3 0x40014200 bored softclock
83536 96226 0 0 3 0x40014200 idle0
97336 161685 0 0 3 0x14200 kmalloc kmthread
1 31227 0 0 3 0x82 wait init
0 0 -1 0 3 0x10200 scheduler swapper
ddb> c
ddb.trigger: 0 -> 1
qemu#
一応ddbのpsでも確認した。それでチェックすると、
qemu# w 7:08AM up 16 mins, 1 user, load averages: 0.05, 0.08, 0.08 USER TTY FROM LOGIN@ IDLE WHAT root 00 - 7:06AM 0 w qemu# w 7:28AM up 36 mins, 1 user, load averages: 0.01, 0.01, 0.00
負荷は、ほぼゼロ。記録係りぐらいは動かすかな。
qemu# cat /etc/rc.conf.local library_aslr=NO ntpd_flags=NO smtpd_flags=NO # syslogd_flags=NO sndiod_flags=NO # cron_flags=NO slaacd_flags=NO # pflogd_flags=NO
こんな結果になった。
qemu# w 7:56AM up 5 mins, 1 user, load averages: 0.03, 0.23, 0.14 qemu# w 8:17AM up 26 mins, 1 user, load averages: 0.00, 0.00, 0.01
最後は、せわしなく動くntpdだけを停止させる。これでほぼデフォなダエモン 君が起動。
qemu$ w 5:00AM up 7 mins, 1 user, load averages: 0.00, 0.19, 0.15 qemu$ w 5:19AM up 26 mins, 1 user, load averages: 0.00, 0.00, 0.02
一方、ntpdだけを主体に動かすと、
qemu# w
5:31AM up 38 mins, 1 user, load averages: 0.21, 0.27, 0.17
qemu# w
6:53AM up 2:01, 1 user, load averages: 0.02, 0.01, 0.00
qemu# ntpctl -s all
5/5 peers valid, constraint offset -1s, clock synced, stratum 2
peer
wt tl st next poll offset delay jitter
162.159.200.1 time.cloudflare.com
1 10 3 632s 1504s -4.720ms 16.740ms 1.794ms
133.243.238.163 from pool pool.ntp.org
1 10 1 632s 1514s -0.263ms 20.114ms 3.743ms
133.243.238.243 from pool pool.ntp.org
* 1 10 1 769s 1644s -0.511ms 20.360ms 5.962ms
162.159.200.1 from pool pool.ntp.org
1 10 3 664s 1542s -4.429ms 18.171ms 3.060ms
129.250.35.251 from pool pool.ntp.org
1 10 2 640s 1541s -0.039ms 17.661ms 4.673ms
linux's ps
ddbからのpsで、普段目にしない情報が出てきてた。リナは余す所なく開陳し てたような気がするんで、見直ししてみる。
BSDスタイル
[sakae@arch ~]$ ps awx
PID TTY STAT TIME COMMAND
1 ? Ss 0:02 /sbin/init
2 ? S 0:00 [kthreadd]
3 ? S 0:00 [pool_workqueue_release]
4 ? I< 0:00 [kworker/R-rcu_g]
:
401 ? S 0:00 (sd-pam)
408 ? S 0:00 sshd: sakae@pts/0
411 pts/0 Ss 0:00 -bash
416 pts/0 S+ 0:00 tmux
418 ? Ss 0:00 tmux
標準スタイル？ 豊富過ぎるオプションに辟易するわ。
[sakae@arch ~]$ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 06:30 ? 00:00:02 /sbin/init root 2 0 0 06:30 ? 00:00:00 [kthreadd] root 3 2 0 06:30 ? 00:00:00 [pool_workqueue_release] root 4 2 0 06:30 ? 00:00:00 [kworker/R-rcu_g] root 5 2 0 06:30 ? 00:00:00 [kworker/R-rcu_p] : sakae 492 424 0 06:38 pts/2 00:00:00 man ps sakae 500 492 0 06:38 pts/2 00:00:00 less
/usr/local/share/doc/qemu
なんて所に、qemuの解説書が、置いてある。最初これを、/var/www/htdocsに コピーして、普通のWEBサーバーから、アクセスしてた。 そんな私製のシステムでも、ググル製のブラウザーでちゃんと日本語に翻訳し てくれた。今迄は、URLをググルに送信して、翻訳結果を受信して表示してる ものとばかり思っていたぞ。chrome自身に翻訳機能が搭載されてるのね。
ちょっと気を良くしたオイラーは、pythonの唯一の使い道、どこでもwebサー バーも試してみる事にした。
alias server='python3 -m http.server 8080'
http://x.x.x.x:8080/ すると、普通のサーバーと遜色の無いコンテンツが返っ てきたよ。
ob$ server Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ... x.x.x.x - - [15/Feb/2024 14:04:28] "GET / HTTP/1.1" 200 - x.x.x.x - - [15/Feb/2024 14:04:29] "GET /_static/pygments.css HTTP/1.1" 200 - :
ddb break trace x
よく使うddbのコマンドを試してみる。 まずは、ロード・アベレージを保持してる構造体の確認。32Bitのデータが4個 で一組だ。
ddb> x/d averunnable,4 averunnable: 0 averunnable+0x4: 0 averunnable+0x8: 0 averunnable+0xc: 2048
次は、ロード・アベレージを更新する関数にBPを置く。そしてcontinue。する と、5秒なんて直に過ぎるので、ブレークする。すかさず、バックトレースす る。
ddb> break update_loadavg ddb> c Breakpoint at update_loadavg: pushl %ebp ddb> trace update_loadavg(0) at update_loadavg softclock_process_tick_timeout(d0ea178c,0) at softclock_process_tick_timeout+0xdd softclock(0) at softclock+0x87 softintr_dispatch(0) at softintr_dispatch+0x8b Xsoftclock() at Xsoftclock+0x12 splx(0) at splx+0x23 db_ktrap(1,0,f3a9545c) at db_ktrap+0xe3 trap(f3a9545c) at trap+0x475 calltrap() at calltrap+0xc db_enter() at db_enter+0x4 ddb_sysctl(f3a954e0,1,cf7fa7a0,f3a954d8,cf7f87a0,4,d1a4a68c) at ddb_sysctl+0xa4 sys_sysctl(d1a4a68c,f3a95550,f3a95548) at sys_sysctl+0x146 syscall(f3a95590) at syscall+0x2a0 Xsyscall_untramp() at Xsyscall_untramp+0xa9 end of kernel
思わぬフォルト発生
ddb> c
panic: uvm_fault(0xd1a9cc30, 0x0, 0, 1) -> e
Stopped at db_enter+0x4: popl %ebp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
69071 93527 0 0x3 0 0 sysctl
db_enter() at db_enter+0x4
panic(d0c9d953) at panic+0x76
kpageflttrap(f3a95444,0) at kpageflttrap+0x143
trap(f3a95444) at trap+0x241
calltrap() at calltrap+0xc
sysctl_rdint(d045c930,0,0,0) at sysctl_rdint+0x1f
ddb_sysctl(f3a954e0,1,cf7fa7a0,f3a954d8,cf7f87a0,4,d1a4a68c) at ddb_sysctl+0xb0
sys_sysctl(d1a4a68c,f3a95550,f3a95548) at sys_sysctl+0x146
syscall(f3a95590) at syscall+0x2a0
Xsyscall_untramp() at Xsyscall_untramp+0xa9
end of kernel
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
もう証拠を残してrebootする鹿。
ddb> boot dump syncing disks... done WARNING: not updating battery clock dumping to dev 1, offset 255 dump 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 : 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 succeeded rebooting... SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org)
起動の途中でfsckが走り、それから、証拠の安置が実行された。
/dev/wd0a (60ed7e83506cee69.a): UNREF FILE I=103777 OWNER=root MODE=100444 /dev/wd0a: SIZE=11131 MTIME=Feb 14 21:58 2024 (CLEARED) /dev/wd0a (60ed7e83506cee69.a): FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/wd0a (60ed7e83506cee69.a): SUMMARY INFORMATION BAD (SALVAGED) /dev/wd0a (60ed7e83506cee69.a): BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/wd0a (60ed7e83506cee69.a): 2157 files, 32352 used, 505023 free (79 frags, ) /dev/wd0a (60ed7e83506cee69.a): MARKING FILE SYSTEM CLEAN /dev/wd0e (60ed7e83506cee69.e): 11 files, 12 used, 1012707 free (19 frags, 1265) /dev/wd0e (60ed7e83506cee69.e): MARKING FILE SYSTEM CLEAN /dev/wd0d (60ed7e83506cee69.d): 22460 files, 502090 used, 1018637 free (421 fra) /dev/wd0d (60ed7e83506cee69.d): MARKING FILE SYSTEM CLEAN ddb.console: 0 -> 1 kern.global_ptrace: 0 -> 1 : starting RPC daemons:. savecore: reboot after panic: uvm_fault(0xd1a9cc30, 0x0, 0, 1) -> e savecore: system went down at Thu Feb 15 15:04:26 2024 savecore: /var/crash/bounds: No such file or directory savecore: writing core to /var/crash/bsd.0.core savecore: writing kernel to /var/crash/bsd.0 checking quotas: done.
証拠物件の確認。その時のカーネルと全メモリー内容が保持されるのか。だか ら、swapエリアのサイズは、最低でもメモリー容量(プラスα)が必要って事な んだな。
qemu# cd /var/crash/ qemu# ls -l total 554600 -rw------- 1 root wheel 2 Feb 15 15:14 bounds -rw------- 1 root wheel 15452101 Feb 15 15:14 bsd.0 -rw------- 1 root wheel 268304916 Feb 15 15:14 bsd.0.core -rw-r--r-- 1 root wheel 5 Oct 10 23:41 minfree qemu# ls -l /bsd -rwx------ 2 root wheel 15452101 Feb 13 07:53 /bsd
今後もパニくる事が有るだろう。その度に、256Mものメモリーをsaveするんじゃ 無駄だな。せいぜい96Mも有れば十分だろう。
instraction
起動直後にロード・アベレージを再採取。それっぽい値になってるかな。
qemu# w 3:47PM up 1 min, 1 user, load averages: 1.28, 0.44, 0.17 qemu# inddb Stopped at db_enter+0x4: popl %ebp ddb> x/d averunnable,4 averunnable: 2412 averunnable+0x4: 891 averunnable+0x8: 344 averunnable+0xc: 2048
そして、更新関数の逆アセンブル。何やらチンプンカンプンです。
ddb> x/i update_loadavg,25 update_loadavg: pushl %ebp update_loadavg+0x1: movl %esp,%ebp update_loadavg+0x3: pushl %edi update_loadavg+0x4: pushl %esi update_loadavg+0x5: movl cpu_info_list,%edi update_loadavg+0xb: xorl %esi,%esi update_loadavg+0xd: testl %edi,%edi update_loadavg+0xf: jz update_loadavg+0x47 update_loadavg+0x11: jmp update_loadavg+0x20 update_loadavg+0x14: int $3 update_loadavg+0x15: int $3 update_loadavg+0x16: int $3 update_loadavg+0x17: int $3 update_loadavg+0x18: int $3 update_loadavg+0x19: int $3 update_loadavg+0x1a: int $3 update_loadavg+0x1b: int $3 update_loadavg+0x1c: int $3 update_loadavg+0x1d: int $3 update_loadavg+0x1e: int $3 update_loadavg+0x1f: int $3 update_loadavg+0x20: pushl %edi update_loadavg+0x21: pushl $0xd0fd70d0 update_loadavg+0x26: call cpuset_isset update_loadavg+0x2b: addl $0x8,%esp update_loadavg+0x2e: addl 0x170(%edi),%esi update_loadavg+0x34: cmpl $0x1,%eax update_loadavg+0x37: adcl $0,%esi update_loadavg+0x3a: movl 0x190(%edi),%edi update_loadavg+0x40: testl %edi,%edi update_loadavg+0x42: jnz update_loadavg+0x20 update_loadavg+0x44: shll $0xb,%esi update_loadavg+0x47: imull $0x75c,averunnable,%eax update_loadavg+0x51: imull $0xa4,%esi,%ecx update_loadavg+0x57: addl %eax,%ecx update_loadavg+0x59: shrl $0xb,%ecx update_loadavg+0x5c: movl %ecx,averunnable ddb> x/i .,20 update_loadavg+0x5c: movl %ecx,averunnable update_loadavg+0x62: imull $0x7de,averunnable+0x4,%eax update_loadavg+0x6c: movl %esi,%ecx update_loadavg+0x6e: shll $0x5,%ecx update_loadavg+0x71: leal 0(%ecx,%esi,2),%ecx update_loadavg+0x74: addl %eax,%ecx update_loadavg+0x76: shrl $0xb,%ecx update_loadavg+0x79: movl %ecx,averunnable+0x4 update_loadavg+0x7f: imull $0x7f4,averunnable+0x8,%eax update_loadavg+0x89: leal 0(%esi,%esi,2),%ecx update_loadavg+0x8c: leal 0(%eax,%ecx,4),%eax update_loadavg+0x8f: shrl $0xb,%eax update_loadavg+0x92: movl %eax,averunnable+0x8 update_loadavg+0x97: pushl $0x5 update_loadavg+0x99: pushl $0xd0ea178c update_loadavg+0x9e: call timeout_add_sec update_loadavg+0xa3: addl $0x8,%esp update_loadavg+0xa6: popl %esi update_loadavg+0xa7: popl %edi update_loadavg+0xa8: popl %ebp update_loadavg+0xa9: ret update_loadavg+0xaa: int $3 update_loadavg+0xab: int $3 update_loadavg+0xac: int $3 update_loadavg+0xad: int $3 update_loadavg+0xae: int $3 update_loadavg+0xaf: int $3 schedcpu: pushl %ebp schedcpu+0x1: movl %esp,%ebp schedcpu+0x3: pushl %ebx schedcpu+0x4: pushl %edi schedcpu+0x5: pushl %esi
usefull command
boot sync Sync disks and reboot.
boot crash Dump core and reboot.
boot dump Sync disks, dump core and reboot.
boot halt Just halt.
boot reboot Just reboot.
boot poweroff Power down the machine whenever possible; if
it fails, just halt.
show struct name [addr]
Prints the content of the memory at addr as a struct
name. Nested structures and bit fields are not
printed. Character arrays are printed as bytes.
ちょいと確認
ddb> show struct loadavg averunnable
struct averunnable at 0xd0f597d8 (16 bytes) {ldavg = 2377, fscale = 0x800}
ddb> pp averunnable
averunnable: {ldavg = 2377, fscale = 0x800}
ddb> p averunnable
d0f597d8