Linux kernel
ひょんな事から、パソコン整備士って言う資格が有る事を知った。車の整備士とか 飛行機の整備士なら知っているんだけど、これは初耳。
国家資格なの？ それともMSが副業でやってる、ブロンズ、シルバー、ゴールド 資格みたいに、特定企業とかがやってるものなの？
軽く調べてみたら、民間が勝手にやってるようだ。３級、２級、１級という区別が あるようだ。いきなり、１級受験って訳にはいかず、まず３級を取って、協会の 会員になり、段階的に上位の級を目指すようになってるらしい。
お金ががっぽがっぽ入ってくる仕組み。対策本とか講習とか儲かるように出来て いる。
パソコン整備士協会 を訪ねると、 模擬問題が掲載されてた。試しに、３級を受けてみた。だって、３級も持って いませんから。 24問中21問が正解で、合格レベルですってさ。間違ったのは 引っ掛け問題ぽい。
よいしょして、ひっぱりこむ戦略だな。その手には乗るまい。
121ware.com > 活用情報 > パソコンお役立ち講座 こんな、お友達サイトも紹介されてた。ワードとエクセル、キーパンチャーが 人気の講座みたい。自治体がやってるパソコン講座も、こういうのに加えて、 スマホとかでSNSとかやってる。基本素養なんだな。
そう言えば、Linuxにも試験が有ったな。 IT資格といえば Linux技術者認定試験LPIC | LPI-Japan やはり、３段階有るんだ。
最上位はLPIC-3で、混在系、セキュリティ系、仮想系と言う具合に専門分野に 分かれるのね。
仮想系って、vboxとかqemuとかからも出題されるのかな？ いや、雲の上の 話だろうな。
KVMはなんたらかんたらって例が出てた。kvm-qemuなんてのが出てるんで、一応 qemuも大事な技術だよーんて、認めてくれているのね。
これからも、一生懸命に精進しまーす！！
diskを縮小する
って言っても、VMWAREのdsik shrinkの事ではない。前回やった、ラズパイの 話である。
fdiskで確認すると、２つのパーテションが有った。最初のやつは、Windowsが読める やつ。後ろの方はLinux専用のやつ。世の中には、Windowsが蔓延してるんで、 ラズパイ用のDISK作成は、Windowsでやって下さいって魂胆だな。
最初のやつには、ラズパイのハードが理解出来るブートローダーが入っているんだな。 まずそれを取り込んで、起動させる。その力を借りて、Linuxのパーテションから カーネルを起動させるって寸法だろう。
今回は、いきなり、Linuxのパーテションをマウント。それをするために、マウント時に ファイルの途中から読むよう、オフセットを持たせた。そんな数字、いちいと覚えて いられるかい。だったら、スクリプトにしとけばいいじゃんってのは、アプルの流儀 シンプルであれってのを逸脱してるんで却下。
最初のパーテションを削除しちゃえば、わざわざオフセットを持たせて、マウント するなんて無駄だ省けるはず。さてどうする。
こんな事もあろうかと、unixの道具屋さんは、ちゃんと考えていた。ファイルの コピーツールである、ddには、ファイルの途中からとかを指定してコピー出来る 機能が有る。元は、Diskファイルのコピーを主眼にしてるんで、基本的に指定する 単位は、ブロック(512Byte)になってる。
前置きが長くなった。早速やってみる。（入力ファイル名は、前回は年月日まで 付いてまのだったけど、unix流に少々短くしてる）
sakae@ub:~/ARM-rp$ dd if=wheezy-raspbian.img of=disk.img skip=122880 5662720+0 records in 5662720+0 records out 2899312640 bytes (2.9 GB, 2.7 GiB) copied, 254.997 s, 11.4 MB/s sakae@ub:~/ARM-rp$ ls -l *img -rw-rw-r-- 1 sakae sakae 2899312640 Aug 30 05:51 disk.img -rw-r--r-- 1 sakae sakae 2962227200 Aug 28 14:04 wheezy-raspbian.img
多少は、ファイルが縮小された。これで動くかな？
sakae@ub:~/ARM-rp$ sudo mount disk.img rootfs sakae@ub:~/ARM-rp$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 2721336 1775388 787996 70% /home/sakae/ARM-rp/rootfs sakae@ub:~/ARM-rp$ sudo chroot rootfs root@ub:/# uname -m armv7l root@ub:/# exit exit
前回は、使うCPU名を環境変数で与えて、起動したけど、うっかりそれを忘れていた。 でも、ちゃんと動いた。ハード名からすると、多少新しいCPUで動いてるようだ。
armv7lって、どゆ事？ armv7までは分かるんだけど。最後のlは？
こういう規約で略してるんだな。
それはそうと、diskサイズに対する、有効に使える大きさが、随分違うな。
sakae@ub:~/ARM-rp$ bc scale=6 2721336*1000/2899312640 .938614
利用率が94%か、残りの6%は何に使われているの？ファイルの台帳と、利用ブロックを 登録しとくMAP領域か。これは、固定的に取られるからなあ。
ああ、新たに作ったイメージファイルは、平べったいものになってるけど、リナちゃん は、どんな風に認識してる、一応聞いてみるか。
sakae@ub:~/ARM-rp$ file disk.img disk.img: Linux rev 1.0 ext4 filesystem data, UUID=fc254b57-8fff-4f96-9609-ea202d871acf (extents) (large files)
ラズパイもext4が標準なのか、それともラズパイに載せるOSをクロス開発してて、 それのリナちゃんのファイルシステムを継承してるのかな？ 一度、開発者に 聞いてみたいものだ。
update-binfmts --display
で、使う、データベースは、何処に有るの？
manを流し読みしたけど、見つからず。ってか、BSDのマニュアルだと、関係 ファイルは、これとか、環境変数はこれが使えるからねって、まとまって 説明されてるんだけど、リナには、そういう作法が無いようだ。
よって、動きをスパイする事にした。
sakae@ub:/tmp$ strace update-binfmts --display 2>LOG
sakae@ub:/tmp$ grep open LOG
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/i386-linux-gnu/libpipeline.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/var/lib/binfmts", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
open("/var/lib/binfmts/qemu-mips", O_RDONLY|O_LARGEFILE) = 4
open("/var/lib/binfmts/qemu-mips64", O_RDONLY|O_LARGEFILE) = 4
:
これを元に、manをgrepすると
--admindir directory
Specifies the administrative directory, when this is to be differ‐
ent from the default of /var/lib/binfmts.
回り道して、やっと見つける、オイラーの眼は、英語に難がある事はよく分かる 事例でしたよ。やっぱり、洋物には弱いな。
sakae@ub:/tmp$ cat /var/lib/binfmts/qemu-arm qemu-user-static magic 0 \x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00 \xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff /usr/bin/qemu-arm-static yes
こいつらを玩べば、どうにでもなるんだな。ウィルス作者さん、注目ですよ、って 煽ったら、幇助罪になるんでしょうか？ さすがに、このファイルは見るだけねって、なってましたよ。
ここまではいいんだけど、armなファイルシステム中に入っている、qemu-arm-static ってファイルを見えなくしたりパーミションを落としておくと、/bin/bashの 起動時に失敗してた。
その時の現場を押さえるために、straceしてログを眺めてみたけど、エラーを 報告してくるまでの動きが謎。当然、上記のDBもどきを参照してると思ったんだけど、 そんな素振りすらない。Linuxは謎めいているからなあ。何か手がかりは無いか、 と、推理小説風に悩むのであります。
chrootが怪しいとにらんで、man chroot 及び man 2 chroot して、差分を取って みると、システムコールの方は、引数としてpathが渡ってくるだけ。対して ユーザーが使う方は、起動プログラムを指定（指示しない場合は、/bin/shが自動的 に使われる)出来るようになってる。
よってこの余計な事は、glibcがやってる。ひょっとして、ここにDBのpathとかが 埋め込まれていないかな。得意のstringsでスキャンしたけど、形跡無し。
探偵は、手がかりを求めて、再び、man update-binfmts を精査する。探偵小説では 虫眼鏡を片手に床にへばりついて、痕跡を探すって表現される所です。
DESCRIPTION
Versions 2.1.43 and later of the Linux kernel have contained the
binfmt_misc module. This enables a system administrator to register
interpreters for various binary formats based on a magic number or their
file extension, and cause the appropriate interpreter to be invoked when‐
:
便利だから、2.1.43以降のLinuxに機能を追加したよ。binfmt_misc ってモジュール にくくり出してあるとな。これ、手がかりになりそうだな。当ってみるか。
sakae@ub:~$ lsmod : binfmt_misc 20480 1 :
うん、確かにロードされてるな。今度は、これの関係者に当ってみる。
sakae@ub:~$ locate binfmt_misc /home/sakae/eabi-chroot/lib/systemd/system/proc-sys-fs-binfmt_misc.automount /home/sakae/eabi-chroot/lib/systemd/system/proc-sys-fs-binfmt_misc.mount /home/sakae/eabi-chroot/lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.automount /lib/modules/4.4.0-31-generic/kernel/fs/binfmt_misc.ko /lib/modules/4.4.0-34-generic/kernel/fs/binfmt_misc.ko /lib/systemd/system/proc-sys-fs-binfmt_misc.automount /lib/systemd/system/proc-sys-fs-binfmt_misc.mount /lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.automount
どうやら、このモジュールは、ファイルシステムの系列に分類されるようだ。
sakae@ub:~$ cat /lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.automount # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Arbitrary Executable File Formats File System Automount Point Documentation=https://www.kernel.org/doc/Documentation/binfmt_misc.txt Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems DefaultDependencies=no Before=sysinit.target ConditionPathExists=/proc/sys/fs/binfmt_misc/ ConditionPathIsReadWrite=/proc/sys/ [Automount] Where=/proc/sys/fs/binfmt_misc
臭そうな名前のやつから当るのが定石です。臭そうなのは長年の勘で決めるの？ オイラーは、ピピィーと、sysinitってのとwantに反応したよ。
手がかりが出てきましたなあ。
sakae@ub:~$ ls /proc/sys/fs/binfmt_misc python2.7 qemu-armeb qemu-mips64 qemu-ppc64abi32 qemu-sparc python3.5 qemu-cris qemu-mips64el qemu-ppc64le qemu-sparc32plus qemu-aarch64 qemu-m68k qemu-mipsel qemu-s390x qemu-sparc64 qemu-alpha qemu-microblaze qemu-ppc qemu-sh4 register qemu-arm qemu-mips qemu-ppc64 qemu-sh4eb status
これ、/var/lib/binfmtに有ったやつとそっくりさんですよ。そんじゃ、どれか 一つ中身を開いてみろ。それから、作成時間にも当れ。
sakae@ub:~$ cat /proc/sys/fs/binfmt_misc/qemu-arm enabled interpreter /usr/bin/qemu-arm-static flags: OC offset 0 magic 7f454c4601010100000000000000000002002800 mask ffffffffffffff00fffffffffffffffffeffffff
作成時間は、OSを起動した時間だったよ。起動時から、常に変換機能が働いて いるんだな。だから、chrootする度にえっちら・おっちら呼び出す事はしない。 一種のキャッシュとして、アプリの起動時間短縮に貢献させてるんか。 システムコールでもないので、straceしても引っ掛かってこない。カーネルが 闇に隠れてこっそり行う行為。
kernel
今まで、Linuxのソースは避けてきたんだけど、いよいよカーネルまで潜って行く 必要が有りそう。何処に入れる？ 巨大なものらしいから、Diskがたっぷり空いて いる所が良いな。vbox上のDebianを選択した。
なお、報道によると、 Linux，25歳になる みたいですな。よく、一つの事を25年も続けられるものだ。感心しちゃうぞ。 そういうお前も、サラリーマン、35年以上もやってただろうに。まあ、飯を 喰わねばならないからね。
linux-source-3.16 - Linux kernel source for version 3.16 with Debian patches
展開したら、800Mを超えてた。半分はドライバーなんだな。updatedbしておく。
sakae@debian:~$ locate binfmt_misc /lib/modules/3.16.0-4-586/kernel/fs/binfmt_misc.ko /lib/systemd/system/proc-sys-fs-binfmt_misc.automount /lib/systemd/system/proc-sys-fs-binfmt_misc.mount /lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.automount /usr/src/linux-source-3.16/Documentation/binfmt_misc.txt /usr/src/linux-source-3.16/fs/binfmt_misc.c
ドキュメントが有るようなので、目を通しておく。 ファイルのMAGICだけじゃなくて、拡張子でも指定出来るようで、wine経由で、 なんたら.exeっていう、Windowsアプリも違和感なく起動出来るようだ。 さすがやるな、ドイツ人。
binfmt_misc.cの中のこのあたりかな。
/*
* the loader itself
*/
static int load_misc_binary(struct linux_binprm *bprm)
{
これを経由で、.load_binaryに行き着き、それを経由で、fs/exec.cへ導かれた。
/*
* sys_execve() executes a new program.
*/
static int do_execve_common(struct filename *filename,
struct user_arg_ptr argv,
struct user_arg_ptr envp)
{
:
retval = exec_binprm(bprm);
if (retval < 0)
goto out;
どうやら、qemu-arm-staticは、ここから起動されてるっぽい。（嘘かも知れない けどね。）こういう時に、kernelのdebugモードに突入出来ればいいんだけど、 それをやるにには、オイラーのマシンは貧弱過ぎる。
ここまで、独自調査したけど、外部の有識者による解説と答え合わせ しとくかな。
読み取り権限がなく実行権限だけのファイルが実行できるのはなぜ？ - カーネルのソースを読む
おお、これは良い資料だ。有り難く使わせてもらいます。