Memory management bug in Intel CPUs threatens massive performance hits.

[Ampera]

My next main machine will be AMD. Ryzen if there isn't something better out there.

[GeorgeOfTheJungle]

Spectre & Meltdown - Computerphile

[wraper]

My next main machine will be AMD. Ryzen if there isn't something better out there.

Mine already is, and I use ECC RAM (ECC not officially supported but not locked out either).

[cdev]

The times they are a changin'

[Mr. Scram]

I plan to do the same, AMD is now competitive enough to suit my/customers needs, but also, Intel needs more competition.

Even without security deliberations, AMD offers a good product at a more than reasonable price. Unlike the previous generations, this seems to be a good choice.

[bd139]

Yeah even I'm looking at a Ryzen based machine to replace my HP Z620. Less power consumption, similar performance, quieter and smaller.

Edit: and not Intel

[Mr. Scram]

Yeah even I'm looking at a Ryzen based machine to replace my HP Z620. Less power consumption, similar performance, quieter and smaller.

Edit: and not Intel

Dat workstation though. Those HP ones tickle me the right way. What processor configuration does yours have?

[RoGeorge]

Spectre & Meltdown - Computerphile

All was clear until the last step.

How exactly are the speculative results extracted?
How come that the speculated values can still leave side effects behind, even after discarding the results?
What are those side effects, and how are they used to access a miss predicted and discarded calculation?

[BravoV]

My next main machine will be AMD. Ryzen if there isn't something better out there.

Damn Intel, already pull the trigger on Ryzen's board just now, its way too early for my budget timing. 

Cause our local mobo distributors are really nasty and well known that they love to do price hiking for this kind of occasions. Also locally here mid and upper class motherboard stock are starting to dry out, as usually distributors won't stock pile them as many as compared to low end mainstream ones, and next batch of import may take months to arrive.

Just ordered Asrock X370 Taichi, hopefully this is enough for now.

[Kalvin]

How exactly are the speculative results extracted?
How come that the speculated values can still leave side effects behind, even after discarding the results?
What are those side effects, and how are they used to access a miss predicted and discarded calculation?

If I understood the video correctly, the exploits take advantage of the {timing] information whether or not some [injected] value has been cached by the CPU or not, due to the speculative nature of execution of the instructions of the modern CPUs. You just need to make the CPU to fetch some known data from the memory and use the available high resolution on-chip timers to measure how long does it take to execute that data fetch. If the execution time is "fast", the value was cached and if the execution time was "slow" the value was not in the cache. By using this direct timing information one can extract indirectly the wanted information for the exploit.

[Cerebus]

All was clear until the last step.

How exactly are the speculative results extracted?
How come that the speculated values can still leave side effects behind, even after discarding the results?
What are those side effects, and how are they used to access a miss predicted and discarded calculation?

Cache timings. The speculative fetches leave the fetched data in the cache(s). By requesting something from memory and timing the result, you know whether is was cached or not, so you can probe the cache to see whether it holds something or not, and hence whether it was the target of a speculative fetch.

Mutating that ability into reading data requires a whole layer more and some knowledge of the data you're hunting that allows you to convert 'it was in the cache' to 'its value is x'. The obvious method is to conditionally fetch some forbidden data based on its content; this will fault, but not before it has speculatively executed the condition, which would control the fetch into cache, which gives you knowledge of whether the condition was met or not.

It's pretty easy to see how you could turn that into a binary tree that chases down the current value of forbidden_location.

[Decoman]

Seeing how there are all these news articles now on the net on this issue with primarily the two critical vulnerabilities nicknamed 'Spectre' and 'Meltdown', I can't help but think how helpless the world is, because at the end of the day, the news outlets seems to me to be more like entertainment than journalism, otherwise I would have wanted to see computer security to be be taken more seriously throughout the whole year, at least on some editorial level, so that there aren't just the occasional horrific event popping up.

And then I think that once reporting of computer security issues becomes this shallow, so as to being more of a public spectacle, I think that also makes the journalism that's is already there non objective, once a journalist makes general statements that maybe seems ok to the journalist there and then, but things considered, would be erroneous when simplifications and generalizations end up being poignant messages that dulls the broader range of issues with anything technical. I suppose that one type of flawed critical thinking would be to arrive at a conclusion of sorts, that dictate that something in particular is flawed (like a known vulnerability in a computer chip), when perhaps it is the underlying feature(s) that can be said to allow catastrophic failures in computer security to exist in the first place. A parallel to this idea of there being a horrible set of features in the first place, would be Adobe's Flash platform, which afaik is so badly tarnished with regard to what I understand as being an ever re-occurring events with 'remote execution vulnerabilities' in the code in the Flash plug-in.

So with regard to the Flash plugin.. some time back, I followed the advice of experts and finally un-installed Flash for good.

