AMD processors from 2011 to 2019 vulnerable to two new attacks

[gpuerrilla]

If you apply all mitigations including the software/Windows patches and some of the firmware updates designed to reduce the performance impact, etc. then the performance penalty will vary a lot depending on task there isn't really a set "25% slow down" some things performance isn't impacted at all other things there is a small to moderate hit. Personally I've only used a small number of updates to protect my external exposure and the performance impact is mostly so close to 0% at worst it makes no difference - talking within error margin differences - there was one thing with ~3% reduction but I can't even remember what that was.

Listen man, Im only saying what I keep reading. Im not gonna trawl the web for every one of them but just take a look at a result in my first search I get this. Its probably way off or exaggerated, but come on close to 0% and max 3% your in fairy land.

 

[Rroff]

Listen man, Im only saying what I keep reading. Im not gonna trawl the web for every one of them but just take a look at a result in my first search I get this. Its probably way off or exaggerated, but come on close to 0% and max 3% your in fairy land.

Read what I said - I said personally I'm only using the patches I consider most critical hence I'm seeing a much lower hit.

For someone that applies every mitigation and patch going the impact is going to vary on task it isn't like suddenly your CPU slows down say 25% - some things will get hit harder some things less so or no impact.

 

[gpuerrilla]

Read what I said - I said personally I'm only using the patches I consider most critical hence I'm seeing a much lower hit.

For someone that applies every mitigation and patch going the impact is going to vary on task it isn't like suddenly your CPU slows down say 25% - some things will get hit harder some things less so or no impact.

Likewise, please READ what I said (in the first place) as it is a continuation of @Scougar question, I am answering this not your personal cherry picked patches - discussing ALL of them to see how badly the total impact is.

I'd be interested in seeing those pre and post mitigation updates charts for sure.

What is interesting is that the volume is showing in many of intel products, and like I said should all the 'fixes' and tweaks be implemented, I wonder if a cpu from generations ago would indeed be now 25% slower to get it secure.

The other side of the coin though is are desktop users going to be vulnerable if you have to be exploiting at the machine with more or less direct access, thus most of the flaws dont need plugging as its not really going to effect the security?

I also highlighted the part which you have repeated as I am aware they can be selected - its not mandatory.

 

[Rroff]

Likewise, please READ what I said (in the first place) as it is a continuation of @Scougar question, I am answering this not your personal cherry picked patches - discussing ALL of them to see how badly the total impact is.

I addressed that in the first part of my post before mentioning my personal situation.

As I said if you apply all patches and mitigations it isn't like you suddenly get an overall slower CPU as per the implied posting from a couple of people in this thread - it isn't a situation where you suddenly see a 25% slowdown - it is a much more complex story than that.

Slow down and actually read what I'm saying before being so abrasive in reply.

 

[gpuerrilla]

As I said if you apply all patches and mitigations it isn't like you suddenly get an overall slower CPU as per the implied posting from a couple of people in this thread - it isn't a situation where you suddenly see a 25% slowdown - it is a much more complex story than that.

The 25% isnt something to latch on to. Its an arbitrary figure because its obviously greater than 0% but has to be something to quantify after all this time. Think of all the meltdown, spectre, ZombieLoad and the bucket full of microsoft OS patches on top, why dont you offer something to debate rather than trying to close it off as a nothing burger when it quite clearly is an impact worth exploring?

 

[Rroff]

The 25% isnt something to latch on to. Its an arbitrary figure because its obviously greater than 0% but has to be something to quantify after all this time. Think of all the meltdown, spectre, ZombieLoad and the bucket full of microsoft OS patches on top, why dont you offer something to debate rather than trying to close it off as a nothing burger when it quite clearly is an impact worth exploring?

I'm not trying to close it off - that is you reading intent. I don't have latest figures as most of the testing hasn't been updated but I'm just saying it isn't as simple as your processor now becoming 25% (or any other quantifying figure in that context) slower there are many many tasks where the performance hit is basically non-existent and other tasks that are more heavily hit so what any one user will see will depend a lot on their usage.

I can link to the previous articles where they've done testing but I'm not aware of anything that currently tests with the whole raft of mitigations.

 

[gpuerrilla]

