Windows Client Guidance against speculative execution vulnerabilities

OldMike65 said:

Yes Asus released all of their Intel 370's boards already. All the others have not been released as of yet.

I checked the ASUS Global
link and I'm assuming that they won't provide updates for the "Asus Z87-A Motherboard - Haswell CPU only" which despite being 2013 "vintage" is my main PC and is still as powerful as i need, what with the 16GB memory and SSD.
If anyone knows differently please respond

Cliff S said:

An Update on AMD Processor Security | AMD

Thank you. @ Intel I know, its not funny, but I couldn't resist. Please don't take offense. In a way they do deserve it some what.

Cliff S said:

For the Maximus X Series boards, it was released(uploaded ) already on the 3rd of January, they were fast!

Uh, no they were not. See my more full report below.

axe0 said:

Isn't software a part of the product?

Software is the majority pat of the problem - because of the software that was written to make use of capabilities provided by the CPU without forethought that such an exploit could ever be developed.

____

Now, in the defense of the chip manufacturers as well as the software developers, this is a very new set of exploits.

First off, some heavy technical background reading: https://meltdownattack.com/meltdown.pdf and https://spectreattack.com/spectre.pdf (and for some easier to understand but no less technical reading, also see https://www.renditioninfosec.com/fil...nd_Spectre.pdf )

Now from the Meltdown PDF:

Acknowledgment

We would like to thank Anders Fogh for fruitful discussions at BlackHat USA 2016 and BlackHat Europe 2016, which ultimately led to the discovery of Meltdown. Fogh [5] already suspected that it might be possible to abuse speculative execution in order to read kernel memory in user mode but his experiments were not successful. We would also like to thank Jann Horn for comments on an early draft. Jann disclosed the issue to Intel in June. The subsequent activity around the KAISER patch was the reason we started investigating this issue. Furthermore, we would like Intel, ARM, Qualcomm, and Microsoft for feedback on an early draft.

These bugs were not discovered In Jan 2018. They were first theorized at BlackHat USA 2016 (July-August 2016) and further at BlackHat Europe (Nov 2016). Meltdown was disclosed to Intel in June 2017. The other chip manufacturers were told about the exploits also a while back, and they have been working with hardware partners for a long while to push out fixes. Microsoft worked on the NT kernel, as we saw with the Intel only IP build, and the Linux community patched the Linux kernel, and many software vendors like Mozilla and Google have patched their software (with Google, the final version of Chrome with the patches, v64, goes live in a couple of weeks for regular channel users, but Chrome Dev and Chrome Canary are already patched), and Google has rolled out a series of patches to its servers that show the performance hit is much, much lower than originally speculated.

So, all your OEM hardware manufacturers that are putting out FW and BIOS patches now are not fast at all - they're actually behind already. Thees patches should have already been deployed to mitigate the effects of the exploits before they were made public so that the end users would already be safe from any newly developed malware looking to make use of the exploits.

Bottom line:

Meltdown can be secured, but thus far, no one has found a way to secure against Spectre.

More so than just a chip redesign.

The idea here is that memory isolation is foolproof - like MD5 was foolproof. Only they're not.

If you take out the speculative loading of information, then the info is only loaded when called, which means it takes time (CPU cycles) to load the information at call time. But that is not good enough - after being used, you have to clear the registers so that the info is no longer present, taking yet more CPU time. And therein lies the real problem with respect to performance issues. You're now using a lot more CPU cycles for every secure transaction call than you were previously.

A good, simplistic analogy for this goes like this: You use your browser for online banking. So, you typically load the webpage, fill in your credentials and do your banking. It takes X amount of time to do so.

Now imagine that, because of a new exploit, this is the manner you have to conduct online banking:

You load your browser, and load the webpage. In order to log in, you have to authenticate yourself to the server, which requires a passcode of some type that you have to hash out (manually) on the fly.

Now you can conduct your business - but every time you perform a transaction, you have to rehash out your password, over and over again, because the system doesn't cache your information, and you have to call it repeatedly. This is because once the info you requested has been given to you, it erases itself from memory, so effectively, you have to log back in to your bank each and every time.

See how this becomes cumbersome even for 5 simple transactions?

Now imagine expanding that to millions of transactions per second.

Mind you, as I said this is a simplistic view of things - but it gets the point across very, very well.

Just imagine if you will how long it would take if you had to log in each time you wanted to post a reply here at 10F

Well, if you really think about it, the way that the CPU is set to make use of memory isolation is, in a sense, a type of firewalling to begin with. Right now you cannot access that information in those registers directly - they're effectively firewalled from active processes, except those that have the correct credentials to allow access to the information in those specific registers. But the exploit breaks the access chain, and then allows a dump of what's there, providing indirect access.

As far as encryption goes, though, from my (albeit limited) understanding, is that when you encrypt something, you need a key to decrypt. Guess where decryption keys are stored?

All in all, it's basically the idea that this was developed as a system to increase performance because, at the time of development, no one thought outside the box and realized that this sort of exploit would ever work, or could ever be leveraged against the CPU.

Now, of course, we know differently.

Mind you, though I've been trying to explain all of this, I'm also actually still trying to wrap my noodle around it all. A lot of this is way above my knowledgeset, and I'm learning a lot of new things here that I, more than likely, would never have been exposed to. So, I apologize in advance if I am misrepresenting this in any way.

Still, though, from what I have thus far gleaned in all the reading I've done (and it is a tremendous volume of stuff I have been reading, minus all the media hype - I stopped all those types of links a while back, as I kept getting the same spin without any real, hard, substantive facts) and it is quite ingenious the way the system is supposed to work in the first place.