天泣記

2014-09-03 (Wed)

#1

ふと openSUSE 13.1 を install してみた。lsb_release の Description と /etc/os-release の PRETTY_NAME は一致しているようだ。

% lsb_release -a
LSB Version:    n/a
Distributor ID: openSUSE project
Description:    openSUSE 13.1 (Bottle) (x86_64)
Release:        13.1
Codename:       Bottle
% cat /etc/os-release
NAME=openSUSE
VERSION="13.1 (Bottle)"
VERSION_ID="13.1"
PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

なお、サーバ (テキスト環境) をインストールしたのだが、lsb_release はなかったので、zypper install lsb-release として lsb-release パッケージをインストールした。

また、/etc/SuSE-release と /etc/SUSE-brand というものもあった。

% cat /etc/SuSE-release
openSUSE 13.1 (x86_64)
VERSION = 13.1
CODENAME = Bottle
# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead
% cat /etc/SUSE-brand
openSUSE
VERSION = 13.1

2014-09-06 (Sat)

#1

Ruby で system, spawn メソッドなどコマンドを起動するところに vfork システムコールを使ってみた。 (現在の trunk に入っており、消されなければ Ruby 2.2 に入る。)

vfork というのは危険だけれど速い fork システムコールである。

Unix におけるコマンドの起動は、まず親プロセスが fork でプロセスを複製し、そうやってできた子プロセスが execve でプロセスを別のプログラムに入れ替える。

ここで、たいていは fork してすぐに execve するので、時間をかけてプロセスのメモリをコピーしたあげくにすぐに捨てる、という動作が無駄で遅い、というのが古代の Unix では問題だったそうな。

そこで BSD のひとが、子プロセスが execve するまでは親のメモリをそのまま使えばいいじゃない、と考えてそういう動作を行う vfork を作った。 これは無駄な動作がなくなるので実際に速くなった。 なお、親子が同じメモリで同時に動作するとまともに動かないのが明らかなので、子プロセスが execve する (あるいは _exit などで終了する) まで親プロセスは停止する。

とはいえ、子プロセスがメモリを書き換えた結果が親プロセスから見えるとか、ちょっとありえないと言いたくなるような動作で、vfork がよろしくないことは初めから分かっていた。 だから仮想メモリで copy-on-write を実現して、あたかもコピーしたかのように見えるけれども実際にはコピーしていないので速い、という動作を fork で実現したら vfork を捨てようという話ではあったようだ。

そして時が経ち、現代では fork が copy-on-write にするのは普通で、速くなった。 だから vfork は忘れましょう、というのが普通の認識だろう。

しかし、仮想メモリで copy-on-write とはいえ、子プロセスのメモリをそういうふうに設定しないといけないので、親プロセスがメモリを使えば使うほど fork が遅くなるという傾向は変わっていない。 vfork にその傾向はない (あるいは低い) ので、親プロセスが大きくなればそのうち vfork のほうが明確に速くなるだろう。

追記: 「子プロセスのメモリをそういうふうに設定」というのは、もっとちゃんと述べると、 copy-on-write な fork では、親プロセスと子プロセスがメモリをread onlyで共有するようにページテーブルを設定するが、これにはページの数に (つまり使用メモリ量に) 比例した時間がかかる、という意味である。 なお、この状態では、どちらかのプロセスで書き込みがおこるたびにページフォルトが起こり、必要なら新しいページを確保してコピーして書き込み可能にして、書き込みを続行する (copy-on-write)。 しかし、子プロセスが exec した後でも、親プロセスのページテーブルがそのままになっていると、親プロセスがread onlyなページに書き込むたびに (コピーは起きないものの) ページフォルトは起こるかもしれない。 これは、親プロセスを遅くするような気がする。 この動作については「NetBSD ドキュメンテーション: なぜ伝統的な vfork()を実装したのか」に説明がある。

