====== ELF-Sektion: .meta_safe ======

Die **.meta_safe** Sektion ist eine spezialisierte Datenstruktur innerhalb der ELF64-Binärdatei, die vom Lyx-Compiler (v0.9.0+) automatisch erzeugt wird, wenn eine Unit mit ''@integrity'' annotiert ist. Sie dient als vertrauenswürdige Referenz für die Hardware-Fehlertoleranz und den TMR-Abstimmungsmechanismus.

===== 1. Struktur und Layout =====

Die Sektion hat eine feste Größe von **8232 Bytes**. Sie ist so entworfen, dass die kritischen CRC32-Hashes durch physikalisches Padding (4096 Bytes, entsprechend einer typischen Memory-Page) getrennt sind, um die Auswirkungen lokaler Hardware-Defekte zu minimieren.

^ Offset (Byte) ^ Feld ^ Typ ^ Beschreibung ^
| 0..7 | ''code_start_va'' | uint64 LE | Start-Virtual-Address des geschützten Code-Segments. |
| 8..15 | ''code_end_va'' | uint64 LE | End-Virtual-Address des geschützten Code-Segments. |
| 16..19 | ''mode'' | uint32 LE | Integritätsmodus (1=lockstep, 2=scrubbed, 3=hw_ecc). |
| 20..23 | ''interval_ms'' | uint32 LE | Prüfintervall in Millisekunden. |
| 24..31 | ''recovery_ptr'' | uint64 LE | Adresse einer Recovery-Routine (0 = nicht gesetzt). |
| 32..35 | **hash_copy_1** | uint32 LE | Erster CRC32 IEEE 802.3 Hash des Codes. |
| 36..4127 | //Padding// | 4092 B | Null-Bytes zur physikalischen Trennung. |
| 4128..4131 | **hash_copy_2** | uint32 LE | Zweite, identische Kopie des Hashes. |
| 4132..8223 | //Padding// | 4092 B | Null-Bytes zur physikalischen Trennung. |
| 8224..8227 | **hash_copy_3** | uint32 LE | Dritte, identische Kopie des Hashes. |
| 8228..8231 | //Padding// | 4 B | Abschluss-Padding. |

===== 2. Triple Modular Redundancy (TMR) Effekt =====

Durch die Speicherung von drei identischen Kopien an weit auseinanderliegenden Offsets implementiert Lyx ein **statische TMR**:
  * **Erkennung**: Die Runtime berechnet den Ist-Hash des RAMs und vergleicht ihn mit allen drei Kopien.
  * **Mehrheitsentscheid**: Solange 2 der 3 Hashes in ''.meta_safe'' noch korrekt sind, kann eine Korruption im RAM oder in einer der Hash-Kopien selbst zweifelsfrei erkannt werden.

===== 3. Compiler-Workflow (Post-Patching) =====

Da der CRC32-Hash den finalen Maschinencode abbilden muss, folgt der Compiler einem speziellen Ablauf:
  - **Codegen**: Das Backend erzeugt den kompletten x86_64/ARM64 Maschinencode.
  - **Placeholder**: Die ''.meta_safe'' Sektion wird zunächst mit Platzhaltern angelegt.
  - **Calculation**: Der Compiler berechnet den CRC32 über das fertige Code-Segment.
  - **Patching**: Die drei Hash-Slots in der ELF-Datei werden NACH der Generierung mit dem echten Wert überschrieben.

===== 4. Verwendung in der Applikation =====

Die Sektion wird primär durch das Builtin ''VerifyIntegrity()'' ausgewertet:
<code lyx>
@integrity(mode: scrubbed, interval: 100)
unit;

fn check_startup() {
  if (VerifyIntegrity()) { 
    PrintStr("ELF .meta_safe verified.\n"); 
  }
}
</code>