Eight New Meltdown-Like Flaws Found (reuters.com)

An anonymous reader quotes Reuters: Researchers have found eight new flaws in computer central processing units that resemble the Meltdown and Spectre bugs revealed in January, a German computing magazine reported on Thursday. The magazine, called c't, said it was aware of Intel Corp's plans to patch the flaws, adding that some chips designed by ARM Holdings, a unit of Japan's Softbank, might be affected, while work was continuing to establish whether Advanced Micro Devices chips were vulnerable... The magazine said Google Project Zero, one of the original collective that exposed Meltdown and Spectre in January, had found one of the flaws and that a 90-day embargo on going public with its findings would end on May 7...

"Considering what we have seen with Meltdown and Spectre, we should expect a long and painful cycle of updates, possibly even performance or stability issues," said Yuriy Bulygin, chief executive officer of hardware security firm Eclypsium and a former Intel security researcher. "Hopefully, Meltdown and Spectre led to improvements to the complicated process of patching hardware."
Neowin now reports that Intel "is expected to release microcode updates in two waves; one in May, and the other in August."

Comments

Retpoline

[DrYak]

Meltdown can be totally protected against in software however with a significant performance impact.

It is patched, by completely changing the way kernel works and not relying on memory protection anymore. Thank you very much, Intel !
Instead you need to context switch and make important kernel parts inaccessible on each system call.

(PCID is something that helps a bit the context switching : you don't actually flush the whole context, you use different process tags so the differently tagged process cannot be seen anymore).

Spectre can be divided into two kinds of attacks:
. One kind that bypass protection checks (range checks etc.) used to create software based virtual machines. These can be protected against in software.

Specifically, relying on by-passing any check (such as a boundary check on an array). It's ABSOLUTELY NOT virtual-machine specific.
The thing is, it's still the same process, still reading data that it has access to, to begin with (unlike Meltdown which basically fucks up any notions of memory protection). So its usability is limited to processes that both can run 3rd party provided code and contain critical data (i.e.: a badly designed webbrowser that runs web-provided javascript and its password manager both in the same context) (or another example: the Linux kernel's new-gen PacketFilter can be optionally configured to JIT compile the user-provided filtering scripts. USer-provided code in a kernel context, what could possibly go wrong ? Hint: There's a reason why it's not "on" by default).

But basically, most of the cases can be handled by keeping sane design pattern in software.

One kind that use shared branch prediction state between an attacker and a victim to influence speculative execution when running the victim code, this can be used to extract data that can be exfiltrated through a shared cache.

Which means that an attacker could be a userland software running on the cloud, and target could be the hypervisor itself. Which is several levels of scarry.
But this thing also requires very detailled knowledge of the internal of the CPU.
It has been successfully exploited on Intel Xeon by Google Project Zero.
The jury ist still out if it is possible to make a meaningul exploit on AMD CPUs (they also to indirect branching speculation, but in a completely different way, that currently seems unlikely to be actually exploitable.

This is in general not possible to patch in software.

It is actually pretty much patchable, the technology is called a retpoline. It's basically the compiler instructed to make special construct that cause mis-predicted branches to jump to an innocuous piece of code.
But it's compiler-dependant, meaning that you need to have a source code to recompile.
For the open-source world (like most of Linux distros), it's piece of cake, it's just recompiling the packages with different flags.
For closed source Linux drivers (hello, nvidia), for binary linux systems (the thing that your smartphone manufacturer put on your device and refuses to upgrade since basically the day after it started shipping), and for any windows computer : that's a nightmare.

Good program design have nothing to do with this.

Good program design try to keep sensitive data and 3rd party provided scripts separated.
That handles a lot of the Spectre v1 attacks.

It's not solving ALL the speculative execution problems tough. (it's doing nothing against Spectre v2 and Meltdown. But those are mostly due to lack of good *hardwware* design. Thanks again Intel !)