Linux 7.2-rc2、BPF JIT噴射攻撃対策を強化

Linux 7.2-rc2のリリースを目前に控え、カーネルのBPF（Berkeley Packet Filter）コードにJIT噴射（JIT spraying）攻撃の対策が施された。IntelのエンジニアPawan Guptaが開発した一連のパッチがマージウィンドウ終了後に取り込まれ、BPF JITアロケータのメモリ再利用時に間接分岐予測子のフラッシュを実行する仕組みが導入された。Phoronixの記事によれば、これらの変更は日本時間7月6日未明に公開される予定のLinux 7.2-rc2に含まれる。

なぜ今、JIT噴射対策なのか

JIT噴射攻撃は、JITコンパイラが生成した実行可能コードの領域に攻撃者が細工したコード片を設定し、間接分岐の予測を操作することで投機的実行の脆弱性を悪用する手法だ。特にSpectre-v2（CVE-2017-5715）で知られる分岐ターゲットインジェクションは、CPUの分岐予測機構を汚染することで特権昇格や情報漏洩を引き起こす。

今回のパッチ投入についてPhoronixは「マージウィンドウが閉じた後の異例のタイミング」と指摘しつつ、最近のセキュリティ発見が動機かどうかは明らかでないと報じている。しかし、驚くべきは「BPFコードがこれまでJIT噴射攻撃に対して対策されていなかったこと」だと同サイトは強調する。BPFはコンテナ環境やクラウドインフラで広く使われ、特権のないユーザー空間からも利用可能なため、攻撃対象領域として見過ごせない存在だった。

既にLinux 7.2-rc1では、Linux 7.2-rc1リリース、AMDGPU HDMI 2.1 FRLやCache Aware Schedulingを統合の記事で報じられた通り、AMDGPU HDMI 2.1 FRL対応やCache Aware Schedulingが統合されていた。今回のセキュリティ強化は、rc1からrc2へのステップで投入された重要な修正である。

パッチの詳細：2段階のハードニング

Guptaが投稿した最初のパッチは、BPF JITアロケータにおける間接分岐予測のフラッシュを実装するものだ。BPF JITアロケータは多数の小さなプログラムをより大きな実行可能領域にパッキングし、プログラムのロードと解放に伴って領域を再利用する。この再利用時に、古いプログラムが残した分岐予測が新しいプログラムの実行に悪影響を及ぼす可能性があった。

具体的には、bpf_arch_pred_flush_enabledという静的キーとbpf_arch_pred_flushという静的コールが導入される。アーキテクチャごとに必要なフラッシュ関数をフックできる設計で、デフォルトはNOP（no-operation）であり、余分なCALL命令は発行されない。パックサイズを超える大きな割り当てはフラッシュの対象外となるが、これはcBPF（classic BPF）プログラム、すなわち非特権ユーザーからの攻撃経路がパックサイズ未満に十分収まることが理由だ。仮にこの前提が破られた場合、警告が発行される仕組みとなっている。

2つ目のパッチは、Spectre-v2緩和策が有効な環境で、IBPB（Indirect Branch Predictor Barrier）フラッシュをBPF JIT割り当てに対して有効にするものだ。具体的には、BPF JITメモリの再利用時にIBPBを発行する。ただし、BPFディスパッチャが既にretpoline（リターンポリシン）を使用している場合は、IBPBフラッシュをスキップする。このハードニングはCONFIG_BPF_JITが有効な場合にのみ動作し、CONFIG_BPF_JIT=nのビルドではbugs.cが影響を受けないようにガードされている。

セキュリティへの影響と業界の反応

今回の修正は、投機的実行の脆弱性に対するカーネル側の防御を一段階進めるものだ。BPFはクラウドネイティブな環境で不可欠な機能であり、DockerやKubernetesのネットワークポリシー、オブザーバビリティツールなどに利用されている。非特権ユーザーがBPFプログラムをロードできるシステムでは、JIT噴射攻撃のリスクが現実的な脅威だった。

Intelのエンジニアが主導した点も注目に値する。IntelはSpectre脆弱性の発覚以来、ハードウェアとソフトウェアの両面で緩和策を提供してきたが、今回のパッチはその流れをさらに推し進めるものと言える。AMDやArmのアーキテクチャでも、適切なフラッシュ関数を実装すれば同様の保護が可能となる設計になっている。

関連して、Linux Cache Aware Scheduling拡張、MySQL最大360%高速化でも報じられたように、Linuxカーネルはパフォーマンスとセキュリティの両軸で進化を続けている。今回のBPF JITハードニングも、パフォーマンスへの影響を最小限に抑えつつ、投機的実行の脆弱性に対処するバランスの取れた設計といえる。

編集部の見解

短期的には、今回のパッチによって主にBPF JITバッファの再利用時に生じる投機的実行脆弱性のリスクが低減される。クラウド事業者やデータセンター運用者にとっては、マルチテナント環境でのISOLATION強化に寄与する変更だ。特に非特権BPFが有効なシステムでは、すぐにアップデートを適用すべきだろう。パフォーマンスへの影響は限定的と見られるが、IBPBフラッシュの頻度によってはレイテンシが増加する可能性があり、実運用での測定が待たれる。 長期的な視点では、今回の対策はSpectre-v2緩和策の延長線上にある過渡的な対応と評価できる。将来のCPU世代ではハードウェアレベルでの分岐予測隔離が進むと予想されるが、既存のハードウェアを保護するにはソフトウェア側での継続的な対策が不可欠だ。また、ArmやRISC-Vアーキテクチャへの同様の対応も課題として残る。カーネルメンテナは各アーキテクチャ向けのフラッシュ関数の実装を促していくと見られる。 編集部としては、なぜ今までこの対策がBPFコードに存在しなかったのかが最大の疑問点だ。

参考

• Phoronix — 2026-07-03T10:49:59.000Z公開