もうひとつの問題はメモリのオーバーコミット (利用できるよりも多くのメモリをプロセスに割り当てること) を許していない場合に、 巨大なプロセスの fork が失敗しがちになるということである。 fork すると親プロセスと同じ量のメモリが子プロセスに割り当てられるので、必要なメモリは 2倍になる。 極端な場合として、利用できるメモリの半分よりも大きなプロセスは fork できないことになる。 vfork であれば、子プロセスは親プロセスのメモリをそのまま利用するので、この問題は発生しない。

#2

というわけで、vfork を使ってみたわけだが、まず現実的なメモリ量で速くなるのか、という疑問を解決するために測定してみた。現実的なメモリ量で速くならないなら、あまり魅力はない。

以下のようにして測定してみた。

% uname -mrsv
Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64
% ./miniruby -Ilib -rbenchmark -e '
str = "a" * 1000;
23.times {
  mem = File.read("/proc/self/status")[/^VmSize:\s*(\S+)/, 1]
  str << str
  time = Benchmark.realtime { system("true") }
  puts "#{mem} #{time}"
}'

で、プロットしてみた。

結果としては、vfork のほうがあからさまに速い。ruby (miniruby) が起動したあたりのメモリ量 (21MB 強) ですでに数倍の速度が出ている。メモリが大きくなるにつれて差は広がり、プロセスが 4GB くらいになるまで測っているが、そこでは 200倍以上になっている。

#3

というわけで、速度を考えるとぜひ vfork を使いたい。

しかし、vfork は危険である。わかりやすいのは CERT の Secure Coding で、 POS33-C. Do not use vfork() と明確に「使うな」と書かれていることだろう。(JPCERT による和訳)

この危険性を確信を持って避けられるか、というのが問題である。

fork に対する vfork の違いは以下の 2点である。

• 親プロセスと子プロセスでメモリを共有する。
• 親プロセスは子プロセスが execve/_exit するまで停止する。 (親プロセスがマルチスレッドだった場合、vfork した以外のスレッドが停止するかどうかははっきりしない。おそらく、動く環境と動かない環境がある)

メモリの共有で問題が起きないように、メモリの使い方を以下のように制限する。

• 子プロセス
  • 書き換えてよいメモリはスタックだけ。 しかも、vfork を呼び出したスタックフレームから奥は壊してはいけない。(vfork を呼び出した関数から return してはいけない)
  • 参照してよいメモリはスタックを除けば変化しないものだけ。 とくにグローバル変数は参照しない。
• 親プロセス
  • 親プロセス全体が停止するなら、なにもできないのでそれ以上に制限することはない。
  • vfork を呼び出した以外のスレッドが停止しないなら、 それらのスレッドは vfork したスレッドのスタックを参照しても書き換えてもいけない。 (他のスレッドのスタックをいじらないというのは普通のことなので難しい話ではない)

親プロセスで制限を守るのは難しくない。しかし、子プロセスについては簡単ではない。

いずれにせよ制限を守れなかった場合には、子プロセスが親プロセスに影響を及ぼす、あるいはその逆が起こり得る。このとき、子プロセスと親プロセスの権限が異なるとセキュリティ問題 (権限昇格) に発展するかもしれない。vfork した直後は親子の権限は同じなので、その後でどちらかが setuid などで権限を変化させる場合が問題である。このため、setuid などが可能なプロセス (root のプロセスや、setuid/setgid されたコマンドから起動されたプロセス) では vfork を使わないことにする。

具体的に、子プロセスでスタック以外のメモリを変更するコードが動くことを防ぐことについては以下のように考えてみた。