Yeah, we aren't tying every person in with the broad range of pc setups as you cannot factor this in; likewise most users dont run PostgreSQL databases with thousands of logs etc. but your on an enthusiast forum specifically CPU's so to keep it manageable I am just segmenting it to regular desktops with production uses and gaming. The impact is going to be little - for each vulnerability. However like some articles state, when running intense benchmarks and synthetic tests where heavy load kicks in, they are saying it does impact performance in single digit percentages for modern generations, with older generations going into double digits.

Again I have yet to see follow up articles to the older spectre/meltdown pieces or any sites offering recent analysis to make it comparative. Surely though with the sheer volume of fixes being available and cve's outed there is enough layers stacking to make applications running now noticeably slower than two years back before the vulnerabilities came flooding in?

 

[Rroff]

Again I have yet to see follow up articles to the older spectre/meltdown pieces or any sites offering recent analysis to make it comparative. Surely though with the sheer volume of fixes being available and cve's outed there is enough layers stacking to make applications running now noticeably slower than two years back before the vulnerabilities came flooding in?

Some instructions won't have any additional layers to wade through - in other cases an instruction/function will be intercepted so to speak and a functionally equivalent set of safe instructions used which will cause a performance impact. In other cases it will be possible to blacklist or whitelist functionality so as to side step performance issues in some cases but not others. There isn't a default situation where all software is now faced with a bunch of mitigations or they are sitting there in the background always running. The point I'm trying to impress is that it is complex even in a desktop environment - you could do a bunch of tests and use the mean result as a quantity of the performance impact but that is somewhat subjective.

 

[IT Troll]

The situation is further complicated by the various hardware revisions that have been released over the period. I know for example that the RO stepping I have is slower at some tasks than the previous PO stepping, due to the security enhancements. Whilst for other tasks it is much faster because the mitigations have been moved into hardware and no longer require the software fixes. For example, restoring context switching back to it’s original performance levels.

 

[humbug]

@Th0nt the Difference with Ryzen is the data sits encrypted in memory so even if you could siphon it out you're getting nothing but gobbledygook. its why these Intel sponsored researchers simulated the L1 Cache and hacked it that way instead of actually just attacking the CPU, IMO its why AMD have said nothing other than "mitigations are already in place" those mitigations are the rest of the CPU.

 

[gpuerrilla]

@humbug the vulnerabilities will be found for all processor vendors and AMD will get some more attention I am sure over the next few months/year now that Ryzen is gaining some ground in the market. What I am seeking is some article or web page that has tracked or is tracking the flaws and mitigations to vendors to make it useful for users to see.

 

[IT Troll]

the Difference with Ryzen is the data sits encrypted in memory so even if you could siphon it out you're getting nothing but gobbledygook. its why these Intel sponsored researchers simulated the L1 Cache and hacked it that way instead of actually just attacking the CPU, IMO its why AMD have said nothing other than "mitigations are already in place" those mitigations are the rest of the CPU.

Although Ryzen supports memory encryption it is application dependent. It is often used in a VM hypervisor environment, but it is not on, all the time, for all apps. Even then, memory encryption is weak protection and can be subverted:
SEVered: Subverting AMD’s Virtual Machine Encryption
https://arxiv.org/pdf/1805.09604.pdf

