プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

/proc ファイルシステムの重箱の隅をつつく その1 このエントリーをはてなブックマークに追加

シリーズ化をもくろんでいるのでその1などとつけてみました。
今回は/procファイルシステムの内、以下の文書でドキュメント化されていないものを
ほげりましょう。ってな趣向です。

第一回はauxvインターフェースです。
/proc/[pid]/auxv にて取得できます。auxvというのはプロセスをexecするときに
カーネルが生成プロセスに引き渡す情報のうちコマンド引数と環境変数に
おさまらない、補助的な(Auxiliary)情報ってことですわ。

選んだ理由はあんまりないんですが、ま、こっそりオモロイ情報でも
渡してたら、楽しい使い道が思いつくかな。と

と、いうのはタテマエで辞書順で先頭に表示されるファイルだからですな。
なんて適当。







んで、さっそくですがLinuxのカーネルの linux/fs/binfmt_elf.c あたりを
つらつらと・・・
うーん、#ifdef分かりにくいのー

とりあえず、


----- 32bit
/ |
↓ ↓
+------+-------+------+-------+------+-------+------+
| id | val | id | val | id | val | 0 |
+------+-------+------+-------+------+-------+------+


こんな感じで IDにAT_NULL(0)が現れるまで、32bitのIDとvalueが交互に現れることが
分かったのでなんちゃってリードプログラムで実際に読んでみる。
(30秒ハックになのでバグってても苦情はうけつけません)

ソース: http://mkosaki.web.fc2.com/read_auxv.c
↓ 結果 フォーマットは 名前: valの10進値(valの16進値)

$ ./read_auxv 3184
AT_HWCAP: 58979327(383f3ff)
AT_PAGESZ: 4096(1000)
AT_CLKTCK: 100(64)
AT_PHDR: 134512692(8048034)
AT_PHENT: 32(20)
AT_PHNUM: 7(7)
AT_BASE: 0(0)
AT_FLAGS: 0(0)
AT_ENTRY: 134546208(8050320)
AT_UID: 500(1f4)
AT_EUID: 500(1f4)
AT_GID: 500(1f4)
AT_EGID: 500(1f4)
AT_SECURE: 0(0)
AT_PLATFORM: -1074135045(bff9fffb)
AT_NULL: 0(0)


あとは、このシンボルでカーネルソースgrepして順に読んでくだけや。
で、結果

順番に解説すると


AT_HWCAP: プラットフォーム(というよりCPU)依存な値
x86プラットフォームではcpuid命令の結果が格納されている
bitの意味は http://www.sandpile.org/ia32/cpuid.htm
「standard level 0000_0001h」のEDXレジスタの項を参照のこと。
AMD拡張が取得できないので3D NowもNX bitもx86_64対応も
取得できず、今となっては片手落ちなこと
cpuid命令は特権を必要としないので、こんなもん使わなくても
ユーザーランドで苦もなく全情報とれることから
あまり有用とは思えない
AT_PAGESZ: 読んで字の如し。メモリのページサイズが4kだと言っている
AT_CLKTCK: sysconf(_SC_CLK_TCK) で取得できる clock_t分解能
AT_PHDR, AT_PHENT, AT_PHNUM: 実行ファイルのELFヘッダの位置・サイズ、ランタイムリンカが使う
AT_BASE: なんで0になってるんや??
AT_FLAGS: Linuxでは常に0
AT_ENTRY: 実行ファイルのエントリポイント、ランタイムリンカが使う
AT_UID, AT_EUID, AT_GID, AT_EGID:
アクセス権。suid, fsuidが知りたかったら結局/proc読まんとならん。
ちゅーとはんぱやのー
AT_SECURE: libcをセキュアモードで動かして欲しいときは1.
伝統的な意味では (uid != euid) || (gid != egid) だが
SELinuxなどのセキュリティーモジュールをインスコしたときは
そちらの定義に従う。
とはいっても、glibcの関数でこのセキュアモードを意識する関数は
とーーーっても少ないので、普段あまり意識しない。
推測だけど、たぶん、過去にセキュリティーホールがあった関数しかチェックしてないんじゃないのか?
AT_PLATFORM: プラットフォーム文字列("i686"とか)へのポインタ



結論。
中途半端。過去の遺物。
だからイマドキの拡張はここの引数増やさずに/procにファイルが増えるのねん。となっとく。

少なくとも、よそのプロセスのauxv情報なんぞ読んでも
まるで役に立ちそうもありません orz
(せっかく解析したのに)



参考文献
----
カーネル付属ドキュメントの和訳 http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/proc.txt.html
Red Hat Enterprise Linux 4 のマニュアルの/procの章: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ja/ref-guide/ch-proc.html
SUSEのマニュアル:http://www.novell.co.jp/pdf/linux/administration.pdf
----
関連記事
linux | 【2006-02-15(Wed) 00:53:20】 | Trackback:(0) | Comments:(3)
コメント
このコメントは管理人のみ閲覧できます
2007-09-03 月 00:53:43 | | # [ 編集]
このコメントは管理人のみ閲覧できます
2007-10-10 水 09:32:17 | | # [ 編集]
このコメントは管理人のみ閲覧できます
2007-12-18 火 02:30:41 | | # [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。