• ライブラリ関数は async-signal-safe な関数のみを使う。 vfork でなく、fork した子プロセスでもこれはそうしなければならないので、いままでどおりである。 async-signal-safe な関数ではグローバル変数の状態が一貫していることを期待できないので、グローバル変数を使わないと期待される。 でも、その期待が本当にそうなのかというとどうなのかなぁ。
• exit では stdio の flush や atexit で登録した関数が動いたりするので使わない。 かわりに _exit を使う。 これは vfork の使い方で必ず説明される話である。 なお、exit は async-signal-safe ではないので、これは上の項目の例である。
• signal handler もグローバル変数を書き換えたりするなど制限に反する動作が行われる可能性がある。 そこで設定された signal handler はすべて SIG_DFL に設定しなおす。 このとき、SIG_DFL に変える前に呼び出されるという race condition を防ぐため、vfork の前に親プロセスでいったんすべての signal を mask しておく必要がある。 子プロセスでは SIG_DFL に変えた後に mask を戻す。 もちろん親プロセスでも mask を戻す。 なお、glibc では NPTL で使われる SIGCANCEL (__SIGRTMIN) と SIGSETXID (__SIGRTMIN + 1) は mask できないようである。 これについては次に述べる。
• pthread_cleanup_push で登録した cancellation cleanup handler も呼び出されるのは困る。 glibc では cancel は SIGCANCEL で実装されているようだが、上記のように SIGCANCEL は mask できない。 ただ、sigcancel_handler, sighandler_setxid を調べると、SIGCANCEL, SIGSETXID を受け取ったときは、 呼び出し元の pid が他のプロセスなら単に return するので他のプロセスから問題を起こすことはできそうにない。 そして、vfork したプロセス自身から cancel をすることもない。 このため、cleanup handler が呼び出されることはない。 (だから少なくとも glibc では関係ないのだが) いちおう、親プロセスで pthread_setcancelstate で PTHREAD_CANCEL_DISABLE して cancel が無効であることを宣言することもできる。
• vfork 時に pthread_atfork() で設定された fork handler が呼び出される可能性がある。 vfork は fork と基本的には同じ仕様なので、fork handler を呼び出してもおかしくない。 ただ、NPTL では呼び出さないらしく問題ない。 でも、LinuxThreads では呼び出すらしい。(LinuxThreads なら vfork を使わないようにしたほうがいいかもしれない。)

他に、意図せざるコードが動く可能性はあるだろうか。RTLD とか? async-signal-safe な関数をスレッドライブラリが wrap しているかもしれないのも心配。

#4

調べると、vfork を実際に使う話はいくつか見つかる。 libc で posix_spawn を実装する時に使う、というのが多い。

• vfork considered dangerous, musl libc のひとが、posix_spawn の実装に vfork を使ってすごく厄介だったという話。 signal, thread, setuid との関連。
• CERT Secure Coding: POS33-C. Do not use vfork() JPCERTによる和訳 vfork は使うな。
• Secure Programming for Linux and Unix HOWTO 8.6. Avoid Using vfork(2) vfork は使うな。

• glibc の posix_spawn の実装 sysdeps/posix/spawni.c vfork が (POSIX_SPAWN_USEVFORK を指定しなくても) 有効になるのは以下の条件が成り立ったとき

  (flags & (POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF
                     | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER
                     | POSIX_SPAWN_SETPGROUP | POSIX_SPAWN_RESETIDS)) == 0
  && file_actions == NULL

