Epic Gamesは2026年10月14日、不正行為対策ソフト「Easy Anti-Cheat」のLinux実装を「EAC Linux v2」として再構築すると発表した。Windows版に近い保護を目指す一方、専用のアンチチート用カーネルモジュールは導入せず、Linuxに備わるセキュリティ機能とeBPFを組み合わせる計画だ。まずFortniteで試験導入し、効果を確かめてから他のゲーム開発者へ広げるという。Linuxで動くゲームを増やすうえで、ゲーム側の対応に加え、誰が署名したカーネルをどの設定で起動するかが問われることになる。

AD

専用モジュールなしでも、OSの保護機能は使う

EAC Linux v2では、保護対象のゲームを初めて起動すると、アンチチート用のsystemdサービスをインストールするよう求められる。systemdはLinuxでサービスの起動や停止を管理する仕組みで、このサービスもゲーム開始時に動き、終了時には停止する設計だ。

Epicは公式発表のFAQで、「EAC Linux v2は、アンチチート用カーネルモジュールをインストールも読み込みもしない」と説明している。ただし、専用モジュールを使わなくても、OSの深い部分で制御を行う。そこで使うのが、カーネルの機能を利用して処理を実行するeBPFと、セキュリティ上の操作を監視・制限するBPF LSMである。

Linuxカーネルの公式文書は、BPF LSMについて、特権を持つユーザーがシステム全体のアクセス制御や監査を実装できる機能と記す。Epicはこれを使い、別のプロセスが保護対象ゲームのメモリを読み書きする行為を制限し、不正を監視するとしている。専用モジュールがないという説明から、権限の小さな通常アプリだけで保護すると受け取るのは早計だ。

そもそもEACのLinux対応自体は新しくない。ネイティブのLinuxゲームには2014年から、WindowsゲームをLinuxで動かすWine／Proton経由では2021年から対応してきた。ところが有効化はゲームごとに必要であり、EpicによればLinux実装がWindows版と同水準の保護を提供できなかったため、対応を見送るゲームが残った。v2が埋めようとしているのは、この保護水準の差である。

8要件が確かめる、署名・起動記録・実行中の状態

Epicが2026年10月14日に示したEAC Linux v2の8要件は、署名の確認、起動内容の記録、起動後の改変制限という3つの役割で整理できる。公式技術ブログの要件1〜8を、主に何を検証・制限するかで分けると次のようになる。

主な役割 要件 Epicが求める状態
署名の確認 署名付きカーネルとモジュール 組織が構築し、Epicが認める署名鍵で署名したものを使う
署名の確認 Secure Boot BIOSで有効にし、認められた鍵で起動する
起動内容の記録 TPM 2.0 BIOSで有効にし、改ざんしにくい起動記録の基盤とする
起動内容の記録 起動時の測定 実行コードや構成の測定結果が記録されている
起動後の改変制限 IOMMU 携帯型以外ではBIOSとカーネルで有効にし、パススルーを無効にする
起動後の改変制限 カーネルロックダウン integrityモードを起動時に明示して有効にする
起動後の改変制限 kexecの無効化 起動時に明示して無効にする
起動後の改変制限 BPF LSM 読み込まれ、有効になっている

表の3分類は各機能の主な役割に基づく整理であり、Epic自身が示した分類ではない。TPMが起動時の測定を支え、kexecの無効化が測定記録との対応を保つように、各機能は互いに関わる。要件は今後変わり得るとEpicは説明しており、表も保護性能の測定結果を示すものではない。

Secure Bootと起動時の測定は、似て見えて確かめる対象が違う。前者は起動するコードの署名を検証し、後者は実際に起動したコードや構成の情報をTPMに記録する。その記録があれば、アンチチート自体がOS起動時から動き続けなくても、後から起動内容を確かめられるというのがEpicの説明だ。

しかし、記録後にカーネルを入れ替えられれば、過去の起動記録だけでは現在の状態を説明できなくなる。完全な再起動を経ずに新しいカーネルへ移るkexecを無効化するのは、この食い違いを防ぐためである。管理者権限によるカーネルの改変などを抑えるロックダウンも、起動後の状態を保つ役割を担う。

IOMMUは、機器から物理メモリへの直接アクセスを制御する機能だ。Epicは不正用のハードウェアによるゲームへのアクセスを防ぐ目的で挙げているが、有効化要件の対象を「携帯型以外」としている。この限定はIOMMUの項目にあるもので、携帯型端末が残りの要件まで免除されるという意味にはならない。

AD

自分で署名するだけでは満たせない条件

カーネルやドライバーを自分で構築する利用者にとっては、署名を付けることと、EAC Linux v2に認められることの違いが大きい。Epicは、利用するカーネルや追加モジュールについて、組織が構築し、認められた鍵で署名するよう求めている。個人の任意の鍵で署名すれば条件を満たす、という仕組みではない。

Linuxのモジュール署名機能は、モジュールを読み込む際にカーネルが署名を検証する仕組みである。上流の文書には、未署名や鍵不明のモジュールを許可する設定と、カーネルが持つ公開鍵で検証できる有効な署名だけを受け入れる設定がある。つまり、Linuxが署名を検証できることに加えて、EAC v2では構築した組織と署名鍵も条件になる。

多くのLinux用ドライバーはカーネルのソースに含まれ、ディストリビューション側がカーネルと一緒に構築・署名する。一方、Epicが外部モジュールの例に挙げたNVIDIA GPUドライバーなどにも、同じ条件が及ぶ。ゲームを動かすためのGPUドライバーまで含め、認められた署名のある構成を用意できるかが利用者に関わってくる。

Epicは当初、認める署名鍵の一覧を自ら管理し、将来のオープンソース化を目指す。一覧にはCanonicalやFedora、Bazziteなどが使うUniversal Blueの鍵が含まれるが、これは鍵の一覧であって、個別のゲームの動作保証ではない。ディストリビューションの保守担当者には、設定要件への対応と鍵の追加に向けた協議を呼びかけている。

普段使う環境を常にゲーム向けの設定に固定する必要はない。Epicは、必要なカーネルと起動設定を指定した別の起動エントリーを用意し、保護対象ゲームを遊ぶときに選ぶ方法を示す。ただしshimを経由して起動する場合、モジュール検証に使われる登録済みのMOK（Machine Owner Key）はすべて認められた鍵である必要があり、起動の選択肢を分けるだけで任意の鍵を併用できるとは限らない。要件を満たさずにゲームを起動した場合は、アカウント停止ではなくエラー表示になるという。

Fortniteで先行検証、既存ゲームは移行を選べる

EAC Linux v2はまずFortniteの実環境で試し、効果を検証してから他の開発者に提供する計画である。Windows版に近い保護という説明も、現時点ではEpicが目指す水準だ。具体的な提供日は示されておらず、発表をもってFortniteがLinuxで遊べるようになったとは扱えない。

Steam Deckについても、Epicは現状ではv2が必要とする機能を満たさないと説明している。Valveと協議し、将来の対応を望んでいる段階で、不足する機能の内訳や対応時期は明らかにしていない。Linux対応の拡大計画を、そのままSteam Deck対応の確約へ読み替えることはできない。

既存のEAC Linux対応を有効にしているゲームには選択肢が残る。開発者は互換性を優先して旧実装を維持することも、保護の強化を目指してv2へ切り替えることも可能だ。すべてのゲームを一斉に新要件へ移す方針ではない。

Epicは、必要な機能を標準設定で満たすディストリビューションが増えるほど、利用者による設定変更が減ると見込んでいる。Fortniteで保護効果を検証できるかに加え、配布元が署名済みの構成を整え、ゲーム開発者が採用するかも普及を左右する。両者の対応が進めば、Linux利用者が対戦ゲームを遊ぶために自分で環境を調整する負担を減らせる可能性がある。