Cheri RTOS

CHERI-aware real-time operating system, CheriRTOS.

  • Fine-grained memory protection
  • Secure centralized heap management;
  • Dynamic task loading;
  • Low-latency and direct domain crossing;
  • Distributed trusted stacks to protect return contexts;
  • Secure peripherals.

Current limitations

MPU limitation

  • MPU is a kernel space device, each register takes multiple cycles to configure;
    • usually configured only globally at system start-up, which makes per-task memory access control difficult;
    • user space cannot leverage it for intra-task protection;
  • MPU entries are limited. Fine grained memory protection is impractical;
  • MPU lookups involve associative searches of all entries.
    • Assuming 8 MPU entries, accounting for both instruction fetch and data, EACH CYCLE can potentially require up to 32 comparisons.????
    • Inefficient in terms of power and die area.

TrustZone limitation

Secure and non-secure worlds; constrained control-flow; A certain degree of CFI, which avoids ROP attacks.

  • Non-secure code can jump only to valid entry points on the secure side, and secure code calls non-secure functions after clearing registers and pushing the return address on the secure stack.

Limitations:

  • scalability issues: further isolation within a world is not possible. Separating the entire system into only two worlds may not be a wise design choice.

EA-MPU

Execution-Aware MPU: links data and code entries to distinguish between different tasks; control memory access on a per-task basis.

Built in TrustLite1 and TyTan2.

Limitations:

  • Inheris MPU flaws: restricted number of simultaneous tasks; restricted inter-task memory sharing.

CFI and ROP defense approaches

  • In 3 4, they use dedicated instructions for function calls, exposing only valid entry points, hiding return addresses in protected spaces, etc.
  • Sanctus 5 6 builds tasks into Self-Protecting Modules (SPMs) to restrict access and enforce control flow.
    • sacrifices software flexibility
    • incurs high hardware cost by implementing SPM loading, measurement, and runtime identification in the trusted CPU.

PL level for embeded devices

nesCheck7 modifies the language and compiler to perform stronger type safety, static analysis, and run-time checks.

SafeCode8 develops new compiler frameworks to address stack, array, and pointer safety, and implement new heap allocation techniques.


  1. TrustLite: A Security Architecture for Tiny Embedded Devices, EuroSys, 2014. New York, NY, USA. ↩
  2. TyTAN: Tiny trust anchor for tiny devices. DAC, 2015. ↩
  3. HAFIX: Hardware-Assisted Flow Integrity eXtension. DAC, 2015. ↩
  4. Hardware-assisted fine-grained control-flow integrity: Towards efficient protection of embedded systems against software exploitation. DAC, 2014. ↩
  5. Sancus: Low-cost Trustworthy Extensible Networked Devices with a Zerosoftware Trusted Computing Base. USENIX Security, 2013. ↩
  6. Efficient Isolation of Trusted Subsystems in Embedded Systems. SPCN, 2010. ↩
  7. nesCheck, Asia CCS, 2017; ↩
  8. SafeCode, ACM Transactions on Embedded Computing Systems (TECS), 2005; ↩
Created Sep 14, 2019 // Last Updated Oct 28, 2019

If you could revise
the fundmental principles of
computer system design
to improve security...

... what would you change?