• glibc bugzilla: Bug 378 - posix_spawn implementation, use vfork/execve rather than fork/execve for NPTL Linux. (2004-09-10) posix_spawn で vfork を使おうという最初の提案。 子プロセスで動く atfork handler が親プロセスを壊したらどうするのか、というのが懸念されている。 自己責任で、ということで POSIX_SPAWN_USEVFORK が追加された。
• glibc bugzilla: Bug 10354 - posix_spawn should use vfork() in more cases than presently (2009-06-30) vfork をもっと使ってほしいという要望に対し、すべての file operation は cancellation point だからそういうのを使う場合はダメ、と返されている。
• glibc bugzilla: Bug 14749 - Dangerous race condition with vfork in posix_spawn (2012-10-21) どっちかが setuid すると、メモリ共有でまずいことが起きるかも。
• glibc bugzilla: Bug 14750 - Race condition in posix_spawn vfork usage vs signal handlers (2012-10-21) signal handler でまずいことが起きるかも。
• NetBSD ドキュメンテーション: なぜ伝統的な vfork()を実装したのか NetBSD 1.3 で伝統的な vfork を実装した。いまでも fork より vfork が速い理由。
• NetBSD: posix_spawn syscall added 2011年から2012年ごろに NetBSD は posix_spawn をシステムコールとして実装した。
• FreeBSD の posix_spawn 常に vfork を使っていて、signal や setuid はとくに気にしていない?
• freebsd-hackers: system() using vfork() or posix_spawn() (2012-08-09) vforked child が sigaction を呼んだときに、親プロセスの他のスレッドも sigaction を呼んでいるとちゃんと同期しないといけないと指摘がある。 ユーザメモリに lock があって排他しているような関数は async-signal-safe ではないので呼んではいけないというのが基本だろうが、 signal まわりはいじりたいのも確かではある。 でも、SUSv4 では、sigaction, sigprocmask も含め、signal まわりの関数は async-signal-safe だから問題ないかも。
• freebsd-hackers: Change vfork() to posix_spawn()? (2012-09-14) FreeBSD では vfork した子プロセスが exec/exit するまでは stop signal を受け付けないとか、 POSIX_SPAWN_RESETIDS は euid/egid しか変えなくて、scheduling parameter を変更する権限には関係ないから問題ないぽいとか、いろいろな考察が書いてある。
• OpenBSD and vfork OpenBSD の vfork は exec/_exit するまで親を待たせる fork として実装されている。 メモリは共有されない。
• uClinux: We have no Fork uClinux には fork がなく、vfork がある。
• Solaris: Minimizing Memory Usage for Creating Application Subprocesses マルチスレッドな親プロセスから vfork したとき、子プロセスで dynamic linker が動くと、 そこで lock が必要になり、親プロセスですでに lock していると dead lock になる。 これは、親プロセスでは、vfork を呼ばなかった別スレッドも止まっていることを意味するように思える。
• 古い Autoconf のマニュアルの和訳の AC_FUNC_VFORK の項 AC_FUNC_VFORK の説明の中に「ただし、子プロセスでsignalを呼んでも 親プロセスのシグナルハンドラが変更されない場合には これはバグつきとはみなされません。」という記述がある。 これは、子プロセスで signal を呼んだときに、親プロセスのシグナルハンドラが変更される環境があることを示している気がする。 シグナルハンドラの設定がユーザメモリにある環境が存在する? むしろそうなってもらっては困るのだが。
• vfork and the signal race GNUnet で vfork が必要になった状況について。 vfork をつかうと、子プロセスが exec するまで親プロセスが動かないので、 その時間に親プロセスのシグナルハンドラが動くことがなく、それが都合がいい、という話。 fork でも避けることは可能だがエレガントでないという主張。

追記

