Intel bug incoming? Meltdown and Spectre exploits

[Rroff]

Intel CPUs impacted by new PortSmash side-channel vulnerability!
https://www.zdnet.com/article/intel-cpus-impacted-by-new-portsmash-side-channel-vulnerability/

The vulnerability is currently confirmed on Skylake and Kaby Lake CPUs and researchers suspect AMD processors may also be impacted.
"PortSmash impacts all CPUs that use a Simultaneous Multithreading (SMT) architecture, a technology that allows multiple computing threads to be executed simultaneously on a CPU core."

I'd imagine that affects all processors that use some form of SMT/HT as it works by using contention to figure out what kind of work another thread is trying to execute the only mitigation would be to significantly slow down processing by wrapping all processing up to look the same (as a simplistic explanation).

As before though this isn't a remote execution vulnerability for most users - though a potential issue for professional environments - for the average consumer if something is taking advantage of this issue on your system then you've got far worse issues in respect to security.

 

[NinjaCool]

Yes this seems to primarily be a concern for workplace environments so not exactly an issue for gamers but it's yet another security issue that needs to be looked into.

 

[Destination]

Pats 9700K.

Knew there must have been some reason, i wonder if Intel is actually aware of other flaws and issues they are not mentioning as yet, and will divulge later with 'fixes' as the community becomes aware of such.

 

[UTmaniac]

Has anyone installed the June BIOS update for the https://www.gigabyte.com/Motherboard/GA-X99-Gaming-5P-rev-10#support-dl-bios ?

Happen to have the i7 5820k CPU installed, from the Black Friday deal a few years ago as well? If so, how bad was the performance hit?

 

[V F]

Yes this seems to primarily be a concern for workplace environments so not exactly an issue for gamers but it's yet another security issue that needs to be looked into.

It seems to be neverending?

 

[NinjaCool]

Linux 4.20 Performance Decimated by Spectre and Meltdown Mitigations
https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1

The culprit is the "kernel-side bits for STIBP (Single Thread Indirect Branch Predictors) for cross-hyperthread Spectre Variant Two mitigation.
AMD CPUs does not appear to be impacted by the mitigations.

It seems to be neverending?

You can say that again!

 

[SledDriver]

16 months ago I bought a brand new ASUS Z-370A Mobo and 8700K CPU just days before the Spectre and Meltdown exploits became a thing. At the time new BIOSes were produced to deal with this exploits, but there were many stories around of them crippling or at least notably affecting the preformance of systems.

I run mostly timing critical applications - music production for work and heavily loaded flight simulator sessions for play. Therefore I have avoided upgrading my BIOS to versions since before the exploit BIOSes, so I'm still running the now old 0605 version.

Now, 16 months on, I see that ASUS have released several updated BIOSes since the one I run. Does anyone know what is the situation with these updated BIOSes and system/cpu performance compared with pre-exploit versions.

I should point out that at the time, I did install and try the first couple of ASUS BIOSes which dealt with the exploits, and indeed there were system slowdown in my applications which I was not prepared to live with.

What is the situation now regarding performance with the newer BIOSes?

And what is deemed risk factor of not running the updated BIOS these days?

Cheers,

 

[zola25]

I have the same board and CPU combo as yourself. Although I've done no empirical testing, I too found that the early updates impacted performance, particularly anything that was I/O bound. For example running full Malware/AV scans concurrently with VMs introduced lag to browsing and opening files.

However I am now using 1601 and have found it to be acceptable in combination with performance improvements Win 10 1809 applied. It's definitely not quite as snappy under extremely high I/O loads as the pre-patched versions, but is much better than the early patches and a reasonable compromise. That's just my own opinion of course.

 

[Bonjour]

Patching these exploits on our VMware cluster has had a devastating affect on performance, particularly the SQL servers.

So much so that we're replacing the cluster with Intel Gold 5120 hosts. I'm guessing these won't suffer the same crippling performance hit as the older Xeons?

Has there actually been any reported exploits of Meltdown or Spectre in the wild?

 

[Distracted]

Can all the mitigations that aren't in hardware be turned off?
Sorry if this has already been answered.

 

[Distracted]

Nvm, i found what looks like answer.

 

[Mercutio]

I'd imagine that affects all processors that use some form of SMT/HT as it works by using contention to figure out what kind of work another thread is trying to execute the only mitigation would be to significantly slow down processing by wrapping all processing up to look the same (as a simplistic explanation).

As before though this isn't a remote execution vulnerability for most users - though a potential issue for professional environments - for the average consumer if something is taking advantage of this issue on your system then you've got far worse issues in respect to security.

Not blindly defending... just... checking my understanding.
As far as I was aware, the AI doing the pre-threading/processing in AMD meant that identifying what parts of memory were owned by what process was rather more difficult on AMD.
It's not like it's a "amazing bit of fore-thought and wonderful engineering" type protection, it's just a random choice made that by dumb luck helps make the attack vector rather more difficult to exploit on AMD. It exists exactly the same but the way it's organised/addressed in AMD CPU's rather helps obfuscate what process a memory area belongs to.

 

[Rroff]

