FiberとPHPの型システム：Zend VMコンテキストスイッチにおける型安全性の極限防御
PHP 8.1で導入されたFiber（ファイバー）は、共有何も持たない（Shared-Nothing）アーキテクチャを基本としてきたPHPの実行モデルに、軽量な協的中断・再開（Cooperative Multitasking）をもたらした。
しかし、Node.jsのAsync/AwaitやGoのGoroutineに慣り親しんだエンジニアが陥りがちな罠がある。それは、「Fiberのコンテキストスイッチが、Zend VMのスタックフレームと型システムの境界を曖昧にする」という事実だ。
本稿では、Fiber実行コンテキストにおける型安全性の保証が、Zend VMの内部挙動、オペコード（Opcode）、そしてメモリ空間において何を意味するのか。プロセスの生存期間、OPcacheプリローディング、そしてオブジェクトインジェクションのコンテキストにおける脆弱性メカニズムまで踏み込み、極限の知見を紐解く。
—
1. Zend VMのスタックフレームとFiberの物理構造
伝統的なPHPの実行モデルでは、1つのリクエスト（FPMプロセス）は1つのコールスタック（`zend_execute_data`の連結リスト）を持つ。関数が呼び出されるたびにスタックフレームが積まれ、リターン時に破棄される。
しかし、Fiberを導入すると、ひとつのスレッド（FPMプロセス）上に複数の仮想コールスタックが並存することになる。
[FPMプロセス / OSスレッド]
├── Main Execution Context (zend_execute_data)
└── Fiber Context (Isolated zend_execute_data & Stack)
├── Fiber::suspend() で退避
└── Fiber::resume() で復帰
コンテキストスイッチの内部挙動
`Fiber::suspend()`がコールされた瞬間、Zend VMは現在の`EG(current_execute_data)`をヒープ上に退避させ、Fiberオブジェクトが保持する別の実行コンテキストへとポインタを切り替える。
このとき、C言語レベル（Zend Engine）では、実行中のローカル変数やテンポラリ変数がそのままシリアライズされるわけではない。あくまで「どこまで実行したか（IP: Instruction Pointer）」と「スタックのポインタ」がスイッチされるだけだ。
ここで問題になるのが、「中断から復帰した際（`resume`時）、渡される引数や戻り値の型が、Fiber内部の型定義と一致しているか」という点である。
—
2. Fiber引数・戻り値における型ヒントの厳格性
PHPの型システムは、基本的に静的チェックと動的強制（Strict Types / Coercion）のハイブリッドで成り立っている。しかし、Fiberの境界を越えるデータ授受は、通常の関数呼び出しとは異なるメモリ・ライフサイクルを持つ。
以下のコードを見てほしい。
start(21); // int 21 -> 42 を返す
echo “Suspended with: {$initialValue}\n”;
// 2. Fiberへ値を戻す（resume経由の型混入リスク）
// ここで不正な型（例: array や object）を渡した場合の挙動を制御する必要がある
try {
$result = $fiber->resume(“payload_string”);
echo “Fiber finished with: {$result}\n”;
} catch (TypeError $e) {
echo “Type safety violation caught: ” . $e->getMessage() . “\n”;
}
}
}
(new SecureFiberRunner())->execute();
なぜFiber内部での明示的な型チェックが必要なのか？
`$fiber->resume($mixedValue)` の引数は、PHPの言語仕様上 `mixed` である。つまり、Zend VMのレイヤでは、`resume()` に渡す値の型制約が、Fiberのコンストラクタで定義されたクロージャのシグネチャと自動的に静的結合されないケースが存在する。
もし `resume()` に予期せぬオブジェクト（後述のガジェットチェインを形成しうるインスタンス）が渡された場合、Fiberが再開した瞬間にメモリ上の意図しないプロパティアクセスが発生し、脆弱性の踏み台になり得る。
—
3. OPcacheプリローディングとFiberクラスの静的解析
プロダクション環境において、パフォーマンスの限界を追求するならばOPcacheのプリローディング（`opcache.preload`）は必須だ。しかし、Fiberと型システムを組み合わせる際、プリローディングは「両刃の剣」となる。
プリロードされたクラスとFiberのメモリ空間
OPcacheによって共有メモリ（SHM）上にプリロードされたクラス定義は、FPMの子プロセス間で共有される。Fiber内部で使用されるDTO（Data Transfer Object）やサービスコンテナがプリロードされている場合、Zend Engineはそれらのクラスの型情報（`zend_class_entry`）を永続的な共有メモリ上に固定する。
; php.ini の極限チューニング例
opcache.enable=1
opcache.preload=/var/www/html/config/preload.php
opcache.preload_user=www-data
ここで、Fiberのコンテキスト内で動的に生成される無名クラスや、型安全性をバイパスするリフレクションを用いたプロパティ書き換えを行っている場合、プリロードされた親クラスの型制約と競合を起こす。
最高峰の知見として覚えておくべきは、「Fiber内で処理されるDTOやイベントペイロードは、すべて `readonly` かつ厳格なスカラー型、あるいはイミュータブルな構造体でなければならない」という点だ。共有メモリ上に存在する型定義に対して、Fiberの非同期コンテキストから可変（Mutable）なオブジェクトが持ち込まれると、並行処理特有の競合状態（Race Condition様の挙動、PHPの場合はシングルスレッドであっても非同期イテレーション時の状態汚染）を引き起こす。
—
4. オブジェクトインジェクションとFiberガジェットチェインの脅威
セキュリティハックの文脈において、Fiberの導入は新たな攻撃サーフェスを生む可能性がある。
攻撃者がシリアライズされたデータ（例：不安全な `unserialize()`）をアプリケーションにインジェクトし、オブジェクトインジェクションを成功させたとする。
従来、攻撃者は `__destruct()` や `__toString()` などのマジックメソッドを連鎖させ（Gadget Chain）、既存のクラスのメソッドを意図しない順序で実行させてRCE（遠隔コード実行）に至っていた。
ここに Fiberと型システムの隙間 が加わるとどうなるか。
悪意あるFiberの構築とコンテキストの乗っ取り
もしアプリケーション側が、ユーザー入力を検証せずにそのまま `Fiber::resume()` の引数として渡していたり、Fiberのクロージャ内で動的にインスタンス化されるオブジェクトの型ヒントを怠っていたりする場合、以下のような脅威が成立する。
command);
}
}
class FiberContextExploit
{
private Fiber $fiber;
public function __construct()
{
$this->fiber = new Fiber(function (object $injectable) {
// 型ヒントに object を指定している場合、任意のオブジェクトを受け入れてしまう
// ここでマジックメソッドを持つ悪意あるオブジェクトが渡されると危険
$injectable->executeUnsafeOperation();
});
}
public function trigger(mixed $payload): void
{
$this->fiber->start($payload);
}
}
防御策：型システムの厳格化によるガジェットの無効化
この攻撃を防ぐ唯一にして最大の防御壁は、Fiberの境界における厳格な型指定（Strict Typing）と、インターフェースによる型のホワイトリスト化である。
validate()) {
throw new \SecurityException(“Payload validation failed.”);
}
// 安全な非同期処理の継続…
});
$fiber->start($payload);
}
}
Zend VMは、関数やクロージャの引数にインターフェースや具象クラスの型ヒントが指定されている場合、オペコードの実行前段階（`ZEND_RECV_INIT` や型アサーションのオペコード）で厳密なクラスツリーのチェックを行う。このハードウェア/エンジンレベルの検証こそが、オブジェクトインジェクションの連鎖を断ち切る最強の盾となる。
—
5. 結び：極限のパフォーマンスと堅牢性の両立
FiberはPHPを単なる「リクエスト単位のスクリプト言語」から、高スループットな非同期アプリケーションプラットフォームへと引き上げる起爆剤だ。しかし、その裏側にあるZend VMのメモリ管理、コンテキストスイッチの物理的挙動、そして型システムの厳格な境界線を理解していなければ、システムは一瞬にして脆弱性の温床となる。
妥協のないアーキテクトよ、Fiberを使うときは常に意識せよ。
「その `resume` の値は、本当に信頼できる型で守られているか？」
エンジンを支配する者だけが、真の高速性と堅牢性を手に入れることができる。