• 2011 Ruby: posix-spawn 0.3.0 (gem) Ruby の posix-spawn gem は posix_spawn を使ってプロセスを起動する。
• 2013 fish: Release Notes for fish GitHub fish-shell/fish-shell#11 fish 2.0.0 で、可能なら posix_spawn を使うようになった
• 2015 Kazuho's Weblog: How to properly spawn an external command in C (or not use posix_spawn) glibc の posix_spawn は execve に失敗しても posix_spawn 自体は成功してしまうので、使えない。 コマンド起動は fork と FD_CLOEXEC な pipe を使って実装する。 (この glibc の posix_spawn の問題は glibc 2.24 で解決している)
• 2015 ruby: deadlock on Solaris 10 since r50900 現在の Solaris でも vfork を使うと dynamic linker で問題が発生する
• 2015 D: std.process: use vfork when possible D で vfork を使うという提案。vfork で作られた子プロセスでは execve と _exit 以外のシステムコールは呼べないからダメ、ということで reject されている。 clone() ならいいのではないか、とコメントされている。
• 2016 FreeBSD vfork.2 libthr では signal handler が部分的に user space で実装されているので親プロセスの状態を壊すという記述が足されている。
• 2016 glibc: posix: New Linux posix_spawn{p} implementation glibc の posix_spawn は vfork じゃなくて、clone システムコールを直接使うようになった。 これにより子プロセスのスタックは新しく確保されるようになり、親プロセスのスタックは共有されないのでトラブルが減る。
• 2016 perl5: vfork should be used for spawning external processes github issue perl で vfork を使うようにする提案
• 2017 golang: syscall: use CLONE_VFORK and CLONE_VM Go言語でも clone システムコール (に vfork 相当の親子プロセスでのメモリ共有をするフラグを指定したもの) を使うようになった。 プロセスを起動するときに、他の全ての goroutine が止まることによって、全体のスループットが落ちることが問題として述べられている。 対応するissue: syscall: use posix_spawn (or vfork) for ForkExec when possible #5838
• 2017 OCaml: spawn 0.9.0 (opam package) OCaml でプロセスを起動するための opam パッケージ。 起動するプロセスのカレントディレクトリを指定できる、 エラーの情報を適切に得られる、 可能なら vfork を使ってプロセスを起動する、 というのが主な狙い。
• 2018 ksh: Use fork()/exec() instead of posix_spawn() by default ksh は posix_spawnではなく fork/exec を使うように戻した。 posix_spawn だと terminal foreground process group を設定するのに race が発生してしまうのが理由。
• 2018 python: use os.posix_spawn in subprocess Python で posix_spawn を使うようにしようという話。 2019-10 にリリースされた Python 3.8 に導入された。
• 2018 Solaris: posix_spawn() as an actual system call Solaris 11.4 では posix_spawn は system call になる。(それ以前は vfork で実装されたライブラリ関数だった)
• 2018 GNOME/GLib: Use posix_spawn for optimized process launching glib では posix_spawn を使うようになった
• 2018 Rust: Command: Support posix_spawn() on FreeBSD/OSX/GNU Linux Rust は posix_spawn を使うようになった。glibc の場合、2.24 未満なら使わないようになっている。 posix_spawn_file_actions_addchdir_np が (Solaris および glibc 2.29 以降のように) 存在すれば 利用する。
• 2018 D: Use vfork on Linux when available D で vfork を使う提案。vfork した子プロセスでは _exit(2) か exec(3) family しか呼べないのでダメ
• 2018 D: Add bindings for POSIX's spawn.h D で posix_spawn への binding の追加が実装された
• 2019 glibc 2.29 glibc 2.29 では posix_spawn_file_actions_addchdir_np と posix_spawn_file_actions_addfchdir_np が追加された。
• 2019 python: Use vfork() in subprocess on Linux Python で vfork を使うようにしようという話。
• 2019 java: JDK 12 JDK 12 では、Linux 上で jdk.lang.Process.launchMechanism に POSIX_SPAWN を指定可能になった。 デフォルトは VFORK のままで変更なし。 (なお、他のプラットフォームではしばらく前から POSIX_SPAWN がデフォルトな模様)
• 2019 .NET: Use vfork() improve performance when starting processes. .NET でも vfork を使うようになった。パッチを見ると、OS X では使わないようになっている。
• 2020 GNU make: GNU make 4.3 released! きっかけとなった質問 パッチと議論 GNU make 4.3 は posix_spawn を使うようになった。 提案した人の理由は、fork と vfork はないけれど、posix_spawn はある、という環境で使いたい、というもの。 その環境は Threos と思われる。
• 2020 Let's talk about posix_spawn, and when to use it. posix_spawn の利点は速いこと。欠点は flexibility および error の扱い。 posix_spawn では tcsetpgrp を扱えないことを指摘している。 また、posix_spawn が子プロセスの中で行うさまざまな操作のどれが失敗したのか情報が得られない。

2014-09-07 (Sun)

#1

せっかくなのでもっと細かくデータをとってみた。

% ./miniruby -Ilib -rbenchmark -e '
str = "a" * 1000;
while str.length < 5_000_000_000
  mem = File.read("/proc/self/status")[/^VmSize:\s*(\S+)/, 1]
  str << str[0, str.length/100]
  time = Benchmark.realtime { system("true") }
  puts "#{mem},#{time}"
end'

#2

Mac OS X の posix_spawn には POSIX_SPAWN_CLOEXEC_DEFAULT というフラグが使えて、指定しなかった fd をぜんぶ close することができるようだ。これは良い方向だなぁ。

#3

せっかくなので posix-spawn gem も測って比較してみよう。

#!/bin/sh

echo func,mem,time

