Chaque classe de détection est un verdict différentiel : une divergence entre deux ou plusieurs canaux. Le moteur de détection est une fonction pure sur le registre + instantané /proc + horodatages des canaux — pas d'E/S, pas d'effets secondaires, entièrement testable unitairement.

### La refonte du NMI : de l'observation à l'intégrité

Dans la conception originale, le NMI était un second canal d'observation des processus qui échantillonnait le CPU et rapportait quelle tâche était en cours d'exécution. C'était redondant : sched_switch observe déjà l'ordonnancement, et le NMI échantillonnait les mêmes données via un mécanisme différent. La redondance coûtait environ 1000+ événements de tampon en anneau par seconde par CPU de données de processus qui, 99,999 % du temps, confirmaient « oui, l'ordonnanceur fait ce que l'ordonnanceur fait ».

Dans l'architecture repensée, **le NMI est réutilisé de l'observation des processus vers la vérification d'intégrité des tracepoints.** Il ne rapporte plus quel processus est sur le CPU. Au lieu de cela, il vérifie que `sched_switch` est effectivement en cours d'exécution en lisant un heartbeat partagé `.bss`. Cela :

1. Élimine environ 99 % du trafic du tampon en anneau NMI (événements quasi nuls en régime permanent)
2. Détecte directement le détachement, la suppression et les échecs d'attachement BTF des tracepoints (le bug BTF original — voir [§11](#11-the-btf-bug-incident))
3. S'exécute depuis une interruption matérielle, en dehors du chemin de distribution des tracepoints — immunisé contre `bpf_override_return`, l'interception kprobe et la manipulation du tableau de fonctions
4. Lit les globales `.bss` via un accès mémoire direct, pas via les helpers BPF — immunisé contre `fmod_ret` sur les fonctions helpers

## 3. Le canal d'observation sched\_switch

Un programme eBPF attaché au tracepoint `sched_switch` se déclenche chaque fois que le noyau ordonnance un processus sur un CPU. Il lit le PID et le comm de la tâche entrante directement depuis les arguments du tracepoint en utilisant des lectures traditionnelles (non-BTF) à décalage fixe :```
ctx.read_at::<u32>(56)    → next_pid
ctx.read_at::<[u8;16]>(40) → next_comm

### Pourquoi cela détecte toutes les attaques dans le périmètre

| Attack | Ce qui se produit | Ce que NMI voit |
|---|---|---|
| Tracepoint détaché du tableau funcs | sched\_switch cesse de s'exécuter | `SCHED_HEARTBEAT` se fige → TAMPER |
| Bogue BTF / échec d'attachement (silencieux) | sched\_switch ne s'exécute jamais | `SCHED_HEARTBEAT` reste à 0 → TAMPER (après délai de grâce) |
| `bpf_override_return` sur une fonction du planificateur | Si elle empêche le tracepoint de se déclencher | `SCHED_HEARTBEAT` se fige → TAMPER |
| Bytecode modifié en place | Nécessite une écriture arbitraire dans le noyau (niveau LKM) | En dehors du modèle de menace eBPF |
| Pointeur consommateur du ring buffer manipulé | Les événements sched n'atteignent pas l'espace utilisateur | `SCHED_HEARTBEAT` avance toujours (le programme s'exécute) → pas de faux TAMPER ; l'espace utilisateur détecte via `max(sched_last)` obsolète → SILENT |

### Pourquoi `.bss` spécifiquement

Les globales `.bss` sont stockées dans la section de données interne du programme BPF, soutenue par une map de tableau interne gérée par le chargeur. Elles sont :

- **Non pinables séparément** — elles n'apparaissent pas comme des maps nommées dans `/sys/fs/bpf/`
- **Non interceptables via les hooks `bpf_map_update_elem`** — les écritures `.bss` sont des stockages mémoire directs, pas des appels système de mise à jour de map. L'ancien mécanisme `sc_canary` (comparant une copie `.bss` avec une copie de map nommée pour détecter l'interception de `bpf_map_update_elem`) n'est plus nécessaire.
- **Partagées entre les programmes dans le même objet ELF** — sched\_switch et NMI communiquent via `.bss` sans interface externe

### Immunité contre l'interception basée sur BPF

Le vérificateur d'intégrité NMI est structurellement immunisé contre les attaques de remplacement BPF en raison d'une propriété fondamentale : `bpf_override_return` intercepte les **appels** de fonction, mais le vérificateur NMI n'*appelle* pas les éléments qu'il vérifie — il *lit directement la mémoire `.bss`*. Vous ne pouvez pas remplacer la valeur de retour d'une lecture mémoire car une lecture mémoire n'est pas un appel de fonction.

De plus :
- `bpf_probe_read_kernel` (utilisé pour les lectures de structures noyau dans des conceptions alternatives) est un helper sécurisé qui accepte toute adresse — mais la conception du heartbeat `.bss` de SPiCa n'en a même pas besoin. Le vérificateur lit les globales `.bss` via des instructions de chargement directes.
- Le programme NMI s'exécute dans un contexte NMI, où les kprobes sont structurellement peu fiables (le noyau les diffère ou les supprime). Une attaque basée sur kprobe contre l'exécution du vérificateur lutte contre le matériel.

### Sémantique des événements NMI

Le ring buffer NMI (`sc_nmi`) transporte des événements légers :

| `event_type` | Signification | Action de l'espace utilisateur |
|---|---|---|
| 0 | Heartbeat — NMI en vie, sched\_switch en vie | Mettre à jour le timestamp `last_nmi_heartbeat` |
| 1 | TAMPER — NMI en vie, heartbeat de sched\_switch gelé | Afficher `[TAMPER]` immédiatement |

Les événements sont émis au maximum une fois par seconde (limité par `NMI_LAST_EMIT`). Si le ring buffer NMI devient silencieux pendant >5 secondes, l'espace utilisateur déclenche `[SILENT]` — le canal NMI lui-même est mort.

---

## 5. Logique de détection```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;

