If you’re the type of person who uses the word “vuln” as a shorthand for code vulnerabilities, you should check out the presentation from the recent linux Security Summit called “ Security in Zephyr and Fuchsia.” In the talk, two researchers from the National Security Agency discuss their contributions to the nascent security stacks of two open source OS projects: Zephyr and Fuchsia.
If you’re worried about the fact that Edward Snowden’s old employer is helping to write next generation OSes that could run our lives in 10 years, consider the upsides. First, since these are open source projects, any nefarious backdoors would be clearly visible. Second, the NSA knows a thing or two about security. Stephen Smalley and James Carter, who discussed security in Zephyr and Fuchsia, respectively, are computer security researchers at the NSA’s Information Assurance Research group , which developed and maintains the security-enhanced SELinux and SE Android distributions. Smalley leads the NSA's Security Enhancements (SE) for the Internet of Things project and is a kernel and userspace maintainer for SELinux.
The Linux Foundation hosted Zephyr Project , which is creating the IoT-oriented Zephyr RTOS, is the more mature of the two projects. Google’s Fuchsia OS has a longer way to go -- especially if you believe that Fuchsia will replace Android and Chrome OS over the next decade.
The developers of Zephyr and Fuchsia have a rare opportunity to develop novel, up-to-date security stacks from scratch. One of the main reasons Google chose to build Fuchsia from a new microkernel was that it could avoid the hodgepodge of legacy code layered on top of Linux, thereby improving security. Attempts to boost security in Linux are always going to be like patching holes in a boat. Zephyr and Fuchsia aim to be the OS equivalents of hovercraft.
Zephyr and Fuchsia are very different OSes, and they implement security in different ways. Zephyr is designed for constrained devices running on microcontrollers, such as Cortex-M4 chips, whereas Fuchsia will target phones and desktops running on applications processors, such as Cortex-A53 and Intel Core.
“Zephyr and Fuchsia were both open sourced in 2016, but they have been developed for very different use cases,” said Smalley. “Their architectures are very different, and each is also very different from Linux.”
Zephyr securityLike Linux and Fuchsia, Zephyr has RO/NX memory protection, stack depth overflow prevention, and stack buffer overflow detection. However, there’s still no kernel or user space ASLR ( address space layout randomization), which “ will likely move to a build time randomization and a small boot time relocation,” said Smalley.
Among other architectural differences with Linux, “There’s no process isolation in Zephyr, only a userspace thread model,” explained Smalley. “The process abstraction model has yet to be implemented, and the kernel/user boundary is still being fleshed out.”
In Zephyr, “you’re generally working with a single application, and security is highly dependent on particular SoCs and kernel configurations,” said Smalley. By comparison, “In Linux, there are a number of core OS security features that are neutral and independent.”
The original Zephyr release had a single executable with a single address space with all threads in supervisor mode and no memory protection or virtual memory, said Smalley. “As Zephyr added OS protections, it sought to minimize changes to kernel APIs in order to be backward compatible,” he added. “A key Zephyr design philosophy is to do as much as possible at build time, and then as much as possible at last view time, thereby minimizing runtime overheads and ensuring bounded latency for real-time.”
Zephyr security is complicated by the fact that some of the MCUs it targets include memory protection units (MPUs) while others do not. Beginning in releases 1.8 and 1.9, Zephyr began to provide memory protections, with allowances for both types of MCUs.
The NSA team developed a set of kernel memory protection tests modeled on lkdtm tests from the Kernel Self Protection Project (KSPP) for Linux. “The tests were helpful in catching bugs in Zephyr MPU drivers, and they are now used for regression testing,” said Smalley.
Zephyr added userspace support in versions 1.10 and 1.11 that provided basic support for user mode threads with isolated memory. Smalley’s team developed a set of userspace tests “that sought to validate the security properties for user mode threads were being enforced.” Zephyr’s userspace memory model is still limited to a single executable and address space, and there’s no virtual memory. “It can support user mode threads but not full processes,” explained Smalley.
Sign up to receive updates on Open Source Summit and ELC+OpenIoT Europe:
Zephyr security features include an object permissions model in which user threads must first be granted permissions to an object to enable access. “A kernel mode thread can grant access to a user mode thread, and an inheritance mechanism allows those permissions to be propagated down,” explained Smalley. “It’s an all or nothing model -- all user threads can access all app global variables.”
This all-or-nothing approach “poses a high burden on the application developer, who has to manually organize the application global variable memory layout to meet MPU restrictions,” said Smalley. To help compensate, the NSA team developed a feature due in release 1.13 that “supports a slightly more developer friendly way of grouping application globals based on desired protections. It’s a small step forward, not a panacea.”
Future Zephyr security work includes adding MPU virtualization, which “would allow us to support a larger number of regions instead of just eight that can be swapped in and out of the MPU on demand,” said Smalley. “We also hope to provide full support for multiple applications and program loading.”
In Zephyr, kernel code is fully trusted. “We would like to see Linux-like mitigations for kernel vulns using KSPP kernel self-protection features while minimizing runtime overheads,” said Smalley. Other wish-list items include leveraging armv8-m for Cortex-M MCUs, thereby enabling TrustZone security. There’s also a long-term plan to “develop a MAC suited to RTOSes that’s more oriented to build-time app partitioning.”
Fuchsia security Fuchsia differs from Linux and Zephyr in that it’s a microkernel OS with security based on object capability