The Meltdown-Spectre processor architectural flaw crisis we have been monitoring has deepened as Intel has to patch its initial patch:

. . . and as a first wave of the inevitable lawsuits hits. Here, we clip one in San Francisco:

NB: Comment 3 below links and clips documentation AMD has been sued over its response to Spectre.
Where also, The Register further reports that there are problems with embedded systems using microprocessors and microcontrollers:
>>Patches for the Meltdown vulnerability are causing stability issues in industrial control systems.
SCADA vendor Wonderware admitted that Redmond’s Meltdown patch made its Historian product wobble. “Microsoft update KB4056896 (or parallel patches for other Operating System) causes instability for Wonderware Historian and the inability to access DA/OI Servers through the SMC,” an advisory on Wonderware’s support site explains.
Rockwell Automation revealed that the same patch had caused issues with Studio 5000, FactoryTalk View SE, and RSLinx Classic (a widely used product in the manufacturing sector). “In fairness [this] may be RPC [Remote Procedure Call] change related,” said cybersecurity vulnerability manager Kevin Beaumont.
El Reg requested clarification from Rockwell but we’re yet to hear back from the vendor.
The expected and well-publicised system slowdown issues from Meltdown and Spectre patches (Reg reports here, here and here) have been accompanied by even more irksome stability problems on some systems. Incompatibility with Microsoft fixes released on January 3 freezes some PCs with AMD chips, as previously reported.
An Ubuntu Linux kernel update prompted by Meltdown caused systems to become unbootable. Patching against CVE-2017-5753, CVE-2017-5715 (Spectre) and CVE-2017-5754 (Meltdown) affected both the PulseSecure VPN client and Sandboxie, the sandbox-based isolation program developed by Sophos.>>
In short, we are clearly in for quite a ride and we are headed towards a new generation of chips with significantly modified architectures, leading to a huge stirring of the industrial pot in the most dynamic sector of the global economy. My guesstimate continues to be two to three years. END
Sci-Tech: Meltdown patches patched as a first wave of lawsuits hits Intel over Meltdown and Spectre
Just to point out, Meltdown only affects Intel CPUs. Therefore, they do not really necessitate reworking of general CPU architecture. In fact, I can see AMD coming out of this as a champion.
Spectre, I think, even though it is based on the same idea (utilizing branch prediction), as far as I can tell, it is not technically a problem with the CPU. It is actually a problem with the JavaScript implementation. As far as the CPU is concerned, the JavaScript executes at the same security level as the browser. Therefore, the ability for the JavaScript to read the rest of the browser’s address space is not actually an issue with the CPU itself. It’s an issue with the JavaScript implementation.
It may be that there are features that would be helpful in the CPU for such execution isolation, but I don’t think it is really a flaw, as it is not considered a guarantee of the CPU to prevent a program from accessing its own address space. It is a flaw in the browser for not sufficiently policing programs that run with its own permissions.
Additionally, I’m not sure about this, but I think the specific flaw can be solved by simply issuing a cache flush after any failed bounds check.
JB,
Before anything else, I just saw AMD has also been sued:
I suppose ARM is next and maybe whoever owns the SPARC chip designs now.
In an earlier u/d I noted Intel is so far the main target for Meltdown, though apparently no guarantee. They pay a price for especially aggressive use of speculative execution.
The dump it problem seems to be when, and apparently that is not easily solved.
NYT, Jan 3:
In short there has to be a reason for this degree of concern.
Wiki might help as a first quick check:
looks like there is a problematique here and we are looking at a new architecture generation.
Thoughts?
KF
OP updated to reflect the suit against AMD over Spectre.
F/N: Briefing papers:
Meltdown: https://arxiv.org/abs/1801.01207
Spectre: https://arxiv.org/abs/1801.01203
KF
KF –
What I said was precisely what you were pointing out. There may be features that are needed, but it is not the *CPU* that is violating security. In fact, it is literally impossible to remove all potential avenues of side-channel attack. There have been some that have extracted private keys via *sound*.
It isn’t that Spectre doesn’t work, but that the specific *reason* it works is because browsers allow code to execute *in their own address space*. That is not really the CPU’s problem. Why should the CPU care about what a program can do with its own address space? Why should the CPU care that information about a program’s address space should leak to the program that owns it.
Spectre, at least from what I can tell, isn’t an attack on the CPU as much as it is an attack on JIT compilation. Because the attacker can predict the JIT compilation, and the JIT doesn’t segregate the address space, that allows the attacker access. But, again, this isn’t the fault of the CPU. The program responsible for guaranteeing the address space here is the hosting program. The fact that most programs aren’t built with this in mind isn’t really the CPU manufacturer’s problem.
JB, I agree that you are raising a good part of the matter, and certainly I have long had suspicions on browsers especially as I notice browser bloat and how much memory and CPU workload they now seem to take up — those suspicions go far beyond Spectre, on the principle that if something is free to you, YOU are the product being sold to someone else. As in, browser ware should be inherently suspect of being
spyware[oh, “market research” and “data mining”], as should be search engines and major social media platforms. So, maybe we need to be looking at the browsers of choice we use, given what is emerging about Google, what has come out about Mozilla, and what has long been felt by many about Microsoft. In that context, browser use of scripting languages is indeed a point for concern, most notably Javascript. However, it also seems that for example a key thing is the architecture at work. When timing differences due to using caching to speed up processing [as opposed to going out to main memory] are part of the game for instance, we are getting into a serious bind. From the noted, that then contains a reasonable probability that “If [the data fetched] was read from the cache the access time was very short, and the data read could contain the private key of encryption algorithms.” Further, as this is in key part based on MPUs using speculative execution [and thus also introducing the commit phase to the classic fetch-decode-execute processor machine code cycle], which is clearly a CPU speed-up architectural feature, we further compound the speed-security trade-off. The generic nature of the attack then suggests that no single patch is likely to fix it and why it is liable to be a longstanding challenge. Yes, just in time compilation may be a vehicle in, but the problem also seems to involve the speed-up features of processor architectures developed over the past 20 years or so, and growing in importance over the past decade. On this, I note the claimed roots in how in 2002 – 3, Yukiyasu Tsunoo and colleagues from NEC showed how to attack Misty and DES. That’s fifteen years back. KFPS: I’d love to hear more on the “sound” — mechanical vibrations? — attack.
PPS: Let us note the Abstract for the Arxiv Spectre paper:
Uh oh, we credibly have a headache on our hands for years to come. And yes, I am going to be rethinking Browser preferences. Maybe, we are about to face a new market: paid-for, guaranteed high security browsers brought out by anti-malware providers. (I already know of and have used Avast’s Safe Zone.)
PPPS: H’mm, the timing on this suggests some implicit information now:
KF,
Very interesting situation. Thanks for keeping us updated on this here.