./ruby.fork -rbenchmark -e '
str = "a" * 1000;
while str.length < 5_000_000_000
  mem = File.read("/proc/self/status")[/^VmSize:\s*(\S+)/, 1]
  str << str[0, str.length/100]
  time = Benchmark.realtime { system("true") }
  puts "fork,#{mem},#{time}"
end'

./ruby.vfork -rbenchmark -e '
str = "a" * 1000;
while str.length < 5_000_000_000
  mem = File.read("/proc/self/status")[/^VmSize:\s*(\S+)/, 1]
  str << str[0, str.length/100]
  time = Benchmark.realtime { system("true") }
  puts "vfork,#{mem},#{time}"
end'

./ruby.vfork -rposix-spawn -rbenchmark -e '
str = "a" * 1000;
while str.length < 5_000_000_000
  mem = File.read("/proc/self/status")[/^VmSize:\s*(\S+)/, 1]
  str << str[0, str.length/100]
  time = Benchmark.realtime { POSIX::Spawn.system("true") }
  puts "posix-spawn,#{mem},#{time}"
end'

うぅむ。posix-spawn に比べて vfork はちょっと遅いなぁ。posix_spawn の中身は vfork なので余計な作業をしているということなんだけど、なんだろう。signal の設定とか、fd の close-on-exec の設定とか、そのあたりだろうか。

2014-09-08 (Mon)

#1

vfork した状態で setuid すると、本当に危険だろうか。ちょっと試してみよう。

% t.c
#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <wait.h>

int main(int argc, char *argv[])
{
  pid_t pid, pid2;
  uid_t ruid, euid, suid;
  int ret;
  int status;

  fprintf(stderr, "parent pid=%ld\n", (long)getpid());

  ret = getresuid(&ruid, &euid, &suid);
  if (ret == -1) {
    perror("getresuid");
    exit(EXIT_FAILURE);
  }
  fprintf(stderr, "parent ruid=%ld euid=%ld suid=%ld\n", (long)ruid, (long)euid, (long)suid);

  pid = vfork();
  if (pid == -1) {
    perror("vfork");
    exit(EXIT_FAILURE);
  }

  if (pid == 0) {
    /* child */

    fprintf(stderr, "child pid=%ld\n", (long)getpid());

    ret = setuid(1000);
    if (ret == -1) {
      perror("setuid");
      exit(EXIT_FAILURE);
    }

    ret = getresuid(&ruid, &euid, &suid);
    if (ret == -1) {
      perror("getresuid");
      exit(EXIT_FAILURE);
    }
    fprintf(stderr, "child ruid=%ld euid=%ld suid=%ld\n", (long)ruid, (long)euid, (long)suid);

    sleep(10);
    _exit(EXIT_SUCCESS);
  }

  /* parent */
  fprintf(stderr, "parent\n");

  pid2 = waitpid(pid, &status, WUNTRACED|WCONTINUED);
  if (pid2 == -1) {
    perror("waitpid");
    exit(EXIT_FAILURE);
  }
  if (WIFEXITED(status))
    fprintf(stderr, "pid %ld exit %ld\n", (long)pid2, WEXITSTATUS(status));
  else if (WIFSIGNALED(status))
    fprintf(stderr, "pid %ld signal %ld\n", (long)pid2, WTERMSIG(status));
  else
    fprintf(stderr, "pid %ld unexpected %ld\n", (long)pid2, (long)status);

  return EXIT_SUCCESS;
}
% gcc t.c
% sudo ./a.out
parent pid=8623
parent ruid=0 euid=0 suid=0
child pid=8624
child ruid=1000 euid=1000 suid=1000

で、他の端末から gdb で attach してみる。

(gdb) attach 8624
Attaching to program: /tmp/a/a.out, process 8624
ptrace: Operation not permitted.

お、カーネルが禁止してくれているようだ。

ptrace のマニュアルの EPERM の項に書いてある該当しそうな条件は set-user-ID/set-group-ID programs というところかなぁ。ruid=euid=suid にしてあるので、これら3つ以外になにか記録してあるのだろうか。