I wish anything related to computer software and hardware, was better compartmentalized, and having a perfectly good foundation to have computers running off that. And Linux wouldn't be that kind of software for me, which iirc, is known for working with usability, rather than security. When I one time had an interest in trying out a few Linux distros, the people on IRC seemed to be more like fanboys instead of sensible people, and sort of patting themselves on the back for knowing how to install stuff and set file flags, without really knowing how things work in the kernel. And with Linus living in USA, I feel I can't even trust the management, but that is just me. It didn't help when Linus some years ago was said to have sort of joked in relation to a serious question directed at him, in which it was asked something about if he had ever been approached by the US government to solicit cooperation from him or something like that, and then the man had said 'no', but nodded 'yes'. Not something to joke about.

[Decoman]

As a sort of off-topic comment of sorts, but related to computer security, I can highly recommend watching the yearly talks at the 'RSA conference', called "The cryptographers' panel" (try speaking the word- cryptographers' - out loud). They had previously some guy that used to work for NSA on the panel (iirc a Mr Brian Snow), but NSA hasn't had a representative there on the panel for a couple of years now.

Here's the 2017 one: (Note reference to NSA's "sweet bee" = suite B)


I think I incidentally read today that one of the individuals that worked with discovering one of these two new vulnerabilities is in fact the host guy seen on the very left just above in the still photo for the video. The bearded guy next to last on the right side, is Whitfield Diffie, who is known for being one of the known inventors of the Diffie Helman key exchange. It has also been pointed out that UK's spy agency also discovered this form of secure key exchange around the same point independently.

https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
"The scheme was first published by Whitfield Diffie and Martin Hellman in 1976, but in 1997 it was revealed that James H. Ellis, Clifford Cocks and Malcolm J. Williamson of GCHQ, the British signals intelligence agency, had previously[when?] shown how public-key cryptography could be achieved." Wikipedia

Btw, Susan Landau and Whitfield Diffie (both appearing in that video I linked just above), previously coauthored a book together about privacy and computer security (titled "Privacy on the line"), and one interesting point that I remember that was mentioned in the book, is that espionage directly undermines the needed privacy and secrecy between two parties for talks and deals that require there to be a fair agreement. So, if you on your side with espionage learn that the other party are discussing with themselves and agreeing that they will accept an offer of 10 billion $ for something in particular, your party might abuse this piece of private information to undercut the deal, by say offering 9 billion $. So, if you reading this, happen to think that nation state espionage is totally ok, because you expect someone like NSA to acquire such information as simply doing their job, I would argue that you are lauding a type of behavior that is obviously unethical, unjust, unfair, and maybe even criminal in the grand scheme of things.

[RoGeorge]

Still don't get it.

Let's say I have all the timing information, I know if it was a cache fetch or not, and I already tricked the processor into executing the false branch. Now, the speculative execution has finished. The results from the false branch execution are in the cache or in the CPU's registers, but the processor won't give those results to me, because very soon it will discard them all. Those results will be discarded as soon as the processor finds out that the speculative execution was in vain.

How can I read those results before being discarded?

[edavid]

Still don't get it.

Let's say I have all the timing information, I know if it was a cache fetch or not, and I already tricked the processor into executing the false branch. Now, the speculative execution has finished. The results from the false branch execution are in the cache or in the CPU's registers, but the processor won't give those results to me, because very soon it will discard them all. Those results will be discarded as soon as the processor finds out that the speculative execution was in vain.

How can I read those results before being discarded?

A protection fault on a speculatively executed load doesn't cause a cache flush.   So, the cached/not cached state is 1 bit of information that is not discarded, and can be read.

[Cerebus]

Still don't get it.

Let's say I have all the timing information, I know if it was a cache fetch or not, and I already tricked the processor into executing the false branch. Now, the speculative execution has finished. The results from the false branch execution are in the cache or in the CPU's registers, but the processor won't give those results to me, because very soon it will discard them all. Those results will be discarded as soon as the processor finds out that the speculative execution was in vain.

How can I read those results before being discarded?

The computational result isn't stored, but the trace of it having been speculatively calculated is there by it's presence in the cache (albeit with its old, non-speculatively-executed value). If you make that fetching into the cache conditional on some value you aren't supposed to have access to, then that presence in the cache stands as a proxy for the value.

flush X from the cache;
IF forbidden_variable == test_value THEN alter some other value X in a way that loads it into the cache FI
IF X is in the cache THEN implied that forbidden_variable == test_value FI
rinse and repeat

[timb]

There have been designs that fix so many problems with x86. Heck, just starting over with x86 and re-implementing a lot of stuff would make the platform WAY better, but the reason why everybody uses x86, and the reason why I can still run the first version of PC-DOS on a Threadripper is because of backwards compatibility with application code. As more and more code is written for x86, we sink deeper into why nobody will change.

If the new CPU is sufficiently powerful you could do dynamic translation between x86 and the new architecture, or even outright emulate the x86 for legacy code. The former method could run with only a 10-15% drop in performance for most applications. Anything performance oriented would obviously be recompiled for the new architecture relatively quickly.