Cette technique transforme le privilège au niveau noyau de SPiCa en une détection active des rootkits en espace utilisateur. Le chemin d'appel système brut est la vérité de référence — aucun hook en espace utilisateur ne peut l'aveugler. Le chemin libc est la vue « perçue » qu'un outil normal (ps, ls) verrait. L'écart est une preuve sans ambiguïté d'interception de bibliothèque.

**Rootkits détectés par `[HOOK]` :**

| Rootkit | Mécanisme de dissimulation | Détecté |
|---------|-----------------|----------|
| Symbiote | LD_PRELOAD parasitaire, hook `readdir` | Oui (lorsqu'il se cache activement) |
| JynxKit | LD_PRELOAD, dissimulation par `MAGIC_GID` via `readdir` | Oui |
| Azazel | LD_PRELOAD, hooks `readdir` + `stat` | Oui |
| Medusa/OrBit | LD_PRELOAD, `readdir` + vol d'identifiants | Oui |

**Testé avec un vrai Symbiote :** Un échantillon réel de Symbiote (SHA256 `f55af21f...`, MalwareBazaar) a été déployé via `/etc/ld.so.preload` sur une VM Ubuntu 24.04. L'échantillon hooke `readdir`, `readdir64`, `stat`, `fstatat`, `pam_authenticate`, `pcap_loop`, `recvmsg`, `fopen`, `read`, `execve`. Lorsque le hook LD_PRELOAD cache activement un PID de `readdir`, SPiCa déclenche `[HOOK]` en un cycle de tick (<1 s). Lorsque Symbiote est chargé mais passif (ne se cache pas activement), SPiCa ne produit aucun faux positif.

### Fenêtre de grâce

Une fenêtre de grâce de 50 ms empêche les faux positifs sur les processus fraîchement créés (fork). Les vérifications SILENT au niveau du canal ont une période de grâce de 5 secondes (la référence `NMI_FIRST_TICK` du programme NMI) afin que la latence de démarrage ne produise pas de fausses alertes TAMPER.

---

## 6. Secret d'adresse borné par le vérificateur

### Définition

**Le secret d'adresse borné par le vérificateur** est une propriété de sécurité computationnelle qui tient dans le modèle d'adversaire contraint par eBPF. Il énonce :

> Étant donné un adversaire qui peut charger des programmes eBPF (CAP\_BPF) mais est contraint par le vérificateur BPF (boucles bornées, helpers restreints, pas d'écriture noyau arbitraire), l'adresse noyau de la section de données `.bss` d'un programme BPF est informatiquement infaisable à découvrir.

### Les quatre mécanismes

La propriété est une composition de quatre barrières indépendantes :

1. **kASLR** — La randomisation du layout de l'espace d'adressage noyau (KASLR) randomise la région du tas noyau où la mémoire des maps BPF (y compris les maps de support `.bss`) est allouée. L'adresse exacte change à chaque démarrage.

2. **Limite d'instructions du vérificateur** — Le vérificateur BPF limite le nombre total d'instructions par programme à environ 1 million et exige des boucles qui se terminent de manière prouvable. Un programme de scan d'un adversaire peut sonder au plus N ≈ 10^6 adresses par chargement via `bpf_probe_read_kernel`. Étant donné un espace de recherche randomisé par kASLR, la probabilité de succès par programme est négligeable.

3. **Passerelle d'accès aux maps LSM** (voir [§7](#7-lsm-map-access-gate)) — Sans la passerelle, un adversaire pourrait énumérer les maps BPF par ID (`BPF_MAP_GET_NEXT_ID` → `BPF_MAP_GET_FD_BY_ID` → `BPF_MAP_LOOKUP_ELEM`) et lire directement le contenu de `.bss`. La passerelle supprime ce chemin facile, forçant l'adversaire à emprunter le chemin de scan mémoire borné par le vérificateur.

4. **Placement de `.bss`** — Les variables globales `.bss` n'apparaissent pas dans les interfaces d'énumération de maps nommées avec des noms lisibles. La map de support interne `.bss` est nommée `.bss` par libbpf/aya, mais son contenu (les variables globales réelles) n'est accessible que si vous possédez le descripteur de fichier (fd) de la map. Le fd de la map nécessite soit la table des descripteurs du processus chargeur, soit l'ID de la map (bloqué par la passerelle).

### Structure de l'argument formel```
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).

Contre l'adversaire eBPF (qui ne peut pas appeler d'appels système), `.bss` est caché. Contre root en espace utilisateur, c'est une carte standard — entièrement lisible. La porte LSM comble cette lacune.

### La défense```
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 vérifie les quatre couches au démarrage et affiche leur statut.

---

## 11. L'incident du bug BTF

### Ce qui s'est passé

Lors des tests sur Ubuntu (noyau le plus récent), une incompatibilité BTF a fait que le programme du tracepoint `sched_switch` s'est attaché avec succès mais **n'a jamais déclenché un seul événement.** L'appel système `attach()` a retourné `Ok(())`, donc SPiCa a continué normalement — mais le tampon circulaire sched est resté vide. Aucune alerte de détection ne s'est déclenchée car le moteur de détection n'avait pas de données de planification. **SPiCa a fonctionné à l'aveugle sans aucune indication d'échec.**

C'est le mode d'échec le plus grave pour un outil de sécurité : la cécité silencieuse.

### Pourquoi cela n'a pas été détecté

Le moteur de détection original raisonnait **par processus** : chaque enregistrement de processus avait les horodatages `sched_last` et `nmi_last`, et la vivacité était calculée par enregistrement. Lorsque sched\_switch est mort globalement :

1. `sched_live` est passé à faux pour chaque enregistrement (pas de nouveaux événements sched → toutes les valeurs `sched_last` vieillissent)
2. Le prédicat `TAMPER` par processus (`in_proc && nmi_live && !sched_live`) pouvait se déclencher, mais nécessitait que `nmi_live` soit maintenu *en continu* pendant 2 secondes. Les échantillons NMI sont rares (période de 10M cycles), donc `suspect_since` se réinitialisait constamment à cause de la gigue d'échantillonnage et n'arrivait jamais à maturité.
3. Le prédicat `SILENT` par processus nécessitait `sched_live`, qui était maintenant faux pour tout — le prédicat s'inversait exactement dans la condition qu'il était censé détecter.
4. Il n'y avait **aucune vérification de vivacité au niveau du canal** — aucun mécanisme du type "est-ce que sched a JAMAIS été déclenché ?" ou "est-ce que max(sched_last) est obsolète ?".

De plus, une inadéquation de base de temps a été découverte : `sched_last` stockait `bpf_ktime_get_ns()` (nanosecondes de démarrage du noyau) tandis que `evaluate()` comparait avec `nanos_since_startup()` (nanosecondes locales du processus). Le `wrapping_sub` de ces bases de temps différentes produisait des valeurs énormes, rendant tous les prédicats de vivacité trivialement faux. La logique de détection n'avait jamais fonctionné correctement en production — le bug BTF l'a simplement masqué en empêchant les événements d'arriver du tout.

### Comment la refonte le corrige

| Problème | Correction |
|---|---|
| Aucune vérification de vivacité au niveau du canal | `evaluate()` calcule maintenant `max(sched_last)` et déclenche `[SILENT]` si obsolète alors que `/proc` n'est pas vide |
| TAMPER par processus n'arrivait jamais à maturité (réinitialisation par gigue) | TAMPER est maintenant un signal direct du programme NMI (comparaison du battement de cœur `.bss`), pas un FSM par processus avec des seuils |
| SILENT par processus s'inversait quand sched mourait | SILENT est maintenant au niveau du canal, calculé à partir d'agrégats, pas des prédicats par enregistrement |
| Inadéquation de base de temps | `sched_last` stocke maintenant le temps local du processus (paramètre `now`), pas `bpf_ktime_get_ns()` |
| NMI était une observation redondante | NMI est maintenant un vérificateur d'intégrité — il détecte la mort de sched directement via le battement de cœur `.bss` |

---

## 12. Limitations connues et surface d'attaque

### Dans le modèle de menace eBPF

| Attaque | Statut | Notes |
|---|---|---|
| **Manipulation du pointeur consommateur du tampon circulaire** | **Détecté** (SILENT) | `max(sched_last)` devient obsolète → SILENT. `SCHED_HEARTBEAT` continue d'avancer (le programme s'exécute) → pas de faux TAMPER. |
| **DKOM de la structure d'événement Perf** (champ `state` mis à zéro) | **Détecté** (SILENT) | NMI cesse de se déclencher → pas d'événements de battement de cœur → SILENT sur le canal NMI |
| **Usurpation de champ `task_struct`** (écraser pid/tgid) | **Partiel** (DUPE) | Si le TGID usurpé correspond à un enregistrement existant avec un `start_time_ns` différent, DUPE se déclenche. Si `start_time_ns` est également usurpé, cela passe inaperçu. |
| **Détachement du programme eBPF** (suppression du tableau funcs) | **Détecté** (TAMPER) | Le battement de cœur NMI se fige → TAMPER |
| **Correctif du bytecode sur place** | **Non détecté** | Nécessite une écriture arbitraire dans le noyau (niveau LKM) — en dehors du modèle de menace eBPF |
| **Canal auxiliaire temporel sur `bpf_probe_read_kernel`** | **Risque théorique** | Une recherche binaire sur le tas pourrait trouver `.bss` en ~30 sondes. Voir les limitations [§6](#6-verifier-bounded-address-secrecy). |

### En dehors du modèle de menace eBPF (reconnu, non résolu)

| Attaque | Statut | Notes |
|---|---|---|
| **Hameçonnage du gestionnaire IDT/NMI** | **La bombe vivante** | Contournement architectural complet. Panique noyau quasi certaine. |
| **Suppression double canal** | **La bombe vivante** | Supprimer simultanément sched + NMI. Hérite de l'instabilité du hameçonnage NMI. |
| **Exploitation du vérificateur** | **Non-objectif** | Échappe à l'exécution de code noyau arbitraire. Classe de menace distincte. |
| **ptrace / `/proc/pid/mem`** | **Limitation fondamentale** | Lecture mémoire de même privilège. Seul l'envoi de logs hors hôte aide. |
| **Pointeur consommateur + correctif du battement de cœur** | **Niveau LKM** | Si l'attaquant a une écriture arbitraire dans le noyau, il peut à la fois avancer le pointeur consommateur ET écrire de faux battements de cœur. Mais écriture arbitraire dans le noyau = niveau LKM = en dehors du modèle de menace. |

---

## 13. Construction et exécution

### Prérequis

- Linux kernel >= 5.15 avec `CONFIG_DEBUG_INFO_BTF=y` (uniquement pour le crochet LSM)
- Pour le blocage de modules : `CONFIG_BPF_LSM=y` et `lsm=bpf` dans la ligne de commande du noyau
- Puce TPM 2.0 + bibliothèque `tpm2-tss` (optionnel ; se replie avec un avertissement visible)
- Chaîne d'outils Rust nightly

> **Note :** L'étape `generate-vmlinux` n'est **plus requise**. Les programmes eBPF utilisent des décalages de tracepoint traditionnels et des globales `.bss` — aucune navigation de structure CO-RE/BTF n'est nécessaire. La commande xtask `generate-vmlinux` est conservée pour une utilisation future mais ne fait pas partie du pipeline de construction.

Vérifiez que BPF LSM est actif : `cat /sys/kernel/security/lsm` doit contenir `bpf`.

### Configuration```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)

### Installation dans initramfs (protection au démarrage précoce)```shell
sudo make install     # spica install — auto-detects Debian (initramfs-tools) or Fedora (dracut)

### Développement (macOS ou Linux)

Les programmes eBPF ne peuvent pas s'exécuter sous macOS. `cargo check` et les tests unitaires pour la logique de détection fonctionnent ; la vérification complète en environnement d'exécution nécessite 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