These "Intel sponsored" researchers are also sponsored by AMD and ARM. Perhaps AMD withdrew funding for this paper to try to suppress the truth? (No, I don't actually think this)

I am not sure where you are getting "simulated" from. Yes, they reverse-engineered it to discover the vulnerability, but the resulting exploit applies to real hardware.

 

[Vince]

So has anybody actually read the paper from start to finish? I just finished reading it and although in parts I did get slightly lost, for the most part it's seems well written and quite clever. Having finished the paper I do think I agree with AMD in terms of there isn't really anything at this point to mitigate against. Having timing info or "meta data" around timings and addresses when there doesn't appear to be anything you can do with that bar build up a picture on address and cache layout, so foot-printing effectively, meaning that without some other exploit there isn't nowhere to go. When you get to the really juicy stuff so around 5.2 and onward it all seems to start being dependant on some pretty specific set of circumstances including what appears to be unpatched OS vulnerabilities in linux. It appears to me that that the only way you could make this work in an effective way or make it leak kernel memory is to be running an OS that hasn't been patched for Spectre.

Or have I just wasted 2 hours of my time trying to understand it? It's like having a map out of Alcatraz, you know the way but at the end there is a couple of miles of freezing cold sea between you and glory. Mind you understanding how it works and everything fits together is where all these things start. Probe it enough and get it to give up all of it's secrets and eventually a way in/out will be found.

 

[humbug]

What alarms me about this is the whole thing is "Theory" given they didn't actually hack in to a CPU, they just ran a simulation of the L2 Cache, this ignores completely the rest of the CPU.

Hack into an actual Ryzen CPU, if you can't do that then you have found nothing.

@IT Troll that's something different entirely...

 

[jigger]

So has anybody actually read the paper from start to finish? I just finished reading it and although in parts I did get slightly lost, for the most part it's seems well written and quite clever. Having finished the paper I do think I agree with AMD in terms of there isn't really anything at this point to mitigate against. Having timing info or "meta data" around timings and addresses when there doesn't appear to be anything you can do with that bar build up a picture on address and cache layout, so foot-printing effectively, meaning that without some other exploit there isn't nowhere to go. When you get to the really juicy stuff so around 5.2 and onward it all seems to start being dependant on some pretty specific set of circumstances including what appears to be unpatched OS vulnerabilities in linux. It appears to me that that the only way you could make this work in an effective way or make it leak kernel memory is to be running an OS that hasn't been patched for Spectre.

Or have I just wasted 2 hours of my time trying to understand it? It's like having a map out of Alcatraz, you know the way but at the end there is a couple of miles of freezing cold sea between you and glory. Mind you understanding how it works and everything fits together is where all these things start. Probe it enough and get it to give up all of it's secrets and eventually a way in/out will be found.

What I got from this is you could potentially get a hint of what is happening that might lead you to another hint. So you could possibly follow a chain of hints that may or may not lead something based on the OS playing ball.

I think it something worth being aware of but not much to be concerned about.

 

[IT Troll]

they didn't actually hack in to a CPU, they just ran a simulation of the L2 Cache, this ignores completely the rest of the CPU.

@IT Troll that's something different entirely...

I still don't understand where you are getting the simulated L1 & L2 cache from. They evaluate and benchmark their proof of concepts on a Threadripper 1920X and EPYC 7571.

I realise that the SEV vulnerability is something different, but it goes to demonstrate that encrypted memory is not some cast iron protection. Only blocking access in the first place is.

The researchers are saying the exploit still works on a fully patched system, whilst AMD are saying this is nothing new and mitigations are already in place. I suspect this will only serve to encourage the researchers to do more.

 

[humbug]

I still don't understand where you are getting the simulated L1 & L2 cache from. They evaluate and benchmark their proof of concepts on a Threadripper 1920X and EPYC 7571.

I realise that the SEV vulnerability is something different, but it goes to demonstrate that encrypted memory is not some cast iron protection. Only blocking access in the first place is.

The researchers are saying the exploit still works on a fully patched system, whilst AMD are saying this is nothing new and mitigations are already in place. I suspect this will only serve to encourage the researchers to do more.

Both are the same Zen 1 CPU under different names, and from 2017, Not 2019. Did they test Zen+ or Zen 2? As far as i can tell they also used Linux, not Windows. Anything beyond that is assumption. The researchers actually said this themselves. And AMD have responded, stating that Windows has already been patched for this exploit.

 

[Rroff]

whilst AMD are saying this is nothing new and mitigations are already in place.

I haven't actually read details on this one but from what I understand mitigations are available but not necessarily in use. TBH I'm largely unconcerned and not bothering my head about this one as while academically interesting and might lead to something in the future it is likely a few years before it is part of anything concerning if at all though I find the tired old BS downplaying/attempts to shift attention from certain people amusing and frustrating in equal measures.

 

[humbug]

I haven't actually read details on this one but from what I understand mitigations are available but not necessarily in use. TBH I'm largely unconcerned and not bothering my head about this one as while academically interesting and might lead to something in the future it is likely a few years before it is part of anything concerning if at all though I find the tired old BS downplaying/attempts to shift attention from certain people amusing and frustrating in equal measures.

Quite a lot of it is trivial tho Rroff. Windows has been patched, Coffeelake has some hardware mitigations and it doesn't seem to be bothering Intel much, infact its good for them as they gain sales from people having get more CPU's to make up for performance losses that the mitigations cause.
AMD have just won a massive Military contract involved in nuclear, not the type of people who would use hardware that is full of holes....

These researchers have found themselves in the limelight with funding pouring in, its in their interest to keep banging the drum.....

 

[ChrisLX200]

I can't say I understand the technicalities of these exploits at all, but I would suggest the OS installation most home users run has inherantly more liabilities than any CPU exploit offers.