Kernel · レッスン 3

システムコール

ユーザー空間コードが Linux カーネルサービスを呼び出し、`strace` で安全に call を調べる方法を学びます。

system call はカーネルへの定義済み entry で、user-space code は file の open、memory の map、process の作成、network data の送信などを要求します。カーネルは処理前に argument、credential、object state、security policy を検証します。

Library と System-Call ABI

application は architecture 固有の entry instruction を直接書かず、通常は C library function を呼びます。library wrapper は system-call ABI に従って register と memory を準備し、カーネルへ入り、結果を language-level の規約へ変換します。

function と syscall は、常に一対一ではありません。

一つの library function が複数の system call を組み合わせる場合がある
完全にユーザー空間で動く function もある
最適化された vDSO function は、完全な mode transition なしに一部の kernel-maintained data を得られる
一つの system call が多数の高水準 API を支える場合がある

一般的な libc の system-call wrapper は何をしますか？

カーネルへの Entry と Return

wrapper は system-call number と argument を architecture 定義の場所へ置き、x86-64 の syscall や AArch64 の svc などの entry instruction を実行します。processor は設定済み privileged entry point へ切り替わり、カーネルが要求を dispatch します。

完了後、カーネルは値または error indication を返します。C library wrapper は error 時に通常 -1 を返し、thread-local の errno を設定します。ほかの language と runtime は異なる error type を公開します。

現在の architecture で全 entry を「software interrupt」と呼ぶのは不正確です。trap、fast system-call instruction、supervisor call は関連する管理済み遷移を別の方法で実装します。

system call の argument と authorization を検証するのは誰ですか？

番号と互換性

system-call number と calling convention は architecture 固有です。同じ symbolic call でも、別の ABI では番号や structure layout が異なる場合があります。kernel release は system call を追加できますが、安定した user-space ABI は既存動作を維持することを目指します。

非特権 process は、動作中カーネルの syscall table へ任意の新規 handler を挿入できません。interface の拡張には kernel code と慎重な ABI design が必要です。seccomp などの機能は process が使える call を filter できますが、新しい kernel implementation は作りません。

別 architecture の syscall number を application が hard-code すべきでないのはなぜですか？

`strace` で Trace する

単純な command を trace し、出力を別ファイルへ保存します。

$ strace -o trace.log -- ls

許可された範囲で child process を追うには -f、出力を絞るには次のような expression を使います。

$ strace -f -e trace=%file -o trace.log -- command

strace は path、argument、environment 由来データ、network address、file content の断片、argument を通じて誤って渡した credential を露出する場合があります。trace は厳しい権限で保存し、incident-data policy に従って削除してください。

strace が主に観測するものは何ですか？

Trace を慎重に解釈する

tracing は timing を変え、大きな overhead を生む場合があります。失敗 call が想定済みの probe であることや、最後に見える error が以前の operation または application policy から生じることもあります。file descriptor を解読し、process 関係を追い、application log と相関させます。

permission と ptrace security policy は trace 可能な process を制限します。許可なく別ユーザーや production process へ attach してはいけません。suspension と timing change が service behavior へ影響する可能性があります。

trace 内で一つの syscall が失敗したら、必ず application が壊れているという意味ですか？