Cada clase de detección es un veredicto diferencial: una discrepancia entre dos o más canales. El motor de detección es una función pura sobre el registro + la instantánea de /proc + las marcas de tiempo de los canales — sin E/S, sin efectos secundarios, totalmente comprobable mediante pruebas unitarias.

### El rediseño del NMI: de la observación a la integridad

En el diseño original, NMI era un segundo canal de observación de procesos que muestreaba la CPU e informaba qué tarea se estaba ejecutando. Esto era redundante: sched\_switch ya observa la planificación, y NMI muestreaba los mismos datos mediante un mecanismo diferente. La redundancia costaba ~1000+ eventos ring-buffer/segundo/CPU de datos de proceso que el 99.999% del tiempo confirmaban "sí, el planificador está haciendo lo que hace el planificador".

En la arquitectura rediseñada, **NMI se reutiliza de la observación de procesos a la verificación de integridad de los tracepoints.** Ya no informa qué proceso está en la CPU. En su lugar, verifica que `sched_switch` se esté ejecutando realmente leyendo un heartbeat compartido en `.bss`. Esto:

1. Elimina ~99% del tráfico del ring-buffer del NMI (eventos de estado estacionario casi nulos)
2. Detecta directamente desconexión de tracepoints, supresión y fallos de BTF/attach (el error original de BTF — ver [§11](#11-the-btf-bug-incident))
3. Se ejecuta desde una interrupción de hardware, fuera de la ruta de despacho de tracepoints — inmune a `bpf_override_return`, interceptación de kprobes y manipulación de arrays de funciones
4. Lee variables globales de `.bss` mediante acceso directo a memoria, no helpers de BPF — inmune a `fmod_ret` en funciones helper

---

## 3. El canal de observación de sched\_switch

Un programa eBPF adjunto al tracepoint `sched_switch` se dispara cada vez que el kernel planifica un proceso en una CPU. Lee el PID y el comm de la tarea entrante directamente de los argumentos del tracepoint utilizando lecturas tradicionales de desplazamiento fijo (no BTF):```
ctx.read_at::<u32>(56)    → next_pid
ctx.read_at::<[u8;16]>(40) → next_comm

### Por qué esto detecta todos los ataques en el ámbito

| Ataque | Qué sucede | Qué ve el NMI |
|---|---|---|
| Tracepoint desvinculado del array de funciones | sched\_switch deja de ejecutarse | `SCHED_HEARTBEAT` se congela → TAMPER |
| Error de BTF / fallo de attach (silencioso) | sched\_switch nunca se ejecuta | `SCHED_HEARTBEAT` permanece en 0 → TAMPER (después del período de gracia) |
| `bpf_override_return` en una función del planificador | Si evita que el tracepoint se active | `SCHED_HEARTBEAT` se congela → TAMPER |
| Bytecode parcheado in situ | Requiere escritura arbitraria del kernel (a nivel de LKM) | Fuera del modelo de amenazas de eBPF |
| Puntero de consumidor del ring buffer manipulado | Los eventos de sched no llegan al espacio de usuario | `SCHED_HEARTBEAT` sigue avanzando (el programa se ejecuta) → no hay falso TAMPER; el espacio de usuario detecta mediante `max(sched_last)` obsoleto → SILENT |

### Por qué `.bss` específicamente

Las globales `.bss` se almacenan en la sección de datos interna del programa BPF, respaldadas por un mapa de array interno que el cargador gestiona. Son:

- **No se pueden anclar por separado** — no aparecen como mapas con nombre en `/sys/fs/bpf/`
- **No interceptables mediante hooks de `bpf_map_update_elem`** — las escrituras en `.bss` son almacenamientos directos en memoria, no llamadas al sistema de actualización de mapas. El antiguo mecanismo `sc_canary` (que comparaba una copia de `.bss` con una copia de un mapa con nombre para detectar la intercepción de `bpf_map_update_elem`) ya no es necesario.
- **Compartidas entre programas en el mismo objeto ELF** — sched\_switch y NMI se comunican a través de `.bss` sin ninguna interfaz externa

### Inmunidad a la intercepción basada en BPF

El verificador de integridad NMI es estructuralmente inmune a los ataques de anulación de BPF debido a una propiedad fundamental: `bpf_override_return` intercepta **llamadas** a funciones, pero el verificador NMI no *llama* a las cosas que verifica — *lee directamente la memoria `.bss`*. No se puede anular el valor de retorno de una lectura de memoria porque una lectura de memoria no es una llamada a función.

Además:
- `bpf_probe_read_kernel` (usado para lecturas de estructuras del kernel en diseños alternativos) es un auxiliar seguro contra fallos que acepta cualquier dirección — pero el diseño de latido `.bss` de SPiCa ni siquiera lo necesita. El verificador lee las globales `.bss` mediante instrucciones de carga directa.
- El programa NMI se ejecuta en contexto NMI, donde las kprobes son estructuralmente poco fiables (el kernel las aplaza o las suprime). Un ataque basado en kprobes contra la ejecución del verificador lucha contra el hardware.

### Semántica de eventos NMI

El ring buffer NMI (`sc_nmi`) transporta eventos ligeros:

| `event_type` | Significado | Acción del espacio de usuario |
|---|---|---|
| 0 | Latido — NMI vivo, sched\_switch vivo | Actualizar la marca de tiempo `last_nmi_heartbeat` |
| 1 | TAMPER — NMI vivo, latido de sched\_switch congelado | Imprimir `[TAMPER]` inmediatamente |

Los eventos se emiten como máximo una vez por segundo (limitados por `NMI_LAST_EMIT`). Si el ring buffer NMI queda en silencio durante más de 5 segundos, el espacio de usuario dispara `[SILENT]` — el canal NMI en sí está muerto.

---

## 5. Lógica de Detección```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;

This technique turns SPiCa's kernel-level privilege into an active detection of userspace rootkits. The raw syscall path is the ground truth — no userspace hook can blind it. The libc path is the "perceived" view that a normal tool (ps, ls) would see. The discrepancy is unambiguous proof of library interception.

**Rootkits detected by `[HOOK]`:**

| Rootkit | Mecanismo de ocultación | Detectado |
|---------|-------------------------|-----------|
| Symbiote | Parasitic LD_PRELOAD, hooks `readdir` | Sí (cuando se oculta activamente) |
| JynxKit | LD_PRELOAD, `MAGIC_GID` hiding via `readdir` | Sí |
| Azazel | LD_PRELOAD, `readdir` + `stat` hooks | Sí |
| Medusa/OrBit | LD_PRELOAD, `readdir` + credential theft | Sí |

**Probado contra Symbiote real:** Una muestra viva de Symbiote (SHA256 `f55af21f...`, MalwareBazaar) fue desplegada mediante `/etc/ld.so.preload` en una VM Ubuntu 24.04. La muestra engancha `readdir`, `readdir64`, `stat`, `fstatat`, `pam_authenticate`, `pcap_loop`, `recvmsg`, `fopen`, `read`, `execve`. Cuando el hook LD_PRELOAD oculta activamente un PID de `readdir`, SPiCa dispara `[HOOK]` en un ciclo de tick (<1 s). Cuando Symbiote está cargado pero pasivo (sin ocultar activamente), SPiCa produce cero falsos positivos.

### Ventana de gracia

Una ventana de gracia de 50 ms evita falsos positivos en procesos recién bifurcados. Las comprobaciones SILENT a nivel de canal tienen un período de gracia de 5 segundos (la referencia `NMI_FIRST_TICK` del programa NMI) para que la latencia de inicio no produzca alertas TAMPER falsas.

---

## 6. Secreto de Dirección Limitado por el Verificador

### Definición

**Secreto de dirección limitado por el verificador** es una propiedad de seguridad computacional que se cumple bajo el modelo de adversario restringido por eBPF. Establece que:

> Dado un adversario que puede cargar programas eBPF (CAP\_BPF) pero está restringido por el verificador BPF (bucles acotados, helpers limitados, sin escritura arbitraria en el kernel), la dirección del kernel de la sección de datos `.bss` de un programa BPF es computacionalmente inviable de descubrir.

### Los cuatro mecanismos

La propiedad es una composición de cuatro barreras independientes:

1. **kASLR** — La aleatorización del diseño del espacio de direcciones del kernel aleatoriza la región del heap del kernel donde se asigna la memoria de los mapas BPF (incluyendo los mapas de respaldo de `.bss`). La dirección exacta cambia en cada arranque.

2. **Límite de instrucciones del verificador** — El verificador BPF limita las instrucciones totales por programa a ~1 millón y requiere bucles que terminan demostrablemente. Un programa de escaneo del adversario puede sondear como máximo N ≈ 10^6 direcciones por carga mediante `bpf_probe_read_kernel`. Dado un espacio de búsqueda aleatorizado por kASLR, la probabilidad de éxito por programa es insignificante.

3. **Puerta de acceso a mapas LSM** (ver [§7](#7-lsm-map-access-gate)) — Sin la puerta, un adversario podría enumerar los mapas BPF por ID (`BPF_MAP_GET_NEXT_ID` → `BPF_MAP_GET_FD_BY_ID` → `BPF_MAP_LOOKUP_ELEM`) y leer el contenido de `.bss` directamente. La puerta elimina este camino fácil, forzando al adversario a la ruta de escaneo de memoria limitada por el verificador.

4. **Ubicación de `.bss`** — Las variables globales de `.bss` no aparecen en las interfaces de enumeración de mapas con nombres. El mapa de respaldo interno de `.bss` se llama `.bss` por libbpf/aya, pero su contenido (las variables globales reales) solo es accesible si se tiene el fd del mapa. El fd del mapa requiere o la tabla de fds del proceso cargador o el ID del mapa (bloqueado por la puerta).

### Estructura del argumento formal```
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).

Contra el adversario eBPF (que no puede llamar syscalls), `.bss` está oculto. Contra el root de userspace, es un mapa estándar — completamente legible. El gate LSM cierra esta brecha.

### La defensa

Un hook LSM de BPF en el syscall `bpf` verifica los comandos de acceso a mapas:```
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 verifica las cuatro capas al inicio e imprime su estado.

---

## 11. El incidente del error BTF

### Lo que sucedió

Durante las pruebas en Ubuntu (kernel más reciente), una incompatibilidad BTF provocó que el programa de tracepoint `sched_switch` se adjuntara correctamente pero **nunca disparara un solo evento.** La llamada al sistema `attach()` devolvió `Ok(())`, por lo que SPiCa continuó normalmente — pero el búfer de anillo sched permaneció vacío. No se dispararon alertas de detección porque el motor de detección no tenía datos de planificación. **SPiCa funcionó a ciegas sin ninguna indicación de fallo.**

Este es el peor modo de fallo para una herramienta de seguridad: ceguera silenciosa.

### Por qué no se detectó

El motor de detección original razonaba **por proceso**: cada registro de proceso tenía marcas de tiempo `sched_last` y `nmi_last`, y la vivacidad se calculaba por registro. Cuando sched\_switch falló globalmente:

1. `sched_live` se volvió falso para cada registro (sin nuevos eventos sched → todos los valores `sched_last` envejecen)
2. El predicado `TAMPER` por proceso (`in_proc && nmi_live && !sched_live`) podía dispararse, pero requería que `nmi_live` se mantuviera *continuamente* durante 2 segundos. El NMI muestrea de forma dispersa (período de 10M ciclos), por lo que `suspect_since` se reiniciaba constantemente debido a la fluctuación del muestreo y nunca maduraba.
3. El predicado `SILENT` por proceso requería `sched_live`, que ahora era falso para todo — el predicado se invertía exactamente bajo la condición que debía detectar.
4. No había **verificación de vivacidad a nivel de canal** — ningún mecanismo "¿ha disparado sched ALGUNA VEZ?" o "¿está obsoleto max(sched_last)?".

Además, se descubrió una falta de coincidencia en la base de tiempo: `sched_last` almacenaba `bpf_ktime_get_ns()` (nanosegundos de arranque del kernel) mientras que `evaluate()` comparaba con `nanos_since_startup()` (nanosegundos locales del proceso). La `wrapping_sub` de estas diferentes bases de tiempo producía valores enormes, haciendo que todos los predicados de vivacidad fueran trivialmente falsos. La lógica de detección nunca había funcionado correctamente en producción — el error BTF simplemente lo enmascaró al evitar que los eventos llegaran en absoluto.

### Cómo el rediseño lo soluciona

| Problema | Solución |
|---|---|
| Sin verificación de vivacidad a nivel de canal | `evaluate()` ahora calcula `max(sched_last)` y dispara `[SILENT]` si está obsoleto mientras `/proc` no está vacío |
| TAMPER por proceso nunca maduraba (reinicio por fluctuación) | TAMPER ahora es una señal directa del programa NMI (comparación de heartbeat `.bss`), no una FSM por proceso con umbrales |
| SILENT por proceso se invertía cuando sched fallaba | SILENT ahora es a nivel de canal, calculado a partir de agregados, no predicados por registro |
| Desajuste de base de tiempo | `sched_last` ahora almacena tiempo local del proceso (parámetro `now`), no `bpf_ktime_get_ns()` |
| NMI era una observación redundante | NMI ahora es un verificador de integridad — detecta la muerte de sched directamente a través del heartbeat `.bss` |

---

## 12. Limitaciones conocidas y superficie de ataque

### Dentro del modelo de amenazas eBPF

| Ataque | Estado | Notas |
|---|---|---|
| **Manipulación del puntero consumidor del búfer de anillo** | **Detectado** (SILENT) | `max(sched_last)` se vuelve obsoleto → SILENT. `SCHED_HEARTBEAT` aún avanza (el programa se ejecuta) → no hay falso TAMPER. |
| **DKOM de la estructura de evento Perf** (campo `state` en cero) | **Detectado** (SILENT) | NMI deja de disparar → sin eventos de heartbeat → SILENT en el canal NMI |
| **Suplantación de campo `task_struct`** (sobrescribir pid/tgid) | **Parcial** (DUPE) | Si el TGID suplantado coincide con un registro existente con un `start_time_ns` diferente, DUPE se dispara. Si `start_time_ns` también es suplantado, esto pasa desapercibido. |
| **Desvinculación de programa eBPF** (eliminar del array funcs) | **Detectado** (TAMPER) | El heartbeat de NMI se congela → TAMPER |
| **Bytecode parcheado in situ** | **No detectado** | Requiere escritura arbitraria del kernel (nivel LKM) — fuera del modelo de amenazas eBPF |
| **Canal lateral de temporización en `bpf_probe_read_kernel`** | **Riesgo teórico** | La búsqueda binaria en el heap podría encontrar `.bss` en ~30 sondas. Ver limitaciones en [§6](#6-verifier-bounded-address-secrecy). |

### Fuera del modelo de amenazas eBPF (reconocido, no resuelto)

| Ataque | Estado | Notas |
|---|---|---|
| **Hook del manejador IDT/NMI** | **La bomba activa** | Bypass arquitectónicamente completo. Pánico de kernel casi seguro. |
| **Supresión de doble canal** | **La bomba activa** | Suprime simultáneamente sched + NMI. Hereda la inestabilidad del hooking de NMI. |
| **Exploit del verificador** | **No objetivo** | Escapa a ejecución de código arbitrario del kernel. Clase de amenaza separada. |
| **ptrace / `/proc/pid/mem`** | **Limitación fundamental** | Lectura de memoria con el mismo privilegio. Solo ayuda el envío de registros fuera del host. |
| **Parche de puntero consumidor + heartbeat** | **Nivel LKM** | Si el atacante tiene escritura arbitraria del kernel, puede avanzar el puntero consumidor Y escribir heartbeats falsos. Pero escritura arbitraria del kernel = nivel LKM = fuera del modelo de amenazas. |

---

## 13. Construcción y ejecución

### Prerrequisitos

- Kernel Linux >= 5.15 con `CONFIG_DEBUG_INFO_BTF=y` (solo para el hook LSM)
- Para bloqueo de módulos: `CONFIG_BPF_LSM=y` y `lsm=bpf` en la línea de comandos del kernel
- Chip TPM 2.0 + biblioteca `tpm2-tss` (opcional; retrocede con advertencia visible)
- Cadena de herramientas Rust nightly

> **Nota:** El paso `generate-vmlinux` **ya no es necesario**. Los programas eBPF utilizan offsets de tracepoint tradicionales y variables globales `.bss` — no se necesita navegación de estructuras CO-RE/BTF. El comando xtask `generate-vmlinux` se conserva para uso futuro pero no forma parte del pipeline de construcción.

Verificar que BPF LSM esté activo: `cat /sys/kernel/security/lsm` debe contener `bpf`.

### Configuración```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)

### Instalar en initramfs (protección de arranque temprano)```shell
sudo make install     # spica install — auto-detects Debian (initramfs-tools) or Fedora (dracut)

### Desarrollo (macOS o Linux)

Los programas eBPF no pueden ejecutarse en macOS. `cargo check` y las pruebas unitarias para la lógica de detección funcionan; la verificación completa en tiempo de ejecución requiere 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