kill でシグナルを送ることはできる。

また、vfork でなく、fork でも同じ挙動になる。まぁ、メモリを覗かれるだけでも危ないか。

2014-09-10 (Wed)

#1

vfork したとき、親プロセスの他のスレッド (vfork を呼び出した以外のスレッド) は止まるのだろうか。(あと、そもそもメモリは共有されるだろうか)

% cat t.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <pthread.h>

static volatile char *global = "vfork doesn't share memory.";

void printn(int prefix, int n)
{
  char buf[4];
  buf[0] = prefix;
  buf[1] = '0' + n;
  buf[2] = '\n';
  buf[3] = '\0';

  write(1, buf, sizeof(buf));
}

void *thread_func(void *arg)
{
  int i;
  for (i = 0; i < 6; i++) {
    printn('t', i);
    sleep(1);
  }
  return NULL;
}

int main(int argc, char *argv[])
{
  int ret;
  pthread_t th;
  pid_t pid;
  int status;
  int j;

  ret = pthread_create(&th, NULL, thread_func, NULL);
  if (ret != 0) { errno = ret; perror("pthread_create"); exit(EXIT_FAILURE); }

  pid = vfork();
  if (pid == -1) { perror("vfork"); exit(EXIT_FAILURE); }

  if (pid == 0) {
    /* child */
    int i;
    global = "vfork share memory.";
    for (i = 0; i < 3; i++) {
      sleep(1);
      printn('c', i);
    }

    _exit(0);
  }

  for (j = 0; j < 3; j++) {
    printn('p', j);
    sleep(1);
  }

  pid = wait(&status);
  if (pid == -1) { perror("wait"); exit(EXIT_FAILURE); }

  ret = pthread_join(th, NULL);
  if (ret != 0) { errno = ret; perror("pthread_join"); exit(EXIT_FAILURE); }

  printf("%s\n", global);

  return EXIT_SUCCESS;
}
% gcc -Wall t.c -lpthread
% ./a.out
t0
c0
t1
t2
c1
t3
c2
p0
t4
p1
t5
p2
vfork share memory.
% uname -srvm
Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64

子プロセスで書き換えたグローバル変数が親プロセスに反映されているので親プロセスと子プロセスでメモリは共有されている。共有しているので親プロセスの vfork を呼び出したスレッド p[0-2] と子プロセス c[0-2] は当然同時には実行されなくて、子プロセスが終わった後に親プロセスが動いている。親プロセスで動いている他のスレッド t[0-5] は vfork 中にも動いている。

この調子でいくつか調べてみた。

メモリを共有し、親プロセスの他のスレッドが動作しつづける:

• Linux 3.14
• FreeBSD 10.0
• NetBSD 6.1.3
• PureDarwin (Darwin 9.8.0)

メモリを共有し、親プロセス全体が停止する:

• OpenIndiana 151a7 (SunOS 5.11)

メモリを共有せず、親プロセス全体が停止する:

• OpenBSD 5.5

メモリを共有せず、親プロセスは動作し続ける (fork 相当の動作):

• DragonFly BSD 3.6.2
• Debian GNU/kFreeBSD 7.0 (wheezy)
• GNU/Hurd 0.3
• Haiku alpha4
• AIX 7.1

#2

しかし、いろいろ考えると、やはり方向としては vfork より posix_spawn のほうがいいなぁ、と思う。自分で vfork を使うと、子プロセスでのメモリの書き変えをスタックだけに完璧に制限できるかどうか確信が持てない。確信を持てないから危ない感じの場合 (私の判断としては setuid 可能な場合) は使わないようになっちゃうし。

2014-09-19 (Fri)

#1

本日のまつもとさんの発表 (基調講演) をネタになるせさんと議論した結果、非常に簡単化した静的解析なら簡単に実装できることがわかったので実装してみた。

% cat static-check.rb
class C
  def m
    xxxx
  end
end

