FreeBSD on FreeBSD
Table of Contents
FreeBSD on FreeBSD
前回、母艦であるFreeBSDにqemuを入れ、そこでゲストとしてFreeBSDを動作さ せる算段をした。残念ながらゲストはqemuを利用してインストール出来なかっ たので、VMWare上でインストール、それを母艦にcpした上で、vmdkタイプを qcow2に変換(qemu-img convert)したものだ。
Booting from Hard Disk と報告してきて、ハングアップ。どうしようとなく て、 第12章 FreeBSD の起動のプロセス を見ておさらいしたり。。。
そのうちに、ふと思った。/boot/loader.confに、シリアル設定を忘れている んではなかろうか？ VMWareに戻って確認したら、案の定設定されていなかっ た。おかしいな、ちゃんと設定したはずなんだけど。。ひょっとして別なOSと 取り違えていたのかも？ きちんと設定して、Diskのタイプを変換してから、 再度挑戦。
Booting from Hard Disk... / Loading /boot/loader.conf.local | \ ______ ____ _____ _____ | ____| | _ \ / ____| __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/
今度は上手くいった。fstabの設定に不整合があったので、da0 -> ada0 と書 き変えはしたけどね。ちゃんとメッセージが出れば、なんとかなる。ダンマリ が一番ツライのよ。
debug確認
ホスト側の/usr/lib/debug/boot/kernelに追加。
ob$ cat .gdbinit target remote :1234
ゲストOSを起動しておいてから、ホスト側で実行。
sakae@f64:/usr/lib/debug/boot/kernel $ gdb -q kernel.debug
Reading symbols from kernel.debug...
warning: remote target does not support file transfer, attempting to access files from local filesystem.
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
acpi_cpu_c1 () at /usr/src/sys/x86/x86/cpu_machdep.c:247
247 }
(gdb) bt 4
#0 acpi_cpu_c1 () at /usr/src/sys/x86/x86/cpu_machdep.c:247
#1 0xffffffff804b3605 in acpi_cpu_idle (sbt=<optimized out>)
at /usr/src/sys/dev/acpica/acpi_cpu.c:1157
#2 0xffffffff80fc45f6 in cpu_idle_acpi (sbt=429605779)
at /usr/src/sys/x86/x86/cpu_machdep.c:590
#3 0xffffffff80fc46ad in cpu_idle (busy=0)
at /usr/src/sys/x86/x86/cpu_machdep.c:679
やっと動いたな。
speed
ゲストOSのmessagesにVMWare時代の痕跡とqemu時代の痕跡が残っていたので、 貼りつけておく。
Jul 7 00:57:56 qf kernel: da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) Jul 7 07:07:42 qf kernel: ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
駆動仮想マシンによって、デバイスの解釈が違うんだね。da0はSCSI接続。 ada0の方はIDE接続と言う事みたいだ。随分パフォーマンスが違うね。
昔(今もそうかも知れないけど)リナのdmesgには、システムのパフォーマンス の目安として、ボンゴ・ミックスと呼ばれるデータが表示されてた。この データに一喜一憂してたみたい。オイラーは、リナのdmesgなんて雑音ばかり 多くて、 見る価値は無いと思っているから、顛末は全くもって知らないぞ。
VMwareで動作してる i386版のFreeBSDでは、こんな結果だった。
ada0: 33.300MB/s transfers (UDMA2, PIO 32768bytes) ada1: 33.300MB/s transfers (UDMA2, PIO 32768bytes) cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
FreeBSDではストレージ・デバイスの大統一理論、cam(4)によって、統合的に扱 かう仕組みが確立してるらしい。これを知ったのは、かの昔に BSD Magazine からだった。あの頃は、何も分かっていなかったからなあ。今、同マガジンが 入手できたら、楽しいだろうね。
NAME
CAM – Common Access Method Storage subsystem
SYNOPSIS
device scbus
device ada
device cd
device ch
device da
:
find measurement point in kernek
どんな風に計測してるの？ cd0ってread onlyだから、読み出しスピードを計
測してると想像できる。/sys/cam/ata/ ata_xpt.c あたりかな。
ata_announce_periph_sbuf(struct cam_periph *periph, struct sbuf *sb)
{
struct ccb_trans_settings cts;
u_int speed, mb;
_ata_announce_periph(periph, &cts, &speed);
if ((cts.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP)
return;
mb = speed / 1000;
if (mb > 0)
sbuf_printf(sb, "%s%d: %d.%03dMB/s transfers",
periph->periph_name, periph->unit_number,
mb, speed % 1000);
どうも、この関数っぽい。今迄はカーネルが定常運転になっている時にgdb入 りしてたけど、それじゃ通り過ぎちゃうんだなあ。
ゲストを起動。10カウントダウンしてる時に、一度gdbを起動、そして継続。 こうしておけば、gdbは臨戦体制になるんで、C-cですぐにgdbに突入できる。
やがてゲストには、カーネルのバナーが出てくる。そしたら、すかさずgdbを 起動。そしてBPを設定して継続。こうして、下記が採取できた。
#0 ata_announce_periph_sbuf (periph=0xcc38780, sb=0x3b1e0d0)
at /usr/src/sys/cam/ata/ata_xpt.c:2181
#1 0x009080af in xpt_announce_periph_sbuf (periph=0xcc38780, sb=0x3b1e0d0,
announce_string=0xccab64c "2048MB (4194304 512 byte sectors)")
at /usr/src/sys/cam/cam_xpt.c:1123
#2 0x00931d92 in adaregister (periph=0xcc38780, arg=0x3b1e680)
at /usr/src/sys/cam/ata/ata_da.c:1898
#3 0x009041cb in cam_periph_alloc (periph_ctor=0x9319c0 <adaregister>,
periph_oninvalidate=0x931f30 <adaoninvalidate>,
periph_dtor=0x931f70 <adacleanup>, periph_start=0x932090 <adastart>,
name=0x14e7903 "ada", type=<optimized out>, path=0xb930d80,
ac_callback=0x931570 <adaasync>, code=AC_FOUND_DEVICE, arg=0x3b1e680)
at /usr/src/sys/cam/cam_periph.c:299
#4 0x009315fd in adaasync (callback_arg=0x0, code=128, path=0x3b1e670,
arg=0x3b1e680) at /usr/src/sys/cam/ata/ata_da.c:1313
#5 0x0090d899 in xptsetasyncfunc (device=0xcc2a800, arg=0x3b1eb78)
at /usr/src/sys/cam/cam_xpt.c:2555
#6 0x00910b8b in xptdefdevicefunc (device=0x3b1dfa0, arg=<optimized out>)
at /usr/src/sys/cam/cam_xpt.c:2478
#7 xptdevicetraverse (target=<optimized out>, start_device=0x0,
tr_func=<optimized out>, arg=<optimized out>)
at /usr/src/sys/cam/cam_xpt.c:2294
#8 xptdeftargetfunc (target=<optimized out>, arg=<optimized out>)
at /usr/src/sys/cam/cam_xpt.c:2463
#9 xpttargettraverse (bus=<optimized out>, start_target=0x0,
tr_func=<optimized out>, arg=<optimized out>)
at /usr/src/sys/cam/cam_xpt.c:2255
#10 xptdefbusfunc (bus=0xb8f8900, arg=0x3b1ebfc)
at /usr/src/sys/cam/cam_xpt.c:2446
#11 0x0090ed07 in xptbustraverse (start_bus=<optimized out>,
start_bus@entry=0x0, tr_func=0x910a40 <xptdefbusfunc>, arg=0x3b1ebfc)
at /usr/src/sys/cam/cam_xpt.c:2219
#12 0x0090d6da in xpt_for_all_devices (arg=0x3b1eb78, tr_func=<optimized out>)
at /usr/src/sys/cam/cam_xpt.c:2528
#13 xpt_register_async (event=128, cbfunc=0x931570 <adaasync>, cbarg=0x0,
path=0xb930d80) at /usr/src/sys/cam/cam_xpt.c:5229
#14 0x009314b6 in adainit () at /usr/src/sys/cam/ata/ata_da.c:1183
#15 0x00903cad in periphdriver_init (level=2)
at /usr/src/sys/cam/cam_periph.c:190
#16 0x0090d49d in xpt_finishconfig_task (context=<optimized out>,
pending=<optimized out>) at /usr/src/sys/cam/cam_xpt.c:5178
#17 0x01083c84 in taskqueue_run (queue=0x3d8f3c0)
at /usr/src/sys/kern/subr_taskqueue.c:532
#18 0x01084d3e in _taskqueue_start_threads (tqp=0x3dec608,
count=<optimized out>, pri=31105224, mask=0x3b1ece8,
p=0x1084c80 <_taskqueue_start_threads>, name=0x0,
ap=0x1daa0c8 <taskqueue_thread> "")
at /usr/src/sys/kern/subr_taskqueue.c:722
#19 0x00fe9eb5 in fork_exit (callout=0x1084c80 <_taskqueue_start_threads>,
arg=0x1daa0c8 <taskqueue_thread>, frame=0x3b1ece8)
at /usr/src/sys/kern/kern_fork.c:1151
#20 0xffc0348e in ?? ()
other sample
今回もそうだったんだけど、/etc/fstabのミスマッチで、起動が停止した。先 月の17日も発生させてしまっていたので、下記が、どの返で出しているか、確 認してみたい。
Manual root filesystem specification:
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:zroot/ROOT/default
cd9660:/dev/cd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
? List valid disk boot devices
. Yield 1 second (for background tasks)
<empty line> Abort manual input
刑事の心境からすれば、証拠物件が豊富すぎるなあ。
sakae@fb:/sys $ fgrep 'Manual root filesystem specification' -r .
./kern/vfs_mountroot.c: printf("\nManual root filesystem specification:\n");
答一発で、辿りつけたんだけど、まだまだ、推理力が無いな。経験が少なすぎ るぞ。
ssh key
これで2つのゲストOSが動作する様になった。ssh qemu すると、それぞれのホ ストのidが異るため、sshに文句を言われるんだ。どんな風にsshが認識してる か調べると、こんな感じ。
sakae@f64:~/.ssh $ cut -b-40 known_hosts [localhost]:2022 ssh-ed25519 AAAAC3NzaC1 [localhost]:2022 ssh-rsa AAAAB3NzaC1yc2E [localhost]:2022 ecdsa-sha2-nistp256 AAA
この文句を回避する(悪い)方法として、両ホストの/etc/ssh/*key を同一にし ちゃえば良い。そうすれば、どちらのゲストでも、同一のkeyで応答するんで、 文句の付けようもなくなる。生活の知恵である。
ここで問題です。qemuで稼動するFreeBSDとOpenBSDの2つが目出たく作成でき た けど、両OSを同時に起動しておき、それにssh qemuしたら、どちらのOSに接続 されるだろう？
1. どちらか一方に常に接続される 2. その時の運次第で、何方とも言えない 3. そもそも、同時にOSを起動できない。よって、愚問である
早速実験
sakae@f64:/opt/OB75 $ ./boot.sh qemu-system-x86_64: -net user,hostfwd=tcp::2022-:22: Could not set up host forwarding rule 'tcp::2022-:22'
これ、先にFreeBSDを起動しておき、続いて、OpenBSDを起動した時。このメッ セージからすると、ちゃんとqemuは連携を取っているようですねぇ。
real speed
上でdmesgが報告してくるdiskのスピードを見たけど、それをユーザーレベル でもやってみる。dd if=/dev/zero of=zz bs=1M count=1000 が報告してくる 時間を列挙するだけだけど。。
ThinkPad SL510 Celeron(R) @ 2.20GHz
VM OS speed ----------- ----------------- ------- None OpenBSD(32Bit) 15.346 qemu FreeBSD(32Bit) 66.208 qemu OpenBSD(32Bit) 99.054
ThinkPad E560 i5-6200U @ 2.30GHz
VM OS speed ----------- ----------------- ------- Hyper-V Debian 2.774 VMWare FreeBSD(32Bit) 6.049 qemu FreeBSD(32Bit) 18.245 VMWare FreeBSD 7.564 qemu FreeBSD 17.868 qemu OpenBSD 34.625 VMWare ArchLinux 7.296 VMWare OpenBSD 38.836
OpenBSDは、VMWareに入れたもの(下記参照)も参考調査。随分とパフォーマン スが悪いな。相性問題なのかなあ。
Debianが断トツに速いのは、CPUレベルの仮想化で、ハードの性能を余す所な く引き出しているから。VMWareはWindowsに虐げられて、CPUの仮想化の恩恵に 預かれない為と考えられる。
OpenBSD on VMWare
を、もう一度やってみる事にする。なんせVMwareとは一蓮托生ですから、と ことん世話になるのさ。
install75.isoを指定すると、ゲストOSを 決定できませんと拒否される。以前はOSを指定するタブが有ったんだけどな。 OpenBSDは見放されちゃった？
違う、isoは何も設定しないで、仮想マシンの設定だけをするって事にして、 nextを指定すれば、手動でOSを設定する画面に遷移する。そこで、その他の 64Bitを選ぶ。もう、完全に雑魚扱いですよ。
この画面では、かろうじてFreeBSDは何種類かから、選べるようになってた。 それと、Solarisもその他扱かいながら選べるのね。腐ってもSolarisだな。 主流は、WindowsとLinuxになってるのは、世界の情勢を反映してる。まあ、そ れが資本主義ってものです。
後は、マシンの設定で、CDを選んで、install75.isoを指定。そして起動って 流れになる。
README
ホワイトハッカー入門 第2版 なんて本を読んでいる。
たまたま、プロバイダーの電話勧誘があったので、先方が名乗った社名をググ るしてURLを割り出し、それを元に 身元調査してみる。
sakae@fb:~ $ host www.hogefuga-cc.jp www.hogefuga-bb.jp has address xxx.yyy.zzz.aa
JPRS のメニュー (JPRS WHOIS)が最上段にあるので、ドメイン名で検索。
JPNIC WHOIS Gateway ここにIPAdressを入力して、アドレスが何処の所属か知 る。
次は、Web serverにアクセスしてみる。
sakae@fb:/tmp $ w3m -dump_head https://www.hogefuga-cc.jp/ HTTP/1.1 200 OK Date: Mon, 08 Jul 2024 20:54:20 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 8009 Connection: close Server: Apache X-Powered-By: PHP/7.3.33 Vary: Range,Accept-Encoding Content-Encoding: gzip X-Cache: MISS Accept-Ranges: bytes
Apacheのバージョン情報は抑制してあるけど、PHPは丸出しじゃん。PHPは穴の 宝庫だから、やりがい、もとえ、調べがえがあるぞ。
Vulnerability & Exploit Database
metasploit ruby-gemで作成された、攻撃用の モジュール。上のdbと連携させると、便利らしい。
The Metasploit Framework The Metasploit Framework is an open source platform that supports vulnerability research, exploit development, and the creation of custom security tools. The goal is to provide useful information to people who perform penetration testing, IDS signature development, and exploit research. This site was created to fill the gaps in the information publicly available on various exploitation techniques and to create a useful resource for exploit developers. The tools and information on this site are provided for legal penetration testing and research purposes only.
FreeBSDでもパッケージになってたので、時々刺さる(USB drive)に入れてみた。
sakae@slfb:~ $ msfdb init & msfconsole Could not find compatible versions Because every version of sinatra depends on rack >= 3.0.0, < 4 and every version of thin depends on rack >= 1, < 3, every version of sinatra is incompatible with thin >= 0. And because every version of metasploit-framework depends on thin >= 0, every version of sinatra is incompatible with metasploit-framework >= 0. So, because every version of metasploit-framework depends on sinatra >= 0 and Gemfile depends on metasploit-framework >= 0, version solving has failed.
メチャメチャ文句を言われた。世間の人は、どうしてるのだろう？
Kali LinuxのMetasploitで脆弱性を突いたペネトレーションテスト
【入門】Metasploit Framework【ペネトレーションテスト用】
Metasploitの基本的な使い方を解説【Kali Linux】
どうも、Kali Linuxが鉄板みたい。後は仕事用のCentOSとかだな。Debianみた いな遊び人には、余り需要が無かったりして。