Spectre and Meltdown – How to Respond in the Embedded World

The past few weeks have included a whirlwind of speculation and revelations around a new set of security issues known as Spectre and Meltdown.  Collectively, these issues impact most of the major processor architectures and implementations, prompting the cross-cutting question – “what should I do about these issues?”

Much of the initial information available focuses on answering this question for cloud computing environments, enterprise IT environments, and consumer endpoint environments.  The embedded world, however, typically has different characteristics and constraints, and as a result, answers to the question may look different.  For example, many embedded devices are more-or-less fixed function devices that are not designed to allow execution of unproven code that might attempt to exploit Spectre or Meltdown.  Developers of devices with these constraints may take a different path to resolution than the developer of an enterprise or cloud solution.

This blog discusses proven approaches to resolving many types of security issues and applies them to the question at hand – from the perspective of an embedded, software defined world.

A Little Background

Spectre and Meltdown are side channel attacks that take advantage of speculative execution, a common technique in processors used to achieve high performance.

• Side Channel = some aspect of a computer system’s physical operation that can be used to expose information being processed by the system without directly receiving that information.
• Speculative Execution = a feature of most modern CPUs that allows them to speculate what code they might need to run for a given process, and run it in advance so the results are ready immediately when needed.

So Spectre and Meltdown are ways of exposing information in a computer system by observing an aspect of its physical operation related to speculative execution – specifically timing.  Code executing these attacks can uncover information that it would not normally be authorized to access, such as passwords or keys used by other applications or even by the operating system itself.

Wind River has been working with processor vendors and the security community regarding Spectre and Meltdown, and continues to do so as a committed security vendor.

What To Do About Spectre and Meltdown

Security is all about identifying risks and determining whether a given risk’s likelihood and impact is acceptable, or whether you need to do something to reduce the risk’s likelihood, impact, or both.  For Spectre and Meltdown, the risk is that an attacker can use the speculative execution side channel to expose information that they are not authorized to access.  You can use the following steps to navigate your path through this challenging process.

Step 1 – Determine the Likelihood and Impact of the Risk for Your System

The Spectre and Meltdown issues have a few pre-requisites to be feasible:

1. The processor must implement features that can be exploited by Spectre or Meltdown – determine whether your processor is vulnerable to Spectre, Meltdown, or both using the processor vendor’s guidance and documentation
2. The processor must have a timing source granular enough to measure the impacts of speculative execution – this can be somewhat system dependent, but in general if only coarse grain timers are available (i.e., smallest timing measurement is on the order of 1000 processor clock cycles or more), exploiting timing of speculative execution is extremely challenging
3. The attacker must be able to run attack code on the processor – Spectre and Meltdown are not remote attacks, they require attacker code to be running on the processor and measuring the timing of speculative execution.  Many embedded systems or mission critical systems are highly constrained and only allow a prescribed, pre-defined, and verified set of functions to run on the system.  In these types of systems, for example, the likelihood of an attacker running attack code on the processor may be low enough that the risk is acceptable.
4. There must be information accessible to the processor that the attacker is not authorized to access – the Spectre and Meltdown issues do not have the potential to corrupt, modify, or delete data, so if the system does not contain information that an attacker is not authorized to access, there would be no impact related to a successful attack and the risk may be acceptable.

Based on evaluation of these four pre-requisites, you may find that Spectre and Meltdown do not pose a risk with high enough likelihood or impact to justify any further action.  If you have questions about aspects of these pre-requisites, for example the likelihood of an attacker running attack code on your system, Wind River can help.

If the four pre-requisites are met (the processor implements speculative execution and a sufficiently granular time source, attackers may be able to run code on the processor, and there is information on the system an attacker is not authorized to access), then a characterization of the likelihood and impact of the risk is needed.  A framework such as the one shown below can be helpful to communicate this characterization.

The definitions of likelihood and impact levels will be different for different organizations, but using this framework can be an effective way to communicate the current likelihood and impact as well as the desired likelihood and impact after mitigation. Wind River has long assisted customers with security assessments, including assessments of risk, and can help out in this area, if needed.

Step 2 – Determine the Resolution Strategy

