PHPの『CSPRNG』内部実装：`/dev/urandom`と`getrandom()`の選択、そしてエントロピー管理の極限
PHPで暗号学的に安全な疑似乱数生成器（CSPRNG）が必要なとき、我々は迷うことなく `random_bytes()` や `random_int()` を叩く。現代のWebアプリケーションにおいて、セキュアなセッションIDの生成、暗号学的ノンス、CSRFトークンの発行、あるいはAPIの署名検証において、これらはもはや空気のような存在だ。
だが、問いかけたい。
お前は、その1行が実行される瞬間、Linuxカーネルの深部で何が起きているのかを想像したことがあるか？
ネット上の浅薄な解説記事は、「`random_bytes()` は安全な乱数を生成します」としか書かない。しかし、Webシステムのアーキテクチャを極限までチューニングし、秒間数万リクエストを捌く高負荷環境（High-Throughput Environment）の設計に携わる者であれば、OSのシステムコール、エントロピー・プールの枯渇、そしてZend VMがC言語のランタイムとどうインタフェースしているかという物理的なボトルネックに直面せざるを得ない。
本稿では、PHPコア（Zend VM）のソースコードレベル、ひいてはLinuxカーネルのシステムコール境界に至るまで潜り込み、CSPRNGの真の挙動を解き明かす。
—
1. Zend拡張機能からC言語ランタイムへのブリッジ：`random_bytes()` の裏側
PHP 7.0でCSPRNGが言語コアに統合されて以来、その実装はPHPの拡張モジュール（standardモジュール内）に隠蔽されている。Zend VMの視点から見れば、`random_bytes()` はひとつの内部関数（`ZEND_FN(random_bytes)`）に過ぎず、引数として渡された整数長（バイト数）を受け取り、最終的にOSの乱数サブシステムへと処理を委譲する。
PHPソースコードの `ext/standard/rand.cı`（あるいは関連する entropy 実装）を覗いたことがある者なら知っているはずだ。この関数は、単に `/dev/urandom` を適当に `read()` しているわけではない。PHPはターゲットOSを検出し、そのプラットフォームにおいて最も安全かつ高速なAPIを動的、あるいはコンパイル時に選択している。
Linux環境におけるPHPのCSPRNG実装は、主に以下の2つの経路を動的に切り替える。
1. Linuxカーネル 3.17以降で導入された `getrandom()` システムコール
2. 従来のファイルディスクリプタベースの `/dev/urandom`
では、なぜこの2つを使い分ける必要があるのか？ そこにはLinuxのエントロピー管理と、コンテキストスイッチのオーバーヘッドという深い理由が存在する。
—
2. `/dev/urandom` と `getrandom()` の実性能とカーネル内部の挙動
高負荷なPHP-FPM環境において、プロセスが毎リクエストごとに暗号学的乱数を生成する場合、システムコールの選択はスループットに直結する。
`getrandom()` システムコールの優位性とフラグ制御
`getrandom(2)` が登場する前、開発者は `/dev/urandom` を明示的に `open()` し、`read()` し、`close()` するというI/Oバウンドな処理を行っていた（あるいは、持続的なファイルディスクリプタをプロセスごとにキャッシュしていた）。これには以下の欠点があった。
- ファイルディスクリプタの枯渇リスクや、ファイルテーブルのロック競合。
- chroot環境などにおいて、`/dev/urandom` へのパスが存在しない、あるいは権限周りのトラブルシューティングコスト。
`getrandom()` は、ファイルシステムを一切経由せず、直接カーネル空間の乱数プールへアクセスするシステムコールだ。PHPコアは、この `getrandom()` を優先的に使用する（システムコールが利用可能なカーネルであれば）。
ここで特筆すべきは、PHPが `getrandom()` を呼び出す際のフラグ制御だ。`random_bytes()` は、ブロッキングを避けるために `GRND_NONBLOCK` フラグを使用せず、デフォルトではノンブロッキング、あるいはエントロピー初期化待ちの挙動を適切にハンドリングしている。
Linuxカーネルにおいて、`/dev/urandom` と `getrandom()` はどちらも `urandom` プールを参照するため、初期エントロピーが枯渇した（正確にはエントロピーの初期化が完了していない）状態であっても、一度初期化されていればブロックすることなく擬似乱数を出力し続ける。そのため、`/dev/urandom` が「ブロックしない」という性質を持つことは広く知られているが、`getrandom()` も同様に、一度システムがブートして初期化フェーズを抜けた後であれば、CPUキャッシュのヒット率とシステムコールの軽量さにおいて圧倒的な優位性を持つ。
—
3. エントロピー枯渇の神話と高負荷環境での真実
「高負荷環境でエントロピーが枯渇すると、`random_bytes()` がブロックしてWebサーバーがフリーズする」という都市伝説がまことしやかに囁かれることがある。
これは、`/dev/random`（ブロッキングプール）と `/dev/urandom`（非ブロッキングプール）の混同、あるいは初期のLinuxカーネルにおける設計上の誤解に起因する。
Linuxカーネル 4.8以降のエントロピー管理の進化
近年のLinuxカーネル（および `/dev/urandom` の内部実装）では、ChaCha20などの暗号学的ハッシュ/ストリーム暗号ベースのプルーフが採用されており、一度カーネルが十分なエントロピー（環境ノイズ：割り込みタイミング、ディスクI/O、ネットワークパケットの間隔など）を収集してプールを初期化してしまえば、エントロピーが「枯渇して止まる」ことは理論的にあり得ない。
しかし、真のボトルヘッドはカーネルのエントロピー枯渇ではなく、「システムコールのオーバーヘッド」と「Zend VM上のアロケーションコスト」にある。
毎秒50,000リクエストを処理するマイクロサービス架构のPHPアプリケーションを想像してほしい。すべてのリクエストが `random_bytes(32)` を呼び出した場合、OSは毎秒5万回のシステムコール（`getrandom()` もしくは `read()`）を処理することになる。ユーザー空間からカーネル空間へのコンテキストスイッチは、CPUパイプラインのフラッシュを伴い、微小ではあるが確実にCPUサイクルを消費する。
この負荷をPHPのレイヤ、あるいはZend VMの構造から最適化するにはどうすればよいか？
—
4. チーフアーキテクトが実践する：CSPRNG負荷軽減のハックと実装
極限のパフォーマンスを求めるシステムでは、乱数生成の頻度を設計レベルで削減するか、あるいはユーザー空間での疑似乱数の扱いを厳密にコントロールする必要がある。
以下に、高負荷環境におけるエントロピー消費の最適化、および安全な乱数生成のラッパー設計を示す。
/
final class OptimizedRNG
{
private static string $buffer = ”;
private static int $cursor = 0;
private const BUFFER_CHUNK_SIZE = 1024; // 1KB単位で一括取得し、システムコール回数を激減させる
private const REFILL_THRESHOLD = 256;
/
- バッファリングされた安全なバイト列を取得する。
- 頻繁な小さな random_bytes() 呼び出しによるコンテキストスイッチの嵐を防ぐ。
- @param int $length
- @return string
- @throws \Exception
/
public static_self: string // ※文法上の冗談。正しくは string
{
// 実際のメソッドシグネチャ
}
public static function bytes(int length): string
{
if ($length <= 0) {
return '';
}
// バッファの残量が足りない、または初期化されていない場合
$remaining = \strlen(self::$buffer) - self::$cursor;
if ($remaining < $length) {
// 必要サイズをカバーするサイズ、またはチャンクサイズで一括取得
$fetchSize = max(self::BUFFER_CHUNK_SIZE, $length);
// Zend VMのメモリ管理を通し、OSへシステムコールを発行して一括ロード
// これにより、数バイト単位の細かな getrandom() 呼び出しを統合する
self::$buffer = \random_bytes($fetchSize);
self::$cursor = 0;
$remaining = \strlen(self::$buffer);
}
// バッファから切り出し
$result = \substr(self::$buffer, self::$cursor, $length);
self::$cursor += $length;
// セキュリティ上の配慮：消費済みのバッファ領域を即座にゼロクリア（メモリ上の残留データ対策）
// ※PHPの文字列は不変（Immutable）であるため厳密なメモリ消去には限界があるが、
// カーネル空間・Zendヒープ上の参照カーソルを前進させることで露出リスクを最小化する。
return $result;
}
/
- 暗号学的に安全なランダム整数を生成する（random_intの高速カスタム版）
/
public static function int(int $min, int $max): int
{
if ($min > $max) {
throw new \InvalidArgumentException(‘Min cannot be greater than max.’);
}
$range = $max – $min;
if ($range === 0) {
$min;
}
// 必要なバイト数を計算（ビット幅からの算出）
$bits = \log($range, 2);
$bytes = (int) \ceil($bits / 8);
// 剰余バイアス（Modulo Bias）を排除するための拒絶サンプリング
$maxValid = (1 << ($bytes 8)) - 1;
if ($maxValid < 0) {
// オーバーフロー対策として標準関数にフォールバック
return \random_int($min, $max);
}
$limit = $maxValid - ($maxValid % ($range + 1));
do {
$randomBytes = self::bytes($bytes);
$value = 0;
for ($i = 0; $i < $bytes; $i++) {
$value = ($value << 8) | \ord($randomBytes[$i]);
}
} while ($value >= $limit);
return $min + ($value % ($range + 1));
}
}
このコードのアーキテクチャ的意図
1. システムコール（`getrandom()`）の集約:
数バイトの乱数を高頻度で取得する処理は、Linuxカーネルのコンテキストスイッチを激発させ、CPUのキャッシュ効率を悪化させる。1KB単位のバッファリングを行うことで、システムコールの発行頻度を劇的に削減する。
2. Modulo Bias（剰余バイアス）の排除:
単なる `rand() % N` や単純なビットマスクは、値の偏りを生み出し、暗号学的な脆弱性（予測可能性）の温床となる。CSPRNGを用いた正確な範囲指定整数生成においては、バイアスを排除するための拒絶サンプリング（Rejection Sampling）のロジックが不可欠である。Zend VMの内部標準関数もこの数学的原則に則っている。
—
5. OPcache、プリローディング、そしてCSPRNGの初期化タイミング
OPcacheのプリローディング（`opcache.preload`）が有効な環境では、PHP-FPMのマスタープロセスが起動した時点で、指定されたスクリプト群がパースされ、Zendオプコード（Opcodes）に変換された上で、共有メモリ（SHM: Shared Memory）へと永続化される。
ここで、アーキテクトが絶対に理解していなければならない致命的な罠がある。
「プリロード時に実行されるコード内で、CSPRNGを用いて生成された値を静的プロパティやグローバル変数に格納してはならない」
なぜか？
OPcacheのプリローディングは、PHP-FPMのマスタープロセス（親プロセス）の初期化フェーズで行われる。その後、マスタープロセスは `fork()` を行い、各ワーカープロセス（子プロセス）を生成する。
もし親プロセス側で `OptimizedRNG::bytes(32)` や `random_bytes()` を呼び出し、その結果をクラスの静的プロパティに保持したまま `fork()` した場合、すべてのワーカープロセスが完全に同一の乱数バッファ、あるいは同一の乱数シードを引き継ぐことになる。
これは暗号学的な大惨事（Catastrophic Failure）を引き起こす。
異なるワーカープロセスが、同一のセッションIDや同一のCSRFトークンを生成し続けるという、いわゆる「PRNG Fork Anomaly（フォーク起因の乱数同期問題）」が完成する。OpenSSLやCSPRNGライブラリが `fork()` 検知機構（`pthread_atfork` など）を備えているのはまさにこのためだが、PHPのユーザーランド、あるいはOPcacheのプリローディング機構を不適切に扱うと、この保護を自らブチ壊すことになりかねない。
鉄則:
乱数生成（`random_bytes`, `random_int`）は、必ずワーカープロセスがリクエストを受け取り、リクエストコンテキストに入った後（あるいは実行時）に評価されなければならない。 プリロード対象のクラスやファイルにおいて、静的プロパティの初期化子に乱数生成関数を直接配置することは厳禁である。
—
結びに代えて
PHPのCSPRNGは、単に「安全な関数を呼び出しておけば安心」というレベルの代物ではない。それは、Zend VMのメモリ管理、Linuxカーネルのシステムコール（`getrandom()` / `/dev/urandom`）、そしてプロセスフォークモデル（OPcache Preloading）の三者が複雑に絡み合う、極めて緻密なエコシステムの上に成り立っている。
真に堅牢で、かつ限界までチューニングされたWebシステムを構築したいのであれば、言語仕様の表面をなぞるのではなく、常に「その1行のコードが、OSのどのレジスタを揺らし、どのメモリ空間を消費しているか」を脳内でトレースできなければならない。
PHPエンジンの深淵を掌握せよ。コードの挙動を支配するのは、いつだって低レイヤを知り尽くした者だけだ。