Critical security flaw in a larger number of CPUs

Maybe you have heard about this issue in the media: A great number of CPUs currently used on the market have been subject to a highly critical vulnerability, resulting in a vast number of possible attacks (these attack scenarios are known under the names of Meltdown and Spectre). We wish to expand on this topic and inform you about the scope of these security flaws and what action should be taken.

What is at issue?

The disclosed flaws ultimately lead to the read out of privileged data storage via a side channel. This includes the readout of any memory across local security boundaries. For more technical details about the vulnerabilities, please refer to:
In this way, all data which, for example, is needed to gain (authorized) access to the system can be (unobtrusively) acquired.
This is not a remote attack, but an attack which requires the local execution of code. At first sight, this may sound rather uncritical. Unfortunately, various news articles and the media have reported that this flaw results in a low security risk for embedded devices. Be aware: Simply executing Javascript via a browser can be a risk! We can assume that the first exploits, which can enter via a browser, are already in existence and are being spread. Any other possibility to execute code (for example a guest access, a diagnosis access to your system, or an interface enabling the user to add own code) is a potential risk! Therefore, we wish to explicitly point out that with any application, it is recommended to verify if there is a potential threat caused by these security flaws!

A co-maintainer of x86 architecture in the Linux kernel, Linutronix CTO Thomas Gleixner has a crucial role in the development of patches for fixing these vulnerabilities. His comments on the disclosed flaw:
"Meltdown and Spectre are a complete disaster in many aspects.
This issue has severely called into question technical features which are the basis for security concepts. For many years, researchers have pointed out that speculative execution has many risks and should only be permissible in restricted areas. It is therefore reasonable to ask whether these warnings and insights have been sufficiently taken into account when designing the latest CPUs.
It is a fact that developers of Linux and other open-source operating systems were involved in fixing these problems at a fairly late stage, clearly only months later than the manufacturers of commercial operating systems. Unfortunately, the reason for this is still not evident. We fail to understand this behaviour, especially when talking about cloud systems and critical infrastructure. It remains to be seen if the responsible chip manufacturers are going to issue relevant statements.
Similarly, the statements from institutions and associations are not really helpful; the initial reaction by BSI clearly lacks content and is full of platitudes. Statements given by the manufacturers and trade associations swing from total lack of knowledge to deliberately trivializing the issue.
At times, the CPU manufacturers' information policy has been rather in-depth, for example by ARM; yet there have been evident attempts to distract from own technical problems by way of clever PR activities. The Intel statement that this is not a bug and that the CPUs operate as expected, is more than interesting. The fact that the exploits cannot destroy, modify or delete data, is technically correct, yet deflects from the real problem: The possibility of the potential read-out of sensitive data is a door-opener for the targeted manipulation of this sensitive data.
It is about time to take these problems seriously and initiate an informed, open public discourse. Security, whether in the private or public space, should never be taken lightly and must never be sacrificed to commercial interests. Security has to be taken care of. Even though at the end of the day this means that chip manufacturers, who have enjoyed success, are now required to rethink their designs."

Furthermore, we refer to a statement by Greg Koah-Hartman (among others, maintainer of the Linux Stable series):

How can I find out whether CPUs which I have built-in are affected?

CPU manufacturers have issued statements, which include lists of the CPUs affected. Here you will find the official statement by AMD:
Intel has listed the affected CPUs within the following link:
A list of affected ARM architectures you will find here:

Furthermore, ARM has published an excellent technical white paper:

Up until now, little information is available about PowerPC architecture, but PowerPC CPUs may potentially also be affected. The patches published in the Linux kernel mailing list suggest that the IBM Power7 to Power9 platforms are also affected. NXP has not published any up-to-date information so far.

What action do I need to take if there is an affected CPU built in my system?

At this stage, affected systems should only continue to be operated under the following conditions and without an immediate update:
- If your system does not allow executing a non-trusted code
- If there is no guest access
- If there is no account for non-trusted users
- If there is no browser running on this system
Unless the conditions mentioned above are not fully applicable, both the affected CPU and the required context are given for a potential attack to happen.

My system is affected by the CPU and the context: What should I do?

Short-term: Kernel upgrade to stable 4.9.75 or 4.14.12 and a possible browser update (with version 57.0.4, a first workaround was implemented for Firefox designed to make potential attacks more difficult). For Chrome browser it is recommended to activate the so-called site isolation feature. In addition, another browser update has been announced:
Once again, this underlines the importance of using up-to-date software versions and, in the case of the kernel, long-term stable (LTS) versions. This will considerably facilitate the integration of necessary bug fixes. When using vendor kernels and software components maintained by the manufacturers, reacting to such scenarios requires an extreme effort, if it is possible at all.

My system is affected by the CPU, but not the user-relevant context: What should I do?

Currently, your risk of being attacked is rather low but each exploit endangers the integrity of the complete system. And it is expected that potential attack scenarios are going to gain momentum. To take preventive action, it is recommended to execute a kernel upgrade to stable 4.9.75 or 4.14.12.

What else should I be aware of?

We wish to point out that not only your embedded systems, but also your server and desktop systems are affected (independent from the operating system used!). The same applies: In the case of Linux, we recommend that you install the appropriate kernel upgrades and browser versions. For all other systems, please install the updates provided by the manufacturer.
We urgently recommend that you verify as soon as possible if your products have been affected, allowing for necessary action to be taken if required. If you are not sure if your CPU is at risk from this flaw and whether any action needs to be taken, please contact us! We will help you assess the risk potential and find a viable solution!
By the way: For many years, we have been dealing with making industrially-used Linux systems more secure. Not only will we help you create a suitable design, but we can also support you maintaining existing products.