各検出クラスは差分判定（differential verdict）である。すなわち2つ以上のチャネル間の不一致に基づく。検出エンジンはレジストリ＋/procスナップショット＋チャネルタイムスタンプに対する純粋関数であり、I/Oも副作用もなく、完全にユニットテスト可能である。

### NMIの再設計：観測から完全性へ

元の設計では、NMIはCPUをサンプリングしてどのタスクが実行中かを報告する第二のプロセス観測チャネルであった。これは冗長だった。なぜならsched\_switchがすでにスケジューリングを観測しており、NMIは別のメカニズムで同じデータをサンプリングしていたからである。この冗長性により、CPUあたり毎秒約1000以上のリングバッファイベントのプロセスデータが消費され、その99.999%は「はい、スケジューラはスケジューラの仕事をしている」ことを確認するだけだった。

再設計されたアーキテクチャでは、**NMIはプロセス観測からトレースポイントの完全性検証へと目的を変更する。** どのプロセスがCPU上にいるかを報告するのではなく、代わりに共有の`.bss`ハートビートを読み取ることで`sched_switch`が実際に動作していることを検証する。これにより以下の効果が得られる。

1. NMIリングバッファトラフィックの約99%を削減（定常状態ではイベントがほぼゼロ）
2. トレースポイントのデタッチ、抑制、BTF/アタッチ障害を直接検出（本来のBTFバグ — [§11](#11-the-btf-bug-incident)参照）
3. ハードウェア割り込みから動作し、トレースポイントディスパッチパスの外にあるため、`bpf_override_return`、kprobeインターセプト、funcs配列操作の影響を受けない
4. `.bss`グローバルをBPFヘルパーではなく直接メモリアクセスで読み取るため、ヘルパー関数に対する`fmod_ret`の影響を受けない

---

## 3. sched\_switch観測チャネル

`sched_switch`トレースポイントにアタッチされたeBPFプログラムは、カーネルがCPUにプロセスをスケジュールするたびに起動する。伝統的な（BTF以外の）固定オフセット読み取りを使用して、トレースポイントの引数から直接、入力タスクのPIDとcommを読み取る。```
ctx.read_at::<u32>(56)    → next_pid
ctx.read_at::<[u8;16]>(40) → next_comm

### なぜこれがスコープ内のすべての攻撃を検出するのか

| 攻撃 | 発生内容 | NMI の観測結果 |
|---|---|---|
| funcs 配列から切り離されたトレースポイント | sched\_switch の実行が停止 | `SCHED_HEARTBEAT` が停止 → TAMPER |
| BTF バグ / アタッチ失敗（サイレント） | sched\_switch が決して実行されない | `SCHED_HEARTBEAT` が 0 のまま → TAMPER（猶予後） |
| スケジューラ関数への `bpf_override_return` | トレースポイントの発火を妨げた場合 | `SCHED_HEARTBEAT` が停止 → TAMPER |
| インプレースでのバイトコードパッチ | 任意のカーネル書き込み（LKM レベル）が必要 | eBPF の脅威モデルの範囲外 |
| リングバッファのコンシューマポインタが操作された | sched イベントがユーザースペースに到達しない | `SCHED_HEARTBEAT` はまだ進行する（プログラムは実行される）→ 誤った TAMPER は発生しない；ユーザースペースが `max(sched_last)` の古さを検出 → SILENT |

### なぜ特に `.bss` なのか

`.bss` のグローバル変数は、BPF プログラムの内部データセクションに格納され、ローダーが管理する内部配列マップによってバックアップされています。それらは：

- **個別にピン留め不可** — `/sys/fs/bpf/` に名前付きマップとして表示されない
- **`bpf_map_update_elem` フックによる傍受不可** — `.bss` への書き込みは直接メモリストアであり、マップ更新システムコールではありません。以前の `sc_canary` メカニズム（`.bss` のコピーと名前付きマップのコピーを比較して `bpf_map_update_elem` の傍受を検出する）は不要になりました。
- **同じ ELF オブジェクト内のプログラム間で共有** — sched\_switch と NMI は外部インターフェースなしで `.bss` を介して通信します

### BPF ベースの傍受に対する耐性

NMI 整合性チェッカーは、根本的な特性により BPF オーバーライド攻撃に対して構造的に耐性があります：`bpf_override_return` は関数の**呼び出し**をインターセプトしますが、NMI チェッカーは検証対象を*呼び出し*ません — `.bss` メモリを*直接読み取る*だけです。メモリ読み取りは関数呼び出しではないため、その戻り値をオーバーライドすることはできません。

さらに：
- `bpf_probe_read_kernel`（代替設計でカーネル構造体の読み取りに使用される）は、任意のアドレスを受け入れるフォールトセーフなヘルパーですが、SPiCa の `.bss` ハートビート設計はそれを必要としません。チェッカーは直接ロード命令によって `.bss` グローバル変数を読み取ります。
- NMI プログラムは NMI コンテキストで実行され、そこでは kprobe が構造的に信頼できません（カーネルがそれらを延期または抑制します）。チェッカーの実行に対する kprobe ベースの攻撃はハードウェアと戦うことになります。

### NMI イベントのセマンティクス

NMI リングバッファ (`sc_nmi`) は軽量イベントを運びます：

| `event_type` | 意味 | ユーザースペースのアクション |
|---|---|---|
| 0 | ハートビート — NMI 生存、sched\_switch 生存 | `last_nmi_heartbeat` タイムスタンプを更新 |
| 1 | TAMPER — NMI 生存、sched\_switch ハートビートが停止 | 即座に `[TAMPER]` を出力 |

イベントは最大でも1秒に1回発行されます（`NMI_LAST_EMIT` によってスロットリング）。NMI リングバッファが5秒以上無音になった場合、ユーザースペースは `[SILENT]` を発行します — NMI チャネル自体が死んでいます。

---

## 5. 検出ロジック```mermaid
graph TD
    subgraph RING0["Kernel Space: Four eBPF Programs"]
        direction TB
        SCHED_P["TracePoint, sched_switch<br/>read next_pid, next_comm<br/>write SCHED_HEARTBEAT (.bss)<br/>XOR obfuscate → sc_sched"]
        NMI_P["PerfEvent hardware NMI<br/>read SCHED_HEARTBEAT (.bss)<br/>compare to NMI_LAST_HB<br/>frozen → event_type=1 (TAMPER)<br/>alive → event_type=0 (heartbeat)<br/>→ sc_nmi"]
        LSM_P["BPF LSM, kernel_read_file<br/>READING_MODULE<br/>gate=0: allow + log<br/>gate=1: EPERM + log → sc_lsm"]
        WATCH_P["TracePoint, sched_process_exit<br/>current == SPICA_PID (.bss)? → sc_wd flag"]
    end

    subgraph RING3["User Space: Differential Engine"]
        ENGINE["SPiCa (Tokio async)"] -->|XOR deobfuscate| RB_S[(sc_sched RingBuf)]
        ENGINE -->|event_type=0: heartbeat<br/>event_type=1: TAMPER| RB_N[(sc_nmi RingBuf)]
        ENGINE -->|raw read| RB_L[(sc_lsm RingBuf)]
        ENGINE -->|read_dir| PROC[" /proc"]
        RB_S --> FSM{Detection FSM}
        PROC --> FSM
        FSM -->|scheduled, absent /proc, >2s| D1["[DKOM]"]
        FSM -->|in /proc, never seen by sched, >5s| D2["[GHOST]"]
        RB_N -->|event_type = 1| D3["[TAMPER]"]
        FSM -->|sched channel silent, /proc ≠∅| D4["[SILENT]"]
        FSM -->|raw getdents64 ≠ libc readdir| D9["[HOOK]"]
        RB_S -->|same TGID, different start_time_ns| D5["[DUPE]"]
        RB_L -->|allowed = 1| D7["[LKM-ALLOW]"]
        RB_L -->|allowed = 0| D8["[LKM-DENY]"]
        WATCH_P -.->|pin exists at startup| D6["[WATCHDOG]"]
    end

    classDef kernbox  fill:#fdf2f8,stroke:#9333ea,stroke-width:2px,color:#581c87;
    classDef userbox  fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e3a8a;
    classDef alertbox fill:#fff7ed,stroke:#ea580c,stroke-width:1px,color:#7c2d12;
    classDef storage  fill:#f8fafc,stroke:#64748b,stroke-width:1px;
    class RING0 kernbox;
    class RING3 userbox;
    class D1,D2,D3,D4,D5,D6,D7,D8,D9 alertbox;
    class RB_S,RB_N,RB_L,PROC storage;

この手法は、SPiCaのカーネルレベル特権を利用して、ユーザ空間ルートキットを能動的に検出します。生のシステムコールパスが真実の基準であり、ユーザ空間のフックでこれを隠すことはできません。libcパスは、通常のツール（ps, ls）が見る「認識された」ビューです。その不一致は、ライブラリインターセプションの明白な証明となります。

**`[HOOK]`で検出されるルートキット：**

| ルートキット | 隠蔽機構 | 検出 |
|---------|-----------------|----------|
| Symbiote | 寄生型LD_PRELOAD、`readdir`をフック | はい（能動的に隠蔽している場合） |
| JynxKit | LD_PRELOAD、`readdir`による`MAGIC_GID`隠蔽 | はい |
| Azazel | LD_PRELOAD、`readdir` + `stat`フック | はい |
| Medusa/OrBit | LD_PRELOAD、`readdir` + 資格情報窃取 | はい |

**本物のSymbioteで試験済み：** ライブのSymbioteサンプル（SHA256 `f55af21f...`、MalwareBazaar）がUbuntu 24.04 VM上で`/etc/ld.so.preload`経由で展開されました。このサンプルは`readdir`、`readdir64`、`stat`、`fstatat`、`pam_authenticate`、`pcap_loop`、`recvmsg`、`fopen`、`read`、`execve`をフックします。LD_PRELOADフックが能動的にPIDを`readdir`から隠蔽すると、SPiCaは1ティックサイクル（<1秒）以内に`[HOOK]`を発します。Symbioteがロードされているが受動的（能動的に隠蔽していない）場合、SPiCaは誤検出を一切生成しません。

### 猶予ウィンドウ

50ミリ秒の猶予ウィンドウにより、フォーク直後のプロセスにおける誤検出を防止します。チャネルレベルのSILENTチェックには5秒の猶予期間（NMIプログラムの`NMI_FIRST_TICK`参照）があり、起動レイテンシが偽のTAMPERアラートを生成しないようにしています。

---

## 6. 検証器境界アドレス秘匿性

### 定義

**検証器境界アドレス秘匿性**は、eBPF制約のある敵対者モデルの下で成立する計算論的なセキュリティ特性です。それは次のように述べています：

> eBPFプログラムをロードできる（CAP\_BPF）が、BPF検証器により制約される（有界ループ、制限付きヘルパー、任意のカーネル書き込み不可）敵対者を想定すると、BPFプログラムの`.bss`データセクションのカーネルアドレスを発見することは計算上不可能です。

### 4つのメカニズム

この特性は、4つの独立した障壁の合成です：

1. **kASLR** — カーネルアドレス空間レイアウトランダム化は、BPFマップメモリ（`.bss`バッキングマップを含む）が割り当てられるカーネルヒープ領域をランダム化します。正確なアドレスは起動のたびに変わります。

2. **検証器命令上限** — BPF検証器はプログラムあたりの総命令数を約100万に制限し、ループの停止が証明可能であることを要求します。敵対者のスキャンプログラムは`bpf_probe_read_kernel`を介して、ロードあたり最大 N ≈ 10^6 個のアドレスを調査できます。kASLRでランダム化された探索空間を考慮すると、プログラムあたりの成功確率は無視できます。

3. **LSMマップアクセスゲート**（[§7](#7-lsm-map-access-gate)参照） — ゲートがない場合、敵対者はIDでBPFマップを列挙し（`BPF_MAP_GET_NEXT_ID` → `BPF_MAP_GET_FD_BY_ID` → `BPF_MAP_LOOKUP_ELEM`）、`.bss`の内容を直接読み取ることができます。ゲートはこの簡単な経路を排除し、敵対者を検証器境界のメモリースキャン経路へと強制します。

4. **`.bss`の配置** — `.bss`グローバルは、人間が読める名前を持つ名前付きマップ列挙インターフェースには現れません。内部の`.bss`バッキングマップはlibbpf/ayaによって`.bss`と名付けられますが、その内容（実際のグローバル変数）にアクセスできるのは、マップfdを持っている場合のみです。マップfdは、ロードプロセスのfdテーブルかマップID（ゲートでブロックされる）のいずれかを必要とします。

### 形式的議論構造```
Adversary's goal:    locate SPiCa's .bss in kernel virtual memory
Search space:        kernel heap region, kASLR-randomized (~2^30 entropy)

Path A — map enumeration (blocked):
  BPF_MAP_GET_NEXT_ID → BPF_MAP_GET_FD_BY_ID → BPF_MAP_LOOKUP_ELEM
  → blocked by LSM gate (§7) for non-SPiCa processes

Path B — memory scan (bounded):
  bpf_probe_read_kernel(addr, buf, len) — fault-safe, accepts any addr
  Per-program capacity: N ≈ 10^6 probes (instruction limit)
  Success probability per load: N / |search space| ≈ 10^6 / 2^30 ≈ 10^-24
  Can reload programs, but: each load is a syscall (observable), and
  the target address doesn't change between loads (same boot session)

Path C — timing side channel (theoretical):
  bpf_probe_read_kernel timing varies on fault vs success
  Binary search over the heap could reduce scan complexity to O(log |A|)
  → O(30) probes, well within instruction budget
  LIMITATION: must be acknowledged. Mitigated by rate-limiting BPF_PROG_LOAD
  via the LSM gate (future work).

Against the eBPF adversary (who can't call syscalls), `.bss` is hidden. Against userspace root, it's a standard map — fully readable. The LSM gate closes this gap.

### 防御

`bpf`システムコール上のBPF LSMフックがマップアクセスコマンドをチェックする:```
hook = "bpf"
  read cmd (arg 0)
  if cmd == BPF_MAP_GET_FD_BY_ID:
    read map_id from userspace bpf_attr (bpf_probe_read_user)
    if map_id matches any of SPiCa's stored IDs (.bss):
      if caller_tgid != SPICA_PID:
        return -EPERM

SB  -->|"boot chain verified"| MS
MS  -->|"signed modules only"| IMA
IMA -->|"measured + appraised"| SPICA

classDef firmware fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f
classDef kernel   fill:#fdf2f8,stroke:#9333ea,stroke-width:2px,color:#581c87
classDef spica    fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e3a8a
class SB firmware
class MS,IMA kernel
class SPICA spica

SPiCaは起動時に4つのレイヤーすべてをチェックし、それらのステータスを表示します。

---

## 11. BTFバグインシデント

### 発生したこと

Ubuntu（最新カーネル）でのテスト中、BTFの非互換性により、`sched_switch` トレースポイントプログラムのアタッチは成功したものの、**イベントが1つも発火しませんでした。** `attach()` システムコールは `Ok(())` を返したため、SPiCaは正常に動作を続けましたが、schedリングバッファは空のままでした。検出エンジンにスケジューリングデータがなかったため、検出アラートは1つも発火しませんでした。**SPiCaは何の障害表示もなく、盲目的に動作していました。**

これがセキュリティツールにとって最悪の故障モードです：サイレントブラインドネス。

### 検出されなかった理由

元の検出エンジンは**プロセス単位**で推論していました。各プロセスレコードには `sched_last` と `nmi_last` のタイムスタンプが含まれており、生存性はレコードごとに計算されていました。sched_switch がグローバルに停止したとき：

1. `sched_live` はすべてのレコードで false に反転しました（新しいschedイベントがない → すべての `sched_last` 値が期限切れになる）
2. プロセス単位の `TAMPER` 述語（`in_proc && nmi_live && !sched_live`）は発火可能でしたが、`nmi_live` が*継続的に*2秒間保持される必要がありました。NMIサンプルはまばら（10Mサイクル周期）だったため、`suspect_since` はサンプリングジッタでリセットされ続け、成熟しませんでした。
3. プロセス単位の `SILENT` 述語は `sched_live` を必要としましたが、今やすべてがfalseでした — 述語はまさに検出対象の条件下で逆転しました。
4. **チャネルレベルの生存確認が存在しませんでした** — 「schedが一度でも発火したか？」や「max(sched_last) が古くなっていないか？」という機構がありませんでした。

さらに、時間ベースの不一致が発見されました：`sched_last` は `bpf_ktime_get_ns()`（カーネル起動ナノ秒）を格納していたのに対し、`evaluate()` は `nanos_since_startup()`（プロセスローカルナノ秒）と比較していました。これらの異なる時間ベースの `wrapping_sub` は巨大な値を生成し、すべての生存性述語を自明に偽にしました。検出ロジックは本番環境で正しく動作したことがありませんでした — BTFバグがイベントの到着を妨げることで、それを隠していたのです。

### 再設計による修正方法

| 問題 | 修正 |
|---|---|
| チャネルレベルの生存確認がない | `evaluate()` は `max(sched_last)` を計算し、`/proc` が空でない場合に古くなったら `[SILENT]` を発火する |
| プロセス単位のTAMPERが成熟しなかった（ジッタリセット） | TAMPERはNMIプログラムからの直接信号（`.bss` ハートビート比較）になり、閾値付きのプロセス単位FSMではなくなった |
| プロセス単位のSILENTがsched停止時に逆転 | SILENTはチャネルレベルになり、レコード単位の述語ではなく集約から計算される |
| 時間ベースの不一致 | `sched_last` は `bpf_ktime_get_ns()` ではなくプロセスローカル時間（`now` パラメータ）を格納する |
| NMIは冗長な観測だった | NMIは現在、整合性チェッカーであり、`.bss` ハートビートを介してschedの停止を直接検出する |

---

## 12. 既知の制限と攻撃対象領域

### eBPF脅威モデル内

| 攻撃 | 状態 | 備考 |
|---|---|---|
| **リングバッファコンシューマポインタ操作** | **検出済み** (SILENT) | `max(sched_last)` が古くなる → SILENT。`SCHED_HEARTBEAT` は進み続ける（プログラムは動作）→ 誤ったTAMPERは発生しない。 |
| **Perfイベント構造体DKOM**（`state`フィールドをゼロにする） | **検出済み** (SILENT) | NMIが停止 → ハートビートイベントなし → NMIチャネルでSILENT |
| **`task_struct`フィールド偽装**（pid/tgidの上書き） | **部分的** (DUPE) | 偽装されたTGIDが異なる `start_time_ns` を持つ既存のレコードと一致する場合、DUPEが発火。`start_time_ns` も偽装された場合、すり抜ける。 |
| **eBPFプログラムのデタッチ**（funcs配列からの削除） | **検出済み** (TAMPER) | NMIハートビートが停止 → TAMPER |
| **バイトコードのインプレースパッチ** | **未検出** | 任意のカーネル書き込みが必要（LKMレベル）— eBPF脅威モデルの範囲外 |
| **`bpf_probe_read_kernel` のタイミングサイドチャネル** | **理論的リスク** | ヒープ上のバイナリ検索で約30回のプローブで `.bss` を見つけられる可能性あり。[§6](#6-verifier-bounded-address-secrecy) の制限を参照。 |

### eBPF脅威モデルの外部（認識済み、未解決）

| 攻撃 | 状態 | 備考 |
|---|---|---|
| **IDT/NMIハンドラフック** | **生きた爆弾** | アーキテクチャ的に完全なバイパス。ほぼ確実にカーネルパニック。 |
| **デュアルチャネル抑制** | **生きた爆弾** | sched + NMIを同時に抑制。NMIフックの不安定性を継承。 |
| **検証器エクスプロイト** | **非目標** | 任意のカーネルコード実行への脱出。別の脅威クラス。 |
| **ptrace / `/proc/pid/mem`** | **根本的な制限** | 同一特権のメモリ読み取り。オフホストログ転送のみが有効。 |
| **コンシューマポインタ＋ハートビートパッチ** | **LKMレベル** | 攻撃者が任意のカーネル書き込みを持っている場合、コンシューマポインタを進めつつ偽のハートビートを書き込める。しかし、任意のカーネル書き込み＝LKMレベル＝脅威モデルの範囲外。 |

---

## 13. ビルドと実行

### 前提条件

- Linuxカーネル >= 5.15 で `CONFIG_DEBUG_INFO_BTF=y` が有効であること（LSMフックのみに必要）
- モジュールブロック用: カーネルコマンドラインに `CONFIG_BPF_LSM=y` と `lsm=bpf`
- TPM 2.0チップ + `tpm2-tss` ライブラリ（オプション、見える警告付きでフォールバック）
- Nightly Rustツールチェーン

> **注:** `generate-vmlinux` ステップは **不要になりました**。eBPFプログラムは従来のトレースポイントオフセットと `.bss` グローバル変数を使用しており、CO-RE/BTF構造体ナビゲーションは必要ありません。xtaskの `generate-vmlinux` コマンドは将来の使用のために残されていますが、ビルドパイプラインの一部ではありません。

BPF LSMがアクティブであることを確認: `cat /sys/kernel/security/lsm` の出力に `bpf` が含まれていること。

### セットアップ```shell
make install-deps     # system packages + nightly Rust (pacman/apt/dnf auto-detected)
make install-tools    # bpf-linker
make build            # compiles eBPF + userspace (no vmlinux generation needed)

### initramfs へのインストール（起動初期の保護）```shell
sudo make install     # spica install — auto-detects Debian (initramfs-tools) or Fedora (dracut)

### 開発 (macOS または Linux)

eBPF プログラムは macOS では実行できません。`cargo check` と検出ロジックの単体テストは機能しますが、完全なランタイム検証には Linux が必要です。```shell
make check      # cargo check for workspace
make check-ebpf # cargo check for the eBPF crate (bpfel-unknown-none)
make test       # unit tests for detection FSM, key derivation, obfuscation