Meltdown and Spectre are security vulnerabilities that have sent shivers through the computing world, and embedded systems are not immune. They reveal design flaws that are potentially devastating to safety-critical and security-critical systems.

If your processor has out-of-order execution (OoOE), then you need to be thinking about these newly-discovered side-channel threats. Meltdown can be defeated, and patches have already being released – although at the time of writing some patches are causing more problems than they are solving.

The mechanism of Spectre is so fundamental that mitigation is the only hope beyond the complete cure of avoiding CPUs with branch prediction and OoOE, which would fly against the current ‘common sense’ view that the associated fall in performance is unacceptable.

Lynx Software Technologies has published a whitepaper on Spectre.

Why should Lynx be listened to? Because it specialises in high-security systems, to the point where, without patching, its LynxSecure kernel was inherently immune to Meltdown attacks.

“Spectre is a greater assurance challenge than Meltdown, which is accessing unauthorised memory in the attacker’s CPU cache without relying on the direct reference to victim memory in the attack code,” said Lynx. “Spectre allows an attacker to extract unauthorised memory both within an application address space – random stack and head memory, for example – and across address spaces, including OS/hypervisor kernel memory.”

LynxSecure’s resource allocation control

Figure 2: LynxSecure’s resource allocation control

While Meltdown exploits OoOE, allowing an attacker to indirectly access kernel memory before the CPU detects that memory being loaded does not belong to the attacking process, according to Lynx’s whitepaper, Spectre accesses protected memory using CPU branch prediction to explore transient code paths. The attacker cannot access memory directly but can later deduce it through cache timing analysis.

Spectre targets code patterns containing conditional paths that can lead to unauthorised memory access.

Two distinct methods of branch prediction exploitation have been identified: ‘bounds check bypass’ and ‘branch target injection’.

Bounds check bypass is an attack that targets victim code with boundary protections on caller-controlled indices into memory arrays. By training the branch predictor with successive calls to the function using ‘legal’ (non?transient) index values, the attacker tricks the CPU into speculatively assuming that the subsequent call is safe to jump into the memory array lookup code with any transient index value address in the victim process address space.

Branch target injection is an attack with branch instructions that can jump into variable target addresses containing code (‘gadgets’) that will access private memory within the victim address space. By training the CPU branch predictor, the attacker can cause victim code to jump into gadgets that normally would not be accessible.

In a central service-oriented architecture, one must question what sensitive data is not accessible by any user process, according to Lynx. So how does a system developer know whether authentication passwords and encryption keys are accessed in way that does not leave information traceable to the processes that can request services dependent on this data – user login, for example?

“When dealing with attacks that rely on speculative (OoOE) execution there is very little that can be done to correct or even to detect the mechanics of the attack,” said the firm. “The attack code itself appears harmless, as it simply repeatedly executes perfectly normal functions in order to “train” a branch predictor as well as setting registers before calling a victim target.”

Furthermore, said Lynx, it is impractical to consider examining every piece of code that a compiler creates in order to remove every possible coding pattern that enables boundary check bypass and branching into gadgets.

A first step in mitigating Spectre is to rule out the possibility of allowing critical information such as administrative passwords and cryptographic keys to be accessed by code running on the same CPU core.

LynxSecure, for example, provides system design controls that can rule out the possibility of processes gaining access to sensitive information through granular resource allocation control. If a secret is guaranteed to execute on CPU resources that are completely independent from a user process, then there are no secrets of interest for Spectre to find.

If you are running a connected security-critical or safety-critical embedded system, you really need to consider Meltdown and Spectre. If you do nothing, you are likely to be vulnerable to future attacks.

Keep your eye on Meltdown patches, as some are being withdrawn as quickly as they emerge, and get a proper understanding of Spectre to best-protect the secrets your system needs to have.