Once the likelihood and impact of the Spectre and Meltdown risk are characterized, if the current risk is unacceptable, a resolution strategy is needed.  While there are several mitigations being developed by processor vendors and software vendors in the community (including Wind River), it’s important to recognize that there are many potential resolutions with different tradeoffs.  Wind River is committed to working with the community to create optimal mitigations where needed for the hardware-based Spectre and Meltdown issues, however we recognize that each solution comes with a unique set of characteristics and that options are needed.

As an example of a potential resolution, if your system is highly constrained as defined previously, but the likelihood of an attacker running code on your system is not sufficiently low because the system does not verify the authenticity of its executable images, then a combined solution of secure boot and static analysis may be acceptable.  The addition of secure boot with digitally signed images would provide authentication of the executable images and data, ensuring that the images only come from trusted sources.  Static analysis would verify that the digitally signed images do not contain speculative execution code sequences, and can therefore be trusted.  This solution would trade off the integration of secure boot (incorporated in Wind River’s VxWorks product line as well as our open source based product lines) with the potential run-time overhead of currently proposed OS and compiler level mitigations.

In another example, if the primary issue is protecting a few very sensitive pieces of information such as cryptography keys, a solution that moves the storage and operations using these keys to a separate cryptographic offload engine or a Trusted Platform Module (TPM) offers a different set of tradeoffs vs. porting an existing system to a newer, updated, version of the operating system.  If the separation of the sensitive information to a hardware module can remove pre-requisite 4, above (there must be information accessible to the processor that the attacker is not authorized to access), then this type of solution may provide an acceptable level of risk with minimal impact to the applications.

The right resolution strategy depends on multiple factors such as schedule, cost of validation and update, and robustness.  Understanding available resolution options is important to ensuring the best resolution strategy is chosen.  Wind River can help teams determine the set of options and their tradeoffs, and Wind River offerings provide a spectrum of implementations, including the community based mitigation.

Step 3 – Monitor

The responses to Spectre and Meltdown will evolve over time.  Initial software-only mitigations are likely to change as processor suppliers provide microcode fixes, and optimizations are likely to be introduced over time.  In addition, it is likely that Spectre and Meltdown will inspire significant additional research that may result in both improving mitigations as well as uncovering additional issues.  Monitoring will be an important part of addressing the issues that Spectre and Meltdown have uncovered and keeping resolutions as up-to-date as possible.

As part of the community addressing mitigations and resolutions, Wind River is actively tracking, integrating, and developing solutions across all products in our portfolio.  Our customers can stay current with the evolution of Spectre and Meltdown solutions through our customer support site (https://knowledge.windriver.com) and subscribe to our RSS feeds for notification.  Our publicly available CVE database provides higher level information about the impact of the associated CVEs for those without active support accounts.  Our CVE database is available here:  http://www.windriver.com/security/cve/main.php

Our product update features also provide the delivery channel for solutions incorporated in Wind River products, and allows our customers to choose the timing for incorporation of solutions and their updates.

As part of the response process to Spectre and Meltdown, planning for future responses will help streamline adaptation to potential changes.  Our products incorporate update solutions and our Professional Services organization can assist in customization of update solutions as well as integration and streamlining processes and tools used in the creation, validation, verification, and delivery of updates to devices.

Summary

Spectre and Meltdown have awakened all participants in the software defined world to the potential for side channel attacks to expose information in unauthorized ways.  Throughout industry, the question “what should I do about these issues?” is being asked.  Much of the initial information available focuses on answering this question for cloud computing environments, enterprise IT environments, and consumer endpoint environments.  The embedded world typically has different characteristics and constraints, and as a result, answers to the question may look different.

For everyone – whether focused on the cloud, enterprise, consumer, or embedded – an effective approach first looks at the risk and impact of the issues, and then proceeds to determining a resolution strategy, implementing that strategy, and then monitoring the solutions.  The conclusions of the approach may differ for different environments, but the approach provides a thorough, thoughtful framework for response.

As part of the security community responding to Spectre and Meltdown, Wind River is providing robust, optimized software solution options for devices and systems across a wide spectrum of industry and for a wide spectrum of processor implementations.  These options allow our customers to balance tradeoffs in their systems so security can be maintained alongside real-time, safety critical, mission critical, and resiliency requirements, among others.  Our best in class security response teams not only provide the initial responses and solutions, but also notifications and updates as solutions and environments evolve so developers can ensure their systems can be secured today and remain secure in the future.