It's not like it's a "amazing bit of fore-thought and wonderful engineering" type protection, it's just a random choice made that by dumb luck helps make the attack vector rather more difficult to exploit on AMD. It exists exactly the same but the way it's organised/addressed in AMD CPU's rather helps obfuscate what process a memory area belongs to.

Depending on which CPU family you are talking about AMD benefited a bit from being behind the curve with Zen and learnt from some of the issues as they started to come to light as the technology progressed in general - some aspects can be flagged off on a per application basis others aren't as easily exploited due to hardware design depending on which potential weakness is attempted to be exploited (sometimes comes with a small performance penalty at a pure hardware level - but not as much as if they had to patch it afterwards). Earlier AMD CPUs lacked some of the features at all which is why they aren't exploitable in the same way but also why they were so behind performance wise in some areas.

Ultimately though if someone tries hard enough they'll probably find ways to decypher data that is trying to be obscured in current HT/SMT implementations (other than where they are protected by performance regulation) just with Zen it will probably take a good few years before anyone figures it out. Can see the same kind of thing with older CPU designs especially when it comes to emulating them on newer hardware, etc. where things like memory protection that were pretty much air tight at the time people eventually found clever ways to open up.

Intel really screwed a lot of things up by trickling out tech progress despite having banked a lot of R&D.

EDIT: Quite frankly though a lot of it isn't very useful - the level of resources required and the kind of information you are talking about with these exploits is only really applicable to large scale industrial or state sponsored hacking where you already know kind of what you are targetting rather than indiscriminate attacks against random users as you have with run of the mill malware.

 

[chrcoluk]

I think different people will have different views,

My view on these cpu exploits is they are high hanging fruit for the malware authors. They are difficult to exploit. For a desktop user the biggest risk factor is the web browser and all the major browsers have browser side spectre mitigation's (which is largely what the bios updates address).

There is 2 system wide spectre mitigation's available.

There is the poor one which involves the bios update and OS patched code, which is the current windows mitigation. Its not even full mitigation but only kernel side, full mitigation would be devastating hence its not been done. In a few months Windows 10 will have a new build which uses the second method developed by google, which is reptoline. A much smaller performance hit, I would wait for that and not update the bios if you feel you really must have the mitigation.

Meltdown impact varies (you likely already patched this doesnt need bios), it impacts kernel calls especially related to i/o operations, note it means i/o access to ram as well as storage. Impact will depend on your usage, the impact is typically lower on desktops than servers.

Worst case scenario for these exploits is virtualisation, someone applying full mitigation on that use case will quite probably see devastating results.

Also windows 10 and linux supply the updated microcode OS side, so you dont even need a bios update for those operating systems, freebsd also does via a package. Users of older versions of windows dont get the OS side microcode updates tho and would need a new bios if they wanted that mitigation.

 

[Rroff]

My view on these cpu exploits is they are high hanging fruit for the malware authors. They are difficult to exploit. For a desktop user the biggest risk factor is the web browser and all the major browsers have browser side spectre mitigation's (which is largely what the bios updates address).

Obviously I'm overly generalising but:

The way I see it, for the average desktop user, sure software could exploit these issues but if you are running that software in the first place then you either have some degree of trust in the developer or have bigger security issues. The web-browser is the most vulnerable unsolicited vector even though the risk is quite small due to these kind of attacks generally needing to be targetted rather than fire and forget like a lot of malware is.

Stuff like SQL servers are more at risk as higher chance of commercial or personal data that might both be a specific target and the attacker already having some idea of what they are looking for/environment they are working with or even inside information that can help them.

I doubt we will ever see "in the wild" malware using these exploits the usage will likely be after the fact facilitated by droppers that use other exploits like EternalBlue.

 

[chrcoluk]

exactly, all the proof of concepts has been to voluntarily run a executable that runs the code.

 

[Double07]

exactly, all the proof of concepts has been to voluntarily run a executable that runs the code.

Sadly that wouldnt be too difficult to do with the vast majority of users, I can't the only one on here who gets people asking them to fix their PCs and it is crammed full of the most random crap imaginable. You ask, "why did you install that?" and the answer is almost always, "oh I didnt know I had, I just clicked on stuff".

 

[chrcoluk]

Well if someone is dumb enough to run an exe embedded with malware, then it doesnt matter if this is patched, as there is always something unpatched to exploit a system. You dont even need to exploit a system if someone willingly runs your rogue code.

 

[Mercutio]

I think my bit was... yeah, fractional AMD bias - but the way Ryzens AI does branch prediction and pre-processing/etc meant that while the attack vector exists (the result are in a bit or memory that isn't properly protected and there's ways and means to look at it), the way the AI does the branch prediction means it's rather more tricky to catalogue which results in memory are for which processes.

Rather than "results for important_banking_app.exe" tags pointing to the data it's more "result for AI task 4534534534534.345345,1". It's still ultimately exploitable. But... there's a few more steps needed for it to make sense and have useful data purloined from the attack.

My understanding isn't amazing, that's likely VERY simplified but... it's that sort of difference. The Intel branch prediction result are rather easier to "crawl through".

 

[Bonjour]

Frustrating. I thought Intel had sorted this. On a brand new Intel Gold host: