As an embedded real-time software engineer, has the rapidly increasing penetration of multicore processors into systems design raised concerns? Does it worry you that the essence of real-time control has become lost in the rush to get access to more processing power or to decrease SWaP (size, weight and power)?
We’re continuously asked to consolidate ever more applications and services with mixed levels of overall system criticality onto multicores via the route of the OS, often Linux, and let it deal with real-time control complexities. But are we creating a host of new issues that are now sitting ready to surprise us once we ship such systems?
The Security Conundrum
The elephant in the room is security (Fig. 1). Our applications increasingly rely on being connected to other systems, often with Internet connectivity. We know this is an aggressive attack vector, so we need to defend against it. But we don’t know what’s going on in the myriad of threaded services Linux is executing. So how can we ever state comfortably to our program managers we have built our systems secure by design? Is blind trust in the OS warranted?
1. With multicore cyber vulnerabilities such as Meltdown and Spectre, security-by-design is the elephant in the room.
In an increasingly connected world the answer is clearly no, and for control system designers its always been no. Yet, at the same time, we have to deal with legacy code reuse for which we have limited understanding of its provenance, and put all of this onto one multicore processor. It may feel like an unassailable problem—it’s not. There are ways to unlock the value of multicore as a system design asset, but it’s not through an OS.
The issue with the OS is that as it has stretched its services over multiple cores. It has failed to adequately adhere to one of the absolute core principles of building systems securely—the principle of least privilege, which states that “every module must be able to access only the information that is necessary for its legitimate purpose.”
The majority of OS-oriented attacks operate by privilege escalation through bug exploitation, whether on multicore or not. But in a multicore OS system running multiple distinct applications, it means every exploited application is an attack vector for the whole system and every other application is now at risk. Clearly, we need to rethink the system-wide consequences of privilege escalation, particularly when it comes to unattended, real-time control systems and especially on consolidated systems using multicore.
Some hackers use side-channel attacks, which in some cases, like Meltdown and Spectre, use multicore optimization hardware design errors to gain access to memory directly and take data without privilege. This shows that our hardware is at the limits of its stable capability for secure system development—or is it? Have the processor designers foreseen these issues and facilitated software developers with the ability to mitigate and address these issues through solid secure design principles? The answer is yes, but it requires the adoption of some new technologies available on multicores and administered in ways that address both the preceding challenges and not at the level of the OS.
These issues have been recognized first in market sectors where security is as much a safety issue as it is a data-confidentiality concern. When lives are on the line—and the associated lawsuits—it focuses the mind. Without cybersecurity by design, a connected system can’t possibly be certifiably safe. Two sectors lead the charge in finding solutions to this issue, so that they can safely and cost-effectively adopt multicore and realize their SWaP and legacy code reuse objectives: automotive and avionics. In addition, the emerging market of “air mobility” (flying cars and Personal Air Vehicles) is waking up to these requirements, too.
In automotive, they have evolved Autosar to Adaptive Autosar so that a greater numbers of applications from a wider pool of OS system capabilities can be utilized and integrated safely into the car. In avionics, there’s a shift to a second generation of IMA (integrated modular avionics) with the objective of being able to adopt multicore for SWaP objectives, while realizing integration onto a single core means greater cybersecurity requirements. Physical isolation in federated units is no longer an asset available to the system architect, but perhaps the multicore designers provide the tools to deliver the equivalent?
What About Virtualization?
So, what’s the common tool these system software developers are using to protect against the consequences of privilege escalation and potentially defend against the side-channel attack even when it’s a consequence of a multicore design fault? In short, it’s virtualization. Not solely utilized to enable the hosting of multiple different OSs, but actually as a security technology. When properly utilized, virtualization offers one of the other key building blocks of secure system design—separation—in effect delivering secured isolation for those hosted OSs that enable the legacy-code reuse for next-generation systems.
2. Security needs least-privilege operation; shown is a comparison with Lynx Software Technologies' LynxSecure.
Surely all hypervisors and VMMs deliver this security? Actually, no (Fig. 2). It seems that most of them are based on a kernel or OS and, as a result, can fall prey to the privilege escalation problem, and worse, all of these can fall prey to the side-channel attack of Meltdown or Spectre. Thus, it demonstrates the core design flaw in the OS-based virtualization solution. Such weaknesses can’t be tolerated in systems where lives are at stake.
The issue is now going beyond just safety. The privacy and confidentiality of any system on the Internet or otherwise publicly or semi-publicly connected, has recently (May 25, 2018) become a huge issue. In Europe, those failing to deliver against expectations of public trust risk fines of up to 4% of company global turnover (not profits!). The new regulation, the GDPR (General Data Protection Regulation) is enforcing a new focus on the need for security by design as a support for privacy by design. Rightly so perhaps, if digital is to become ever more integral to our daily lives.
The OS has its role to play as a portable application-development platform. However, as a trustworthy solution to manage the merger of multiple capabilities across highly integrated cores sharing memory and caches and I/O, it has manifestly been shown to fail on a far too regular basis, as the daily occurrence of hacks and lost data attest.
Multi-Pronged Approach
In the end, the solution should address several factors:
- Fully utilize the capabilities provided to us by multicore processor providers.
- Limit the impact of privilege escalation to stay within the application platform environment that failed to withstand the hacker
- Provide a platform capability immune to privilege escalation
- Most importantly, deliver the hardware-supported module (OS, bare-metal application or service, or unikernel) for the secure separation these multicores provide us.
This solution is not an OS, nor even a micro-kernel—it’s a separation kernel hypervisor, where the word “kernel” merely reflects the well-understood need to support the development of securely isolated system services, as well as hosted guest OSs. A separation kernel hypervisor is a small purpose-built security layer (no OS inside) that utilizes hardware virtualization instructions to enable virtualized modules (OSs, RTOSs, bare-metal apps) to run securely on top with dedicated, securely separated hardware resources.
Keep using your favorite OS or legacy for application development, but secure it up with virtualized separation when running on multicore.
John Blevins is Director of Products at Lynx Software Technologies.
