• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Yet another Intel CPU security vulnerability!

AMD encrypts data in RAM, SME. (Secure Memory Encryption) even if you're able to get access to the memory, and that may well be the case just as it is with Intel, the difference is you get nothing but garbled garbage out of AMD's chips.

This is why they are invulnerable to all this crap, AMD designed their CPU's to be secure from the ground up.
 
It does seem that as well as resting on their laurels vis a vis performance upgrades over the last decade, they were rather lackadaisical in their approach to security too. Yes, AMD has a couple of vulns as well but compared to Intel?...

This is what happens when you recycle a design for years and years - no matter how secure a CPU is at launch give it enough time people will find clever ways to break in. A lot of the emulated hardware for games, etc. in their day often had robust DRM, encryption or other security features, etc. but even 5-10 years later people found ways to defeat it.

EDIT: The same will be true for even Ryzen, etc. if they are still relevant down the road.
 
This is what happens when you recycle a design for years and years - no matter how secure a CPU is at launch give it enough time people will find clever ways to break in. A lot of the emulated hardware for games, etc. in their day often had robust DRM, encryption or other security features, etc. but even 5-10 years later people found ways to defeat it.

EDIT: The same will be true for even Ryzen, etc. if they are still relevant down the road.

Software encryption is a poor substitute for hardware encryption. AMD Encrypt data inside the CPU before it even leaves the core.
 
Sg8Vea0.jpg

It does seem that as well as resting on their laurels vis a vis performance upgrades over the last decade, they were rather lackadaisical in their approach to security too. Yes, AMD has a couple of vulns as well but compared to Intel?...

As you point out performance & security are actually intertwined.

It turns out many of Intel's hardware speed benefits came from taking shortcuts and being less secure (on top of their infamous compiler shenanigans), up until now it's been "don't run Intel with HT enabled to try and stay safe", now it's simply "don't run Intel".

I see a massive collapse in Intel's market share in the server space over the next year or so, starting to wonder if they can actually survive if this goes on for another few years.
 
As you point out performance & security are actually intertwined.

It turns out many of Intel's hardware speed benefits came from taking shortcuts and being less secure (on top of their infamous compiler shenanigans), up until now it's been "don't run Intel with HT enabled to try and stay safe", now it's simply "don't run Intel".

I see a massive collapse in Intel's market share in the server space over the next year or so, starting to wonder if they can actually survive if this goes on for another few years.

And AMD still has now 30% higher IPC despite taking extra steps at every cycle.
 
Sg8Vea0.jpg

It does seem that as well as resting on their laurels vis a vis performance upgrades over the last decade, they were rather lackadaisical in their approach to security too. Yes, AMD has a couple of vulns as well but compared to Intel?...

Bear in mind it seems to be a sport now to look for Intel vulns, they pretty much all meaningless vuln's that are little concern in the real world, and I expect if the same effort was put into arm, AMD cpu's, there would be issues found on those platforms, I guess intel made the wrong enemies. :)
 
Bear in mind it seems to be a sport now to look for Intel vulns, they pretty much all meaningless vuln's that are little concern in the real world, and I expect if the same effort was put into arm, AMD cpu's, there would be issues found on those platforms, I guess intel made the wrong enemies. :)

They really aren't meaningless, some of the earlier ones would allow (for instance) javascript in a browser to read arbitrary memory. Not good!
 
Bear in mind it seems to be a sport now to look for Intel vulns, they pretty much all meaningless vuln's that are little concern in the real world, and I expect if the same effort was put into arm, AMD cpu's, there would be issues found on those platforms, I guess intel made the wrong enemies. :)

I haven't read every disclosure, but the ones I did have always also checked AMD and said 'not vulnerable'.
 
They really aren't meaningless, some of the earlier ones would allow (for instance) javascript in a browser to read arbitrary memory. Not good!

How meaningful these attacks/vulnerabilities are depends a lot on how much an attacker can invoke a certain part of the process at will - in a shared/server environment where a would be attacker already has one foot in the door, even with very low privilege, that is a very different situation to where they are knocking on the outside.

Something the proof of concepts don't illustrate very well is that these attacks generally need to force the data or access they want repeatedly to happen so that they can resolve it out of the mess of irrelevant/noise data as well as having visibility of that data - what takes a few hours to leak concerning data in the proof of concepts can be possible to force in a situation where you already have low privilege access to a system by invoking things like authentication attempts (some of these are possible to prevent with proper watchdogging of a system but a creative attacker might find another weakness you haven't foreseen). But in other environments like a properly setup (even without mitigations) desktop environment they might not be able to invoke the process to leak the data at will resulting in the data only appearing 1 or 2 times per user session instead of the 10s of thousands of times per second required to make sense of it any time this decade.

The browser based ones are by far the most concerning so far for the desktop but without the attacker already having some presence in the system your browser generally doesn't place privileged data often enough in the right locations under normal usage patterns for a would be attacker to make any sense of it.

For the desktop environment as it stands there are far easier ways, especially if you are running Windows 10 currently :s, for an attacker to gain privilege elevation once they already have one foot in the door than using these vulnerabilities - which don't tend to be a fire and forget thing unlike other approaches to malware.
 
How meaningful these attacks/vulnerabilities are depends a lot on how much an attacker can invoke a certain part of the process at will.

