Real-time control for multicore needs to rethink trust in the OS

November 22, 2018 // By John Blevins
Real-time control for multicore needs to rethink trust in the OS
OS architecture is insufficiently secure by design in the context of modern multicore processors. A new approach is needed that looks beyond security and into complex system design for security, safety, and complex consolidated system architectures.

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. 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?

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 it has 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.

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.