Cog’s D4 Secure products mitigate and protect connected devices from many different forms of attacks. Let’s take a look at how D4 is impacted by Meltdown and Spectre, and how device makers can use D4 to create more secure and feature rich IoT devices.
What is Meltdown and Spectre?
Meltdown and Spectre are ‘side channel’ attacks leveraging bugs found in the design and implementation of many modern processors. Meltdown mostly impacts Intel x86 chips (which a lot of the Cloud is built on). Spectre impacts Intel and also may impact other processors from AMD and ARM, and in particular those that perform software computations via speculative execution such as out-of-order. Many of today’s flagship processors execute code instructions ‘out-of-order’. That basically does what it says, allowing the processor to run some code speculatively and then only commit to memory, or make visible, the results of the instructions which ended up being executed.
For example, a code sequence depending upon a decision needs to either add two numbers together, or subtract them. So, before the processor knows what the decision is, it picks one path to execute assuming it can guess the decision outcome, and holds onto the results of the computation until the decision is made a short time later. These types of processor optimisation are necessary as they allow for better utilisation of the processor’s computing units that ultimately speeds up computation and reduces latency.
These are bugs in the implementation of the processor. They’re serious because at no point should speculative execution of an unrelated computation be made visible to another, and unlike other side-channel attacks, these manage to extract data at a very high bit-rate.
Operating system software can implement protections and work-arounds to protect your devices. Some of these protections, like those built into D4 Secure are by design with little-to-no performance impact. Other workarounds will impact performance. For example, in some scenarios the operating system will flush the processor caches (things that make memory operations faster), which reduces the benefits of those caches and can make performance lower.
A key concern within the research community however is that these and other side-channel attacks are going to continue to make headlines for years to come – and all operating system vendors including Cog, device makers, and even application writers are responsible for mitigating the impact of these attacks. D4 Secure isn’t perfect, but offers some of the solution today and ultimately raises the bar on security. We continue to invest heavily in operating system and platform security to stay ahead of the bugs and attackers.
Do they impact my D4 phone, or your Raspberry Pi IoT community platform?
No. Our D4 phone (available here), and our Raspberry Pi community development platform (here) are immune to these specific attacks. Of course, we continue to audit, and improve our software to minimize risks associated with many forms of attacks or bugs. D4 protects you from many other attacks by design, and offers device makers optional hardening features to further risk mitigate where needed.
Are any products based on D4 secure impacted?
Some products may be impacted by Spectre, especially those using OSes and chipsets known to be vulnerable. However, a well designed system using D4 also mitigates the impact of a successful Spectre attack. Read on below for more information.
It is also important that all customers using cloud services along side D4 devices assume that their cloud software is at risk and needs to be patched.
I’m a device maker. Will using D4 Secure in device protect us?
Yes. Products built with D4 Secure are more secure and less prone to failure including from exploits such as Meltdown and Spectre, even on chips known to be at risk. And, we continue to make our capability better, because we believe that great security is foundational and critical for our connected IoT devices.
D4 Secure helps mitigate against threats including Meltdown and Spectre thanks to our modular, defence-in-depth approach to software architecture, and our unique hypervisor capabilities which include hardening against threats including side channels and remote code exploits, as well as our careful and detailed collaboration with customers and the ecosystem on platform and chipset choice. We’d never claim D4 is attack-proof; we believe it performs above and beyond any other solution, and ultimately enables mobile and IoT device manufacturers to produce products that are safe and less prone to failure from attack and other sources of failure.
For example, the meltdown attack cannot be used across our micro-VM boundaries, or to compromise the hypervisor kernel on any affected processor. This means that while an attack could be successful within a VM against an OS like Linux, the threat would be contained there. When we combine that with D4’s modular design principles, this ultimately means the rest of the system is protected and your sensitive data and applications there will be safe. This can help mitigate Spectre too.
Device makers need to decide how much mitigation they would like to take as there are some performance tradeoffs, even on D4, and they’ll need to ensure the software they run within micro-VMs on D4 are patched to reduce risk of attack against those VM modules.
At Cog, we’re not done – we’re continuously adding new features to make security even better. We are developing a broad range of guest operating system hardening capabilities, that help further mitigate or prevent a broad range of attacks and exploits including remote code exploits. Many are already available today for our customers building connected IoT devices on ARM chipsets. These are simple to use and protect even monolithic Linux-based systems running on-top of D4. You’ll be able to try that for yourself at our community portal, where we are releasing many of our new features for device makers to try.
Want to learn more?
Contact us at Cog to learn how to build your IoT and connected devices with D4, with great security and functional richness. If you’re after more technical detail, check out these write ups: