Putting the You in CPU

ステップ0: 定義を見る

システムコールの仕組み自体はもう知っていますが、実際のコードをまだ見ていません。Linuxカーネルのソースを見て、execve が内部でどう定義されているのか確認してみましょう。

SYSCALL_DEFINE3(execve,
		const char __user *, filename,
		const char __user *const __user *, argv,
		const char __user *const __user *, envp)
{
	return do_execve(getname(filename), argv, envp);
}

SYSCALL_DEFINE3 は、引数3個のシステムコールを定義するためのマクロです。

どうしてマクロ名に引数個数が埋め込まれているのか気になって調べてみたところ、これはある種のセキュリティ脆弱性への対処として入った仕組みだとわかりました。

filename 引数は getname() 関数へ渡されます。これはユーザー空間の文字列をカーネル空間へコピーし、いくつかの利用追跡も行います。戻り値は filename 構造体で、これは include/linux/fs.h で定義されています。そこには、元のユーザー空間文字列へのポインタと、カーネル空間へコピーされた値への新しいポインタの両方が入っています。

struct filename {
	const char		*name;	/* pointer to actual string */
	const __user char	*uptr;	/* original userland pointer */
	int			refcnt;
	struct audit_names	*aname;
	const char		iname[];
};

execve システムコールはその後 do_execve() を呼びます。そして do_execve() は、いくつか既定値を与えて do_execveat_common() を呼びます。先ほど触れた execveat も同じ do_execveat_common() を呼びますが、こちらはユーザー指定のオプションをもっと多くそのまま渡します。

以下の抜粋では、do_execve と do_execveat の両方を載せています。

static int do_execve(struct filename *filename,
	const char __user *const __user *__argv,
	const char __user *const __user *__envp)
{
	struct user_arg_ptr argv = { .ptr.native = __argv };
	struct user_arg_ptr envp = { .ptr.native = __envp };
	return do_execveat_common(AT_FDCWD, filename, argv, envp, 0);
}

static int do_execveat(int fd, struct filename *filename,
		const char __user *const __user *__argv,
		const char __user *const __user *__envp,
		int flags)
{
	struct user_arg_ptr argv = { .ptr.native = __argv };
	struct user_arg_ptr envp = { .ptr.native = __envp };

	return do_execveat_common(fd, filename, argv, envp, flags);
}

[spacing sic]

execveat では、ファイルディスクリプタ（何らかの資源 を指すIDの一種）がシステムコール経由で do_execveat_common へ渡されます。これは、そのプログラムをどのディレクトリ基準で実行するかを指定します。

execve のほうでは、ファイルディスクリプタ引数に特別な値 AT_FDCWD が使われます。これはLinuxカーネル内で共有されている定数で、パス名をカレントディレクトリ基準で解釈せよ、という意味です。ファイルディスクリプタを受け取る関数には、たいてい if (fd == AT_FDCWD) { /* special codepath */ } のような分岐が入っています。

ステップ1: 準備

ここで、プログラム実行の中核を担う do_execveat_common にたどり着きました。少しコードから目を離して、この関数が全体として何をしているのかを見てみましょう。

do_execveat_common の最初の大仕事は、linux_binprm という構造体を組み立てることです。構造体定義全体は長いのでここには載せませんが、重要なフィールドはいくつかあります。

• mm_struct や vm_area_struct のようなデータ構造が用意され、新しいプログラム用の仮想メモリ管理を準備します。
• argc と envc が計算され、プログラムへ渡すために保存されます。
• filename と interp には、それぞれプログラム本体のファイル名と、そのインタプリタのファイル名が入ります。最初は同じ値ですが、場合によって変わります。代表例が shebang 付きのスクリプトです。たとえばPythonプログラムを実行する場合、filename はソースファイルを指し、interp はPythonインタプリタのパスを指します。
• buf は、実行対象ファイルの先頭256バイトを格納する配列です。ファイル形式の判定や、スクリプトのshebang読み取りに使われます。

（ちなみに binprm は binary program の略です。）

この buf をもう少し詳しく見てみましょう。

	char buf[BINPRM_BUF_SIZE];

As we can see, its length is defined as the constant BINPRM_BUF_SIZE. By searching the codebase for this string, we can find a definition for this in include/uapi/linux/binfmts.h:

/* sizeof(linux_binprm->buf) */
#define BINPRM_BUF_SIZE 256

つまり、カーネルは実行対象ファイルの先頭256バイトをこのメモリバッファへ読み込みます。

余談: UAPIって何？

上のコードのパスに /uapi/ が含まれていることに気づいたかもしれません。なぜ長さの定義が、linux_binprm 構造体のある include/linux/binfmts.h と同じファイルにないのでしょうか。

UAPI は "userspace API" の略です。この場合は、誰かが「このバッファ長はカーネルの公開APIの一部にすべきだ」と決めた、という意味です。理屈の上では、UAPIに属するものはすべてユーザーランドへ公開され、UAPIでないものはカーネル内部専用です。

カーネル空間のコードとユーザー空間向けコードは、もともとかなり雑然と同居していました。2012年に、保守性向上のためUAPIコードが別ディレクトリへ整理されました。

ステップ2: binfmt

カーネルの次の大仕事は、"binfmt"（binary format）ハンドラをひとつずつ試していくことです。これらのハンドラは fs/binfmt_elf.c や fs/binfmt_flat.c のようなファイルで定義されています。カーネルモジュールが独自のbinfmtハンドラを追加することもできます。