So, I don’t think legacy applications are what’s keeping x86 around.

In fact, Apple has undergone this very transition. Twice. They went M68k -> PPC -> x86. It was done both time by incorporating a dynamic translation engine into the OS, along with implementing fat binaries for new software (which would contain both PPC and x86 machine code in the same binary, allowing them to natively execute on either architecture). This worked pretty well for them both times.

(Technically there was a third major transition as well, the one between Mac OS Classic and Mac OS X. They literally replaced the entire OS with one that was completely different. The only bridge between them, software wise, was the Carbon API, created specifically for the purpose. Non-Carbon apps could still be run in OS X via the Classic Environment, which ran a full install of Mac OS 9 in what was, in essence, a bare metal virtual machine. OS/2 used a similar concept. Frankly Microsoft should have used this approach with NT and gotten rid of all the old Windows 9x/3.11 cruft altogether.)

[Mr. Scram]

If the new CPU is sufficiently powerful you could do dynamic translation between x86 and the new architecture, or even outright emulate the x86 for legacy code. The former method could run with only a 10-15% drop in performance for most applications. Anything performance oriented would obviously be recompiled for the new architecture relatively quickly.

So, I don’t think legacy applications are what’s keeping x86 around.

In fact, Apple has undergone this very transition. Twice. They went M68k -> PPC -> x86. It was done both time by incorporating a dynamic translation engine into the OS, along with implementing fat binaries for new software (which would contain both PPC and x86 machine code in the same binary, allowing them to natively execute on either architecture). This worked pretty well for them both times.

(Technically there was a third major transition as well, the one between Mac OS Classic and Mac OS X. They literally replaced the entire OS with one that was completely different. The only bridge between them, software wise, was the Carbon API, created specifically for the purpose. Non-Carbon apps could still be run in OS X via the Classic Environment, which ran a full install of Mac OS 9 in what was, in essence, a bare metal virtual machine. OS/2 used a similar concept. Frankly Microsoft should have used this approach with NT and gotten rid of all the old Windows 9x/3.11 cruft altogether.)

The difference is that Microsoft is used much more in professional and corporate settings. Keeping things ultra backwards compatible is part of why they have the market share that they do. Their corporate customers don't like rocking the boat in major way. There's a reason that most of the changes made to Windows 10 can be turned off in the Enterprise and Server editions.

[cdev]

I wouldn't count on any modern CPU, firmware (or perhaps even OS) being free of these kinds of issues because they may be a feature, not a bug.

ya know..

[Mr. Scram]

I wouldn't count on any modern CPU, firmware (or perhaps even OS) being free of these kinds of issues because they may be a feature, not a bug.

ya know..

Shoo!

[Richard Crowley]

The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some networking performance impact. This can be addressed by turning on Azure Accelerated Networking (Windows, Linux), which is a free capability available to all Azure customers. We will continue to monitor performance closely and address customer feedback.
https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/

There has been speculation that the deployment of KPTI causes significant performance slowdowns. Performance can vary, as the impact of the KPTI mitigations depends on the rate of system calls made by an application. On most of our workloads, including our cloud infrastructure, we see negligible impact on performance
https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

All instances across the Amazon EC2 fleet are protected from all known threat vectors from the CVEs previously listed. Customers’ instances are protected against these threats from other instances. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads.
https://aws.amazon.com/security/security-bulletins/AWS-2018-013/

...Our testing with public benchmarks has shown that the changes in the December 2017 updates resulted in no measurable reduction in the performance of macOS and iOS as measured by the GeekBench 4 benchmark, or in common Web browsing benchmarks such as Speedometer, JetStream, and ARES-6.

...Analysis of these techniques [Spectre] revealed that while they are extremely difficult to exploit, even by an app running locally on a Mac or iOS device, they can be potentially exploited in JavaScript running in a web browser.
https://support.apple.com/en-us/HT208394

[bd139]

Marketing bollocks.

Reality: https://lkml.org/lkml/2018/1/3/281

We’re seeing roughly the same.

Cloud vendors are preventing the investor fall out from having to reduce their prices 20% to offset capacity reduction.

[Decoman]

Anyone thinking that all of this seem a bit complicated and weird, it should be pointed out that nowadays, the encryption on a laptop (some of it I guess) can be broken from recording and analyzing the noise patterns coming from the laptop when measuring the sound with a recording device close by. Pretty obscure stuff.

[GeorgeOfTheJungle]

This is what worries me most: "can be potentially exploited in JavaScript running in a web browser". Right now, here, as we type...

[GeorgeOfTheJungle]

I think its not disputed that NSA attempts to get hardware manufacturers to include back doors in hardware. What would be surprising is if there were not any backdoors, not if there were.

I wouldn't count on any modern CPU, firmware (or perhaps even OS) being free of these kinds of issues because they may be a feature, not a bug.

ya know..

Shoo!

And heartbleed was not an accident...