Security model
The current security model combines a secure-boot prototype, Harvard separation, IMEM-loader locking, W^X checks in the ELF loader, MMU/MPU checks and a bounded DMA/IOMMU window.
Implemented protection mechanisms
| Mechanism | Effect | Limit |
|---|---|---|
| Secure boot | Compares expected hash/key/signature values and releases boot_ok. | Prototype values in RTL; no final production key lifecycle. |
| IMEM lock | Disables the write path into instruction memory after ELF load. | Lock lasts until reset; multiboot or hot patching requires a new protocol. |
| W^X | Boot ROM rejects ELF segments with both PF_W and PF_X. | No per-ELF signature verification in the current boot ROM. |
| MMU/MPU | Fetch and data accesses are separated and checked against PTE flags and fixed regions. | Full multi-process isolation needs a supervisor with managed page tables. |
| DMA IOMMU | USB/HNET DMA is restricted to a small bounce window. | Production systems should use per-device rings and rights. |
| YAML paths | Boot ROM requires matching YAML and data directories for each ELF. | YAML itself is not yet cryptographically authenticated. |
Recommended hardening
- Add an ELF manifest with SHA-256/signature for each file.
- Include YAML configuration in the same signed manifest.
- Run the program image read-only or through a verified file system.
- Give the data image per-application rights, quotas and journaling.
- Load a supervisor/microkernel first and start services as user tasks.
- Use per-task MMU page tables: code RX, data RW, guard pages and no W^X mappings.
- Add watchdog recovery, crash logs and a documented recovery boot path.
- Validate the network stack against malformed frames, SYN floods and oversized headers.
Boot ROM versus supervisor
The boot ROM should initialize, validate, load and transfer control. Long-running services, file systems, scheduling and device policy belong in a supervisor or microkernel layer. That layer can isolate HarvTTP, HarvSQL and future services behind MMU, capability and device policies.
Recovery mode
A robust recovery mode should trigger on signature failure, missing program or data image, ELF validation errors and watchdog reset. Useful recovery tools include a small serial console, a read-only recovery image and, when safe enough, a minimal debug web page.