def_methods = {}
call_methods = {}
ObjectSpace.each_object {|o|
  methods = []
  methods.concat o.instance_methods.map {|msym| o.instance_method(msym) } if Module === o
  methods.concat o.methods.map {|msym| o.method(msym) }

  methods.each {|m|
    def_methods[m.name] = true
    asm = RubyVM::InstructionSequence.disasm(m)
    next if !asm
    asm.scan(/mid:([a-zA-Z0-9]+)/) {
      call_methods[$1] = true
    }
  }
}

a = call_methods.keys - def_methods.keys
if !a.empty?
  p a.sort
end
% ruby --disable-gems static-check.rb
["synchronize", "xxxx"]

これにより、定義されていないけれど呼び出しが存在する、xxxx というメソッドを発見できている。いままでは実行が xxxx というメソッド呼び出しに到達しないかぎりこのようなものを発見することはできなかったのだが、ここではそこを実行せずに発見している。

話は簡単で、すべてのメソッド定義のメソッド名をリストアップし、すべてのメソッド呼び出しのメソッド名をリストアップし、後者だけに存在するメソッド名を表示しているだけである。(実装が不完全であるのはわかっているので気にしていない)

飲み会の中で実装したのだが、ちょうどそこにいたまつもとさんやささださんなどに見せていろいろな話が出た。

単純な typo の発見ならこれでもかなり効くだろうとか、定期的に実行して名前の増減を監視すればどうかとか。いつやるかが問題だけど、Rails みたいなのはリクエストを受付始める前でやればいいとか、require の終わりでやればいいとか。あと、InstructionSequence#to_a が使えるだろうとか。

2014-09-29 (Mon)

#1

shellshock で有名になった、シェル関数を子孫のプロセスに export するという bash の機能は、どうも ksh88 に由来するような気がする。

ksh88 のマニュアル には typeset で、-f (関数) と -x (export) を組み合わせられると記述されている。

ksh88 はあまり生き残っていないのだが、AIX 7.1 にまだあったので試してみた。試行錯誤の結果、以下のようにすると動くことが確認できた。

-bash-4.2$ ksh
$ echo bar > bin/foo       # foo という名前のファイルで shell procedure を作る。中身は bar を呼び出す
$ chmod 755 bin/foo        # shell procedure は実行可能でないといけないので実行可能にする
$ which foo                # which で foo が見つかる
/home/akr/bin/foo
$ foo                      # ここで foo を呼び出すと bar が見つからないというエラー
foo: bar:  not found                                                                                  .
$ bar () { echo baz; }     # bar を関数として定義する
$ foo                      # ここで foo を呼び出しても bar は見つからない
foo: bar:  not found                                                                                  .
$ typeset -fx bar          # bar を export するように設定する
$ foo                      # foo を呼び出すと bar が呼び出される
baz
$

試してわかったのだが、これは bash のように環境変数を介する機能ではないようだ。例えば、ksh -c bar としたり、foo の先頭に #!/bin/ksh をつけると bar の定義は伝わらない。

truss すると以下のようになる。

-bash-4.2$ truss -f ksh -c 'bar () { echo baz; }; typeset -fx bar; foo'
...
12124234: 51511337: execve("/home/akr/bin/foo", 0x200119B8, 0x20011EB8) Err#8  ENOEXEC
12124234: 51511337: kopen("/home/akr/bin/foo", O_RDONLY)        = 3
...
baz
12124234: 51511337: kwrite(1, " b a z\n", 4)            = 4
...

つまり、ksh は foo を execve しようとして失敗し、しょうがないので foo を自分で読んで処理して (bar を呼んで) baz を出力する、という流れである。

execve してないので呼び出し元の情報が利用可能で、typeset により export とマークされている bar を見つけて使うのであろう。

というわけで、もし ksh88 が使われていても、(環境変数は関係ないので) shellshock のような話にはならないだろう。

ちなみに、ksh93 では動かない。(ksh93 のマニュアルでも、typeset で -f と -x を組み合わせた時の動作の記述は消えている。)

-bash-4.2$ ksh93 -c 'bar () { echo baz; }; typeset -fx bar; foo'
foo: line 1: bar: not found

なお、pdksh のマニュアル には typeset -fx は効果がないことが書いてある。

[latest]