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). 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).

  • 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