各ハンドラは load_binary() 関数を公開していて、linux_binprm 構造体を受け取り、そのプログラム形式を自分が理解できるかどうかを調べます。

ここではしばしば、バッファ内のマジックナンバーを見たり、同じくバッファからプログラム先頭をデコードしてみたり、拡張子を確認したりします。その形式に対応していれば、ハンドラはプログラム実行の準備をして成功コードを返します。そうでなければ早々に諦めてエラーコードを返します。

カーネルは成功するものに当たるまで、各binfmtの load_binary() を順に試します。これが再帰的に呼ばれることもあります。たとえばスクリプトにインタプリタが指定されていて、そのインタプリタ自身もまたスクリプトだった場合、binfmt_script → binfmt_script → binfmt_elf という連鎖になるかもしれません。最後にあるELFが、実際に実行されるバイナリ形式です。

形式別ハイライト: スクリプト

Linuxが対応している多くの形式の中で、最初に取り上げたいのは binfmt_script です。

shebang を見たことはありますか。スクリプトの先頭にあって、インタプリタのパスを書くあの行です。

#!/bin/bash

私は長いこと、これはシェルが処理しているのだと思っていました。でも違います。shebangは実はカーネルの機能で、スクリプトもほかのプログラムと同じシステムコールで実行されます。コンピュータ、やっぱり面白い。

fs/binfmt_script.c が、ファイルの先頭がshebangかどうかをどう判定しているか見てみましょう。

	/* Not ours to exec if we don't start with "#!". */
	if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))
		return -ENOEXEC;

ファイルが実際にshebangで始まっていれば、このbinfmtハンドラはインタプリタのパスと、その後ろに空白区切りで続く引数を読み取ります。改行に当たるか、バッファ末尾へ達したところで止まります。

ここには、面白いけれど少し変な点が2つあります。

第一に、linux_binprm の先頭256バイト入りバッファを覚えていますか。あれは実行形式の判定にも使われますが、binfmt_script ではshebangの読み取りにも同じバッファが使われます。

調べている途中で、このバッファは128バイトだと書いてある記事を読みました。ところが、その記事の公開後どこかの時点で、長さは256バイトへ倍増していました。なぜか気になって、Linuxソースの BINPRM_BUF_SIZE 定義行に対して Git blame、つまりその行を誰が編集したかの履歴を見てみると……。

コンピュータ、本当に面白い。

shebangはカーネルが処理し、しかもファイル全体ではなく buf から読むので、必ず buf の長さで切り詰められます。どうやら4年ほど前、カーネルが128文字超のパスを途中で切ってしまうことに誰かが困り、その解決策としてバッファ長を倍にして切り詰め位置も倍にしたようです。つまり今日でも、あなたのLinuxマシンでshebang行が256文字を超えていたら、その先は 完全に失われます。

これが原因でバグを踏んだ場面を想像してみてください。コードが壊れている根本原因を探して、ついに問題がLinuxカーネルの深部にあるとわかったときの気持ちを。巨大企業で、パスの一部がなぜか消えていることに気づく次のIT担当者には心から同情します。

第二の変な点 は、argv[0] がプログラム名だというのは 単なる慣習 にすぎず、呼び出し元は好きな argv をexec系システムコールへ渡せるし、それが特に検査されず通ってしまう、という話を思い出してください。

binfmt_script はまさに、argv[0] がプログラム名だと 仮定している 箇所のひとつです。このハンドラは必ず argv[0] を取り除き、そのうえで argv の先頭に次のものを追加します。

• インタプリタへのパス
• インタプリタへの引数
• スクリプトのファイル名

**例: 引数の書き換え**

具体例として、次の execve 呼び出しを見てみましょう。

// 引数: filename, argv, envp
execve("./script", [ "A", "B", "C" ], []);

この仮想的な script ファイルの先頭行には、次のshebangが書かれているとします。

#!/usr/bin/node --experimental-module

こうして最終的にNodeインタプリタへ渡される argv は、次のようになります。

[ "/usr/bin/node", "--experimental-module", "./script", "B", "C" ]

argv を更新したあと、ハンドラは linux_binprm.interp にインタプリタのパス（この場合はNodeバイナリ）を設定し、ファイルの実行準備を終えます。最後に、準備に成功したことを示す 0 を返します。

形式別ハイライト: その他のインタプリタ

もうひとつ面白いハンドラが binfmt_misc です。これは /proc/sys/fs/binfmt_misc/ に特別なファイルシステムをマウントすることで、ユーザーランドの設定から限定的に新しい形式を追加できるようにします。プログラムはこのディレクトリ内のファイルへ特定形式の書き込みを行うことで、自前のハンドラを追加できます。各設定エントリは次のことを指定します。

• そのファイル形式をどう検出するか。特定オフセットにあるマジックナンバーでも、拡張子でも指定できます。
• インタプリタ実行ファイルのパス。インタプリタ引数を直接指定する方法はないので、必要ならラッパースクリプトが必要です。
• binfmt_misc が argv をどう更新するかを含む、いくつかの設定フラグ。

この binfmt_misc はJava環境でよく使われていて、classファイルを 0xCAFEBABE のマジックバイトで検出したり、JARファイルを拡張子で検出したりするよう設定されます。私の環境では、.pyc 拡張子でPythonバイトコードを検出して適切なハンドラへ回す設定も入っていました。

高い特権が必要なカーネルコードを書かずに、インストーラ側が独自形式への対応を追加できる、かなり面白い仕組みです。