# Safety, Security, and Compliance Certifications

> **The criterion.** For industrial, medical, automotive, or aerospace use: functional-safety certification
> (ISO 26262 / IEC 61508 / DO-178C), and code provenance (MISRA-C, no dynamic allocation in critical paths,
> verifiable execution bounds).

## How Revera answers it — honestly

**Revera 0.1.0 carries no functional-safety certification, and no cryptography or verified boot in the
shipped tree.** What it *does* bring to a safety/security effort — genuinely, in root, today:

- **Hardware-enforced isolation** — the differentiator: per-thread and per-island memory fencing that binds
  even the kernel (see [Memory Protection & Isolation](memory-protection-isolation.md)). This is the
  foundation freedom-from-interference arguments are built on.
- **No dynamic allocation** in any path — static pools + caller-provided stacks (see
  [Memory footprint](memory-footprint.md)).
- **A strict, reproducible build** — the whole tree compiles clean under `-std=c99 -pedantic-errors -Wall
  -Wextra -Werror`; impossible configurations fail loud at compile time.
- **A test harness** — host unit suites + live-kernel QEMU arch suites (`make test` / `test-arch`), the
  starting point for a verification argument.
- **Fault observability** — a DET hook (`tk_det_set_hook`) plus the trace ring and post-mortem decode.

These are **certification-friendly foundations, not a certification**. There is no safety case, no tool
qualification, no MISRA compliance report in 0.1.0.

## Available from the project's history (roadmap / on request — not in 0.1.0)

A substantial security & safety plane was implemented and **hardware-verified on nRF52** before the reshape,
and is port-forward-ready:

| Area | What was built (HW-proven in history) |
|---|---|
| **Cryptography** | SHA-256 (+ portable software impl) · HMAC-SHA256 · AES-128 ECB + CBC · ECDSA P-256 verify-only · TRNG/RNG · CRC-16/CCITT |
| **Verified / secure boot** | Symmetric HMAC (A1), asymmetric ECDSA-P256 verify (A2), two-stage bootloader (A2c), and the nRF52 APPROTECT debug-lockout hardware anchor (A3) — each HW-verified on the PCA10040. Host-side signing tools (`tk_vboot_sign*.py`). |
| **Safety drivers** | Mode-based watchdog MCAL (warn callback) · brownout / voltage detection · reset-reason reporting · validated persistence (`tk_persist`, magic + CRC-16 + length) · cross-core software heartbeat · a full error/DET reporting subsystem (per-module counters, 28 module IDs). |

Honest caveat carried from the design notes: a *software* verified-boot whose key lives in the same rewritable
flash is "a teaching device, not a real boundary" — a production root of trust needs an immutable boot ROM +
eFuse key.

## Learn more

- **The staged plan:** [safety-and-security.md](../safety-and-security.md) (the reconciled index that tiers
  every crypto / verified-boot / safety item as landed vs staged) · [roadmap](../roadmap.md).
- **The isolation foundation:** [Memory Protection & Isolation](memory-protection-isolation.md) ·
  [security/safety API](../architecture/security-safety-api.md).