[[katsuhiro]] -> [[katsuhiro/refmon]] -> katsuhiro/refmon/todo * To Do [#w0d33117] 未解決の問題が山積みでござる。 *制限 [#t220be86] -setuid されていても実効ユーザ ID は変化しません。 --ptrace の制限です。 *未解決で既知の問題 [#j47e7649] **シグナルのエミュレーション [#va9a5663] -sigaction の SA_xxxx というフラグに全対応していない。 -sys_kill やシグナルを受けて停止したときの処理が正しいのかよくわからん。 --man はなんとか動いているみたいだけど。mozilla の起動スクリプトを suspend したらフリーズする。 原因は恐らく 2.6 系の wait が変な動きをするからだと思う。 -2.6 系は一回 wait してしまうと、ptrace(PTRACE_SYSCALL, ...) を呼ばずには(TRACED 状態のまま?)次のシグナルが検知できない。 --SIGSTOP のエミュレーションとして、以下のような処理を考えていた。 --wait で子プロセスにシグナルが来るのを待つ --SIGSTOP が来た: 何もしない(子プロセスは TRACED 状態のまま) --SIGCONT が来た: ptrace で次に進める(子プロセスは RUNNING 状態になる) --再び wait する --でも残念ながら、SIGSTOP の後、SIGCONT を送っても、リファレンスモニタの wait が戻ってきません、よって動きませんでした。 **スレッド用のシグナルのエミュレーション [#hed994a9] -tkill や tgkill はまだ。 **clone のエミュレーション [#ufa304bf] -ptrace の禁止(CLONE_UNTRACED(Linux 2.5.46 以降))が指定されていたらつぶさなければならない。 -スレッド ID を返す呼び出し(CLONE_THREAD)の動作はするが、スレッド ID を使える関数群のエミュレーションはしていない。 -シグナルハンドラの共有(CLONE_SIGHAND)のエミュレーションはしていない。 --CLONE_PARENT_SETTID, CLONE_CHILD_SETTID, CLONE_CHILD_CLEARTID (Linux 2.5.49 以降)もエミュレーションしていない、というよりしなくてもいいのかもね? -vfork の動作(CLONE_VFORK)はサポートする予定なし。 **wait のエミュレーション [#wbd41e90] -外部からスレッドグループを取得する方法が無い。そのため wait のオプションに __WNOTHREAD を指定されると非常に困る。 --妥当なやり方としては、clone のフラグを見張って CLONE_THREAD が指定されたら、clone の返り値(スレッド ID が入ってる)を覚えておくとか。 --関連: プロセスグループ ID(pgid)は外部から取れるので特に問題は無い。 -それ以外はなんとかなったっぽい。 -2.4 でさえ面倒なのに、2.6 系だとオプションが増えて、sys_waitid も追加された。やる気なくなるなあ。 -sys_pause と sys_nanosleep の動きがおかしくなってる気がするので、これもエミュレートが必要かもしれない。2.6 系だとまた違ってややこしい。 --sys_pause は何もしなくても大丈夫?ほんと? **ptrace のエミュレーション [#r2feef54] -ptrace しているプロセスはどんなシグナル(無視されるシグナル)でも停止しなければならない。 -特殊な動きをするシステムコールがある。 --sys_execve のあとに SIGTRAP を送るなど。 -wait 系がおかしくなる動作(2.4系の)をエミュレーションすべきだろうか。やらないと refmon on refmon をやったときにおかしくなるかもね? --そうならないようにすべきですね…。 **コールスタックトレース [#aa0eea19] -sys_mmap2 が来た時はトレースできない。ebp に第 6引数を入れて潰してくるため、スタックフレームの開始位置がわからない。何この仕様…。 --関連: sys_mmap の場合は、5個以上の引数を持ったシステムコールを呼び出すときのお決まりの手(?)で、スタックに引数を積んで、第 1引数にポインタを指定する渡し方です。 **ELF ファイルの読み込み [#p9e3ae9c] -ELF の定義が難しくてよくわからない。固定配置のセクションは読めているが、再配置可能セクションの意味が良くわからん。 **ARM へのポーティング [#x53dc245] -スタックの使い方がまちまちなため、スタックトレースがうまくとれないかもしれない --少なくとも gcc は fp を使ってスタックフレームの開始位置を保存する方法と、そうしない方法の二つを使う --リターンアドレスから返る先の関数を調べておいて、関数の先頭にある命令を調べると大体わかるかもしれない。 ---strip されると動きませんが、何か? -システムコール番号を書き換えても反映されない。 --i386 では特に問題のなかった点だった。これはカーネルパッチを作るしかない? *不安な点 [#lc5ec8f4]