天泣記

2014-09-10 (Wed)

#2

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

#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 中にも動いている。

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

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

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

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

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

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-07 (Sun)

#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'

fork-vfork-posixspawn.png

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

#2

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

#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'

fork-vfork2.png

2014-09-06 (Sat)

#4

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

#3

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

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

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

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

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

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

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

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

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

#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}"
}'

で、プロットしてみた。

fork-vfork.png

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

#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 のほうが明確に速くなるだろう。

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

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-08-26 (Tue)

#1

ふと、select の errorfds がなんに使われているのか、BSD のソースを追いかけてみた

わかったこと:

前にも調べたことがあったような、と思ったら、5年前で、そのときはソースは読まなかったようだ

2014-07-30 (Wed)

#1

Ruby のリリースブランチでテストの失敗がどう変わっているかプロットしてみた。

ruby-stable-tests.R:

library(ggplot2)
d <- read.csv("2014-07/ruby-stable-tests.csv")
d$date <- as.POSIXct(d$time, format="%Y%m%dT%H%M%S")
p <- qplot(date, failures, data=d, color=ruby, position="jitter") + stat_smooth(method=lm)
print(p)

ruby-stable-tests.png

リリースされてからだんだん壊れていく (直らない失敗が増えていく) という印象があったのだが、しばらく失敗していたものが直ることもあるようだな。



田中哲