प्रत्येक पहचान वर्ग एक अंतर निर्णय है: दो या अधिक चैनलों के बीच विसंगति। पहचान इंजन रजिस्ट्री + /proc स्नैपशॉट + चैनल टाइमस्टैम्प पर एक शुद्ध फ़ंक्शन है — कोई I/O नहीं, कोई दुष्प्रभाव नहीं, पूरी तरह से यूनिट-परीक्षण योग्य।

### The NMI redesign: from observation to integrity

मूल डिज़ाइन में, NMI एक दूसरा प्रक्रिया-अवलोकन चैनल था जो CPU का नमूना लेता था और रिपोर्ट करता था कि कौन सा कार्य चल रहा है। यह अनावश्यक था: sched\_switch पहले से ही शेड्यूलिंग का अवलोकन करता है, और NMI एक अलग तंत्र के माध्यम से समान डेटा का नमूना लेता था। अनावश्यकता की लागत ~1000+ रिंग-बफ़र ईवेंट/सेकंड/CPU प्रक्रिया डेटा की थी जो 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-array हेरफेर से प्रतिरक्षित
4. `.bss` ग्लोबल्स को BPF हेल्पर्स के बजाय प्रत्यक्ष मेमोरी एक्सेस के माध्यम से पढ़ता है — हेल्पर फ़ंक्शंस पर `fmod_ret` से प्रतिरक्षित

---

## 3. The sched\_switch Observation Channel

`sched_switch` ट्रेसपॉइंट से जुड़ा एक eBPF प्रोग्राम हर बार फायर करता है जब कर्नेल CPU पर एक प्रक्रिया शेड्यूल करता है। यह पारंपरिक (गैर-BTF) निश्चित-ऑफ़सेट रीड का उपयोग करके ट्रेसपॉइंट तर्कों से सीधे आने वाले कार्य के PID और comm को पढ़ता है:```
ctx.read_at::<u32>(56)    → next_pid
ctx.read_at::<[u8;16]>(40) → next_comm

### यह दायरे में हर हमले का पता क्यों लगाता है

| हमला | क्या होता है | NMI क्या देखता है |
|---|---|---|
| फंक्स ऐरे से ट्रेसपॉइंट अलग किया गया | 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 संदर्भ में चलता है, जहाँ kprobes संरचनात्मक रूप से अविश्वसनीय होते हैं (कर्नेल उन्हें स्थगित या दबा देता है)। जाँचकर्ता के निष्पादन के खिलाफ kprobe-आधारित हमला हार्डवेयर से लड़ता है।

### NMI इवेंट अर्थशास्त्र

NMI रिंग बफ़र (`sc_nmi`) हल्के इवेंट ले जाता है:

| `event_type` | अर्थ | यूज़रस्पेस कार्रवाई |
|---|---|---|
| 0 | हार्टबीट — NMI जीवित, sched\_switch जीवित | `last_nmi_heartbeat` टाइमस्टैम्प अपडेट करें |
| 1 | TAMPER — NMI जीवित, sched\_switch हार्टबीट फ्रीज़ | तुरंत `[TAMPER]` प्रिंट करें |

इवेंट अधिकतम एक बार प्रति सेकंड उत्सर्जित होते हैं (`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;

This technique 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 के विरुद्ध परीक्षण:** Ubuntu 24.04 VM पर `/etc/ld.so.preload` के माध्यम से एक लाइव Symbiote नमूना (SHA256 `f55af21f...`, MalwareBazaar) तैनात किया गया था। यह नमूना `readdir`, `readdir64`, `stat`, `fstatat`, `pam_authenticate`, `pcap_loop`, `recvmsg`, `fopen`, `read`, `execve` को हुक करता है। जब LD_PRELOAD हुक सक्रिय रूप से `readdir` से एक PID छिपाता है, SPiCa एक टिक चक्र (<1 s) के भीतर `[HOOK]` फायर करता है। जब Symbiote लोड होता है लेकिन निष्क्रिय है (सक्रिय रूप से नहीं छिपा रहा है), SPiCa शून्य गलत सकारात्मक उत्पन्न करता है।

### Grace विंडो

एक 50 ms की Grace विंडो ताज़ा-forked प्रक्रियाओं पर गलत सकारात्मक को रोकती है। चैनल-स्तरीय SILENT जाँचों में 5 सेकंड की Grace अवधि होती है (NMI प्रोग्राम के `NMI_FIRST_TICK` संदर्भ) ताकि स्टार्टअप विलंबता गलत TAMPER अलर्ट उत्पन्न न करे।

---

## 6. सत्यापनकर्ता-सीमित पता गोपनीयता

### परिभाषा

**सत्यापनकर्ता-सीमित पता गोपनीयता** एक कम्प्यूटेशनल सुरक्षा गुण है जो eBPF-प्रतिबंधित विरोधी मॉडल के अंतर्गत मान्य है। यह बताता है:

