One think has really struck me in most pictures of #RTOS designs that I’ve seen recently: they all have a HAL or device driver layer at the bottom. The bottom layer is your trusted computing base (TCB): the bits that have to be correct for any of your security guarantees to hold. But device drivers talk to the outside world. Ethernet, SPI, I2C, UARTs, and so on are all parts of your attack surface: the place where an attacker is most likely to start attacking your system.

By combining your external attack surface with your TCB, you guarantee that an attacker who mounts a successful exploit has complete control over the system.

This is why #CHERIoT RTOS makes it trivial to delegate devices to the least-trusted portion of a firmware image. A compartment with exclusive access to a device doesn’t get any privileges other than a CHERI capability (hardware-enforced pointer) authorising access to that device’s MMIO region. If an attacker compromises it, they get access to that device, and maybe a way of trying to attack the next compartment, but it’s just the first step towards device compromise, not the end. Device drivers for single-user devices are just a software engineering abstraction, not a security boundary: they let you avoid thinking about device-specific details. Device drivers that handle multiplexing have no special privileges other than access to the device. At worst, compromising one allows you to break the isolation that the multiplexing provided.