New ZombieLoad Side-Channel Attack Variant: TSX Asynchronous Abort

[wizard69]

so it affects cloud providers and anyone who uses a web browser.

Lovely isn’t it.

[NateHubbard]

I use NoScript whenever possible, so I'm not really concerned.

Do you read every bit of javascript that you allow your browser to run, every time you visit sites you trusted previously?

[starshipeleven]

I use NoScript whenever possible, so I'm not really concerned.

Your post was still wrong though. You should have said something like "use NoScript to not run untrusted js on the browser"

And even then I laugh at people that still believe the user can decide what he can trust.

You are not auditing the code. You are not even able to audit the code. You don't look at anyone that has audited the code. Yours is a fucking religion. You just have faith in some applications and not in others.

[starshipeleven]

They'd better get paid handsomely.
I'd imagine severe loss of hair and acquiring muscle twitching tics from just trying to grasp the magnitude of effort.

AMD ones seem to be doing a decent job at this so far. Word on the street is that Intel management gave orders to relax the QA.

[Mario Junior]

Finally a utility for TSX: be a fucking security hole.

[JanW]

I use NoScript whenever possible, so I'm not really concerned.

I do, too. And I rarely trust any source permanently. And then most of the web or more is broken and when I want to access a page, I one by one try to temporarily enable the sources that look most promising to restore functionality, from the dozen or more scripts that are blocked on each site. And when I get tired of that game I enable it all, temporarily. And now browsing for me is: Go to site, enable all scripts temporarily.

I'm incapable of auditing any of the code so in the beginning it was a feeble attempt at reducing attack surface and now using Noscript has become just a farce for me.

YMMV, but this doesn't look like a solution to me.

[L_A_G]

I feel like "can't we just rip the bandage off all at once and do all the exploits and mitigations in one big batch?" But then, I'd probably be stuck with a computer that would never boot again.

Considering so many of these bugs are shortcuts made in the implementation of things like speculative execution, SMT and TLB that are invisible to the user and programmer that I don't think a machine without them would be unable to run the code. An x86 CPU without these things would essentially be a multicore 486 with modern vector instructions implementing the AMD64 instruction set, so not the fastest thing around, but not completely unworkable either.

Come to think of it, that wouldn't be that far off from Intel's Xeon Phi accelerator cards, so they could just dust off those things and do what they did in the early 2000s when they threw out the Pentium/Netburst lineage and promoted their mobile CPU lineage to their main desktop lineage.

[Almindor]

I guess the joke about Intel CPUs losing performance on a monthly basis is as true as ever. Who knows how many of these are under embargo right now?

It's the inverse Moore's law at this point. We should make a new "Intel's law". The effective computing power of the CPU you buy from us will halve every year from purchase.

[rahvin]

As has been posted frequently. The only potentially safe Intel processor is one with Hyper threading disabled. Hyper threading appears to have been designed with no security in mind at all. AMD's version of SMD has not been vulnerable to these variations of the spectre attacks because AMD did the secure thing rather than the thing that boosted performance a half percent but left everything open to any process to suck information out with the assumption that no one would ever figure out how to do it.

Does anyone need to be reminded, Spectre-like based timing attacks were discovered more than a decade ago but no one was able to demonstrate a viable attack until the first Spectre exploits were released. In that time frame Intel continued to assume no one would ever demonstrate an effective attack while AMD mitigated at every point in the execution stack leaving them only vulnerable to very few of the exploits even though it hurt performance a little to execute securely. Spectre has been a real eye opener about the company that was actually concerned about security an effective process isolation.

I wouldn't dare run Intel in any kind of cloud environment these days where you share the system with any other users or where untrusted code could be executed on the same system. If you've got an Intel server you've got to lock that sucker down and stay up on exploits because it isn't going to be long before hackers start combining regular privilege escalation attacks with spectre attacks and start sucking critical information out of memory. There's already meltdown based malware circulating.