Yes and no. You ideally want there to be zero chance of any of this happening. You'd have to be unfortunate, but (for instance) if you were doing online banking in one tab, and perhaps left it open, and the browser wasn't doing the best job of cleaning things up in reasonable time, and you just happened to have left dodgysite.com open in the background, before the javascript VM patches that disabled fine timing... there was a chance you could get pwned. I tend to prefer the kind of security that comes with guarantees in the "millions of years to crack" range.

Was it an everyday threat? Perhaps not, but the fact these are present at all is a concerning.

Honestly I'm starting to wonder if the whole idea of running potentially-hostile code on the same hardware as trusted code is a stretch too far. The web has become a monstrosity in which it's expected that basically anything can run on your local machine with little oversight and little trust beyond the guarantees that the VM vendors can give you (and they were blindsided by this stuff) and then you look at cloud computing and how you have no real idea what else might be getting executed on the same hardware as your lambda...
 
Last edited:
I have noticed one of my card providers has deprecated the PC platform (they clearly dont trust it) in favour of Android, I dont trust Android, so I am at odds now with the provider and will likely revert to phone support. Web browser access is deprecated and it will be exclusive to their smartphone app in 2021. I wonder if we will start seeing other vendors do the same thing.
 
I have noticed one of my card providers has deprecated the PC platform (they clearly dont trust it) in favour of Android, I dont trust Android, so I am at odds now with the provider and will likely revert to phone support. Web browser access is deprecated and it will be exclusive to their smartphone app in 2021. I wonder if we will start seeing other vendors do the same thing.

Sadly seems to be heading in that direction - my bank is trying to push a lot to the app but it really doesn't have the overall convenience factor despite being a better option in some circumstances.

Yes and no. You ideally want there to be zero chance of any of this happening. You'd have to be unfortunate, but (for instance) if you were doing online banking in one tab, and perhaps left it open, and the browser wasn't doing the best job of cleaning things up in reasonable time, and you just happened to have left dodgysite.com open in the background, before the javascript VM patches that disabled fine timing... there was a chance you could get pwned. I tend to prefer the kind of security that comes with guarantees in the "millions of years to crack" range.

Was it an everyday threat? Perhaps not, but the fact these are present at all is a concerning.

Honestly I'm starting to wonder if the whole idea of running potentially-hostile code on the same hardware as trusted code or is a stretch too far. The web has become a monstrosity in which it's expected that basically anything can run on your local machine with little oversight and little trust beyond the guarantees that the VM vendors can give you (and they were blindsided by this stuff) and then you look at cloud computing and how you have no real idea what else might be getting executed on the same hardware as your lambda...

So far though the chances of dodgy site in one tab getting privileged data from your system via these Intel vulnerabilities even without browser patches or other mitigations is actually really low - the data is in a place where it can possibly be leaked only a tiny number of times in a normal session versus needing to force it to be there 10s of thousands or 100s of thousands in a short space of time for an attacker to have any realistic chance of making any sense of it. (I would still highly recommend everyone to make sure they are using a browser with built in protection however). And that really requires a hands on attacker with some knowledge of their intended target's environment rather than a dodgy site using a drive by malware approach.

Not my intention to downplay it but there are a lot of misconceptions because the proof of concepts aren't the most illustrating - the interesting thing is that it is possible, even in the most remotest and unlikely of senses to leak data over these boundaries that should by their nature be watertight.
 
Last edited:
I have got some data for you guys, I think it really shows how performance has been mullered with this stuff in the workloads where it hits hard.

So my 2nd rig which has often been running VMs as a reminder, here is the history of it.

Intel i5 750 running ESXi (no mitigations)
Amd 2600x running ESXi
Amd 2600X running proxmox with mitigations=off in kernel. (yes AMD is affected as well).

I have a benchmark app called novabench I was running.

APuTIjN.png

It saves test results, all the results are from the same windows install in a guest. Note I do think proxmox is generally much snappier than ESXi, although I know a fair chunk of it will be down to mitigations=off, how much I dont know, but I will reboot proxmox later with mitigations enabled and retest.

The drive hosting the image has changed over time though so ignore the overall score and just look at cpu/ram.

I picked the highest 2600x ESXi score for comparison which had XFR enabled and ESXi tuned for performance.

Ram score is lower now as I had to downclock ram when installing extra 2 dimms. The cpu score however has a crazy jump.

If this turns out to be mostly just a proxmox boost vs ESXi ;) I will delete this post in shame and post it in a proxmox vs ESXi thread instead maybe.
 
Probably to be expected? I am going through virtualization layer and it only has 4 virtual cores out of 12 hardware threads.

I have been fighting some instability which has took my time up but will hopefully today do another novabench with all proxmox/guest os mitigation's enabled.
 
Probably to be expected? I am going through virtualization layer and it only has 4 virtual cores out of 12 hardware threads.

I have been fighting some instability which has took my time up but will hopefully today do another novabench with all proxmox/guest os mitigation's enabled.

What licence are you using?
 
On ESXI I was using the free community license, Proxmox no license although I do plan to buy a community license from them.

The instability I narrowed down to when the machine was idle or transitioning between p-states, ultimately I think linux is less forgiving than windows, when I removed my -100mv on the cpu its fine again.
 
Long story short, Linus Torvalds is not happy with buggy hardware and the ever increasing CPU security issues with their chaotic state particularly around theoretical vs. practical attacks.

I can't post the link as it contains swearing but Linus Torvalds has had enough of coding against theoretical attacks that have never actually shown themselves to be used.

 
Back
Top Bottom