> ऐसे विरोधी को देखते हुए जो eBPF प्रोग्राम लोड कर सकता है (CAP\_BPF) लेकिन BPF सत्यापनकर्ता द्वारा प्रतिबंधित है (सीमित लूप, प्रतिबंधित सहायक, कोई मनमाना कर्नेल लेखन नहीं), BPF प्रोग्राम के `.bss` डेटा अनुभाग का कर्नेल पता कम्प्यूटेशनल रूप से खोजना अव्यावहारिक है।

### चार तंत्र

यह गुण चार स्वतंत्र अवरोधों का एक संयोजन है:

1. **kASLR** — कर्नेल एड्रेस स्पेस लेआउट रैंडमाइज़ेशन कर्नेल हीप क्षेत्र को यादृच्छिक करता है जहाँ BPF मैप मेमोरी (जिसमें `.bss` बैकिंग मैप शामिल हैं) आवंटित की जाती है। सटीक पता हर बूट पर बदलता है।

2. **सत्यापनकर्ता निर्देश सीमा** — BPF सत्यापनकर्ता प्रति प्रोग्राम कुल निर्देशों को ~1 मिलियन तक सीमित करता है और आवश्यकता है कि लूप सिद्ध रूप से समाप्त हों। एक विरोधी का स्कैनिंग प्रोग्राम `bpf_probe_read_kernel` के माध्यम से प्रति लोड अधिकतम N ≈ 10^6 पतों की जांच कर सकता है। kASLR-यादृच्छिक खोज स्थान दिया गया, प्रति-प्रोग्राम सफलता संभावना नगण्य है।

3. **LSM मैप-एक्सेस गेट** (देखें [§7](#7-lsm-map-access-gate)) — गेट के बिना, एक विरोधी BPF मैप्स को ID द्वारा गणना कर सकता है (`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).

eBPF विरोधी (जो सिस्टम कॉल नहीं कर सकता) के विरुद्ध, `.bss` छिपा हुआ है। यूज़रस्पेस रूट के विरुद्ध, यह एक मानक मैप है — पूरी तरह से पढ़ने योग्य। LSM गेट इस अंतर को बंद करता है।

### रक्षा

`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 स्टार्टअप पर सभी चार परतों की जाँच करता है और उनकी स्थिति प्रिंट करता है।

---

## 11. BTF बग घटना

### क्या हुआ

Ubuntu (नवीनतम कर्नेल) पर परीक्षण के दौरान, एक BTF असंगति के कारण `sched_switch` ट्रेसपॉइंट प्रोग्राम सफलतापूर्वक अटैच हो गया लेकिन **एक भी इवेंट फायर नहीं हुआ।** `attach()` सिस्कॉल ने `Ok(())` लौटाया, इसलिए SPiCa सामान्य रूप से आगे बढ़ा — लेकिन sched रिंग बफ़र खाली रहा। कोई डिटेक्शन अलर्ट फायर नहीं हुआ क्योंकि डिटेक्शन इंजन के पास शेड्यूलिंग डेटा नहीं था। **SPiCa विफलता के किसी भी संकेत के बिना अंधा हो गया।**

यह एक सुरक्षा टूल के लिए सबसे खराब विफलता मोड है: मूक अंधापन।

### यह क्यों नहीं पता चला

मूल डिटेक्शन इंजन **प्रति-प्रक्रिया** तर्क करता था: प्रत्येक प्रक्रिया रिकॉर्ड में `sched_last` और `nmi_last` टाइमस्टैम्प होते थे, और जीवंतता प्रति-रिकॉर्ड गणना की जाती थी। जब sched\_switch वैश्विक रूप से मर गया:

1. `sched_live` प्रत्येक रिकॉर्ड के लिए गलत हो गया (कोई नया sched इवेंट नहीं → सभी `sched_last` मान समय समाप्त हो गए)
2. प्रति-प्रक्रिया `TAMPER` विधेय (`in_proc && nmi_live && !sched_live`) फायर हो सकता था, लेकिन इसके लिए `nmi_live` को *लगातार* 2 सेकंड तक रखना आवश्यक था। NMI विरल रूप से नमूना लेता है (10M साइकिल अवधि), इसलिए `suspect_since` नमूना जिटर पर रीसेट होता रहा और कभी परिपक्व नहीं हुआ।
3. प्रति-प्रक्रिया `SILENT` विधेय के लिए `sched_live` आवश्यक था, जो अब सबके लिए गलत था — विधेय ठीक उसी स्थिति में उलट गया जिसका पता लगाने के लिए इसे डिज़ाइन किया गया था।
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` अब प्रक्रिया-स्थानीय समय (`now` पैरामीटर) संग्रहीत करता है, `bpf_ktime_get_ns()` नहीं |
| 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 हुक के लिए)
- मॉड्यूल ब्लॉकिंग के लिए: कर्नेल cmdline में `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