Security Implications of AMD’s Cache Way Predictors - funding by Intel

ChadD said:
This is basically a non story. The headline should read. "Paid Intel researcher... finds way to compromised ANY CPU running a custom hacked Kernel. " This is all tripe. Side channel attacks are possible ON any CPU with any form of cache speculation even if its been patched in hardware to not give user land software kernel access.... if you run a modified kernel that has had its permissions bits tossed and flipped.
Click to expand...

One of the PhD students involved in the paper had funding from Intel, that's it. There is absolutely zero evidence of anything shady going on on. Don't try to turn this into anything that it isn't. The whole thing should simply be "New AMD flaw found, already fixed". Simple as that. The only reason to even mention Intel involvement is for the purposes of mudslinging when it isn't even warranted.
 
ChadD said:
One company has a track record of including hardware security holes in hardware years after they come to light. The other has a track record of taking some pretty big design risks while somehow still not doing stupid things like allowing software to read random bits of cache without permission. lol
Yes Intel has fixed a lot of their terrible caching systems that where ignoring basic permission security.... as long as you buy the right stepping at least. Intel has a habit of selling older steppings for years cause they are so far behind the eight ball on demand. I'm sure its not a problem for big clients... but smaller customers get whatever Intel can get out the door. You can still buy brand new Intel chips with steppings with less then all their current hardware mitigation included.

This AMD vulnerability may never be "fixed" in hardware as its not really a flaw. Its working as intended. It can be exploited by software... and its software that needs to mitigate it. The hardware isn't doing anything really dangerous. Nothing more then a standard speculation engine anyway. You can't exploit this with standard software.

As Charlie Demerjian from semi accurate said on twitter...
" So I read the AMD Takeaway paper and, well, it is another Spectre attack. It isn't a hardware flaw and anyone who claims it is didn't read the paper or doesn't understand jack all about side channels and security. It is real but it is mostly a software problem. "

IMO this isn't a major exploit.... you can use this to read a bit of memory you shouldn't be able to but NOT anything kernel related. The chip still does what its supposed to and does check if the software has permission to retreive anything from kernel space before handing it over. (unlike chips produced by someone else) In order to achieve this novel AMD exploit... this research had to run a custom kernel. That part will be left out in Intel marketing. Running on a standard non modified kernel this exploit won't do much of anything accept perhaps read some data from other USER space software. Its not going to be pulling Crypto keys or anything important out of kernel space without the nefarious software somehow first managing to completely replace the kernel with a custom kernel with software permissions hinked up.

This is basically a non story. The headline should read. "Paid Intel researcher... finds way to compromised ANY CPU running a custom hacked Kernel. " This is all tripe. Side channel attacks are possible ON any CPU with any form of cache speculation even if its been patched in hardware to not give user land software kernel access.... if you run a modified kernel that has had its permissions bits tossed and flipped.
Click to expand...

Spectre and Meltdown came at a very bad time for Intel, right as they were about to transition to a new architecture but got delayed again and again due to process issues. That's why they're not fully fixed in hardware today, because today's Intel chips are essentially a tweaked Skylake architecture from 2015, which meant the processor was designed in 2013-2014. Only simple fixes that required no major rework of the architecture were implemented. The real fixes will come when Intel finally gets 10nm and 7nm working. Additionally, now that Intel knows that jumping to a new process node every 2 years is no longer feasible, they should be planning for improved architectures for each time they do a node improvement (the + part). Yes, a series of bad decisions did contribute to where Intel is today, but the process issues are the primary reason fixes aren't in place yet.

It was a university group that pokes at everything they can find. It was not paid by Intel to specifically look for AMD exploits, it's sponsoring university groups to foster talent. They properly notified AMD about the exploit they found 6 months ago, and are only releasing the details today. They probably did not get a confirmation that the exploit was fixed or already mitigated, hence the lack of detail on what AMD has done in the initial news release.
 
Tsumi said:
Spectre and Meltdown came at a very bad time for Intel, right as they were about to transition to a new architecture but got delayed again and again due to process issues. That's why they're not fully fixed in hardware today, because today's Intel chips are essentially a tweaked Skylake architecture from 2015, which meant the processor was designed in 2013-2014. Only simple fixes that required no major rework of the architecture were implemented. The real fixes will come when Intel finally gets 10nm and 7nm working. Additionally, now that Intel knows that jumping to a new process node every 2 years is no longer feasible, they should be planning for improved architectures for each time they do a node improvement (the + part). Yes, a series of bad decisions did contribute to where Intel is today, but the process issues are the primary reason fixes aren't in place yet.

It was a university group that pokes at everything they can find. It was not paid by Intel to specifically look for AMD exploits, it's sponsoring university groups to foster talent. They properly notified AMD about the exploit they found 6 months ago, and are only releasing the details today. They probably did not get a confirmation that the exploit was fixed or already mitigated, hence the lack of detail on what AMD has done in the initial news release.
Click to expand...

Well intel has shipped 10nm parts and they are not completely mitigated vs side channel stuff. And granted its impossible to protect against every possible side channel in hardware. However Intels 10nm are still less mitigated vs AMD ARM and IBM chips. I'm not sure the we are having problems with our fancy new fabs is a real excuse. Not wanting to spin their old 14nm fabs down long enough to retool is more likely a reason for rehash parts that are still not properly mitigated. You need a spreed sheet to figure out which of Intels chips need software mitigation enabled and which don't. There really isn't an excuse for Intel having 3-4 steppings for say coffee lake parts... where only one if fully mitigated and they are not only selling but still producing all of them.

As for why they never heard anything from AMD... cause there isn't anything for AMD to do. This "Exploit" only works on modified kernels. In otherwords. It doesn't work on a standard Linux BSD OSx or windows install. If your exploit requires you to replace a systems kernel first.... then almost any CPU feature can be twisted into a exploit. The only thing this has in common with earlier side channel stuff is that its a timing attack. But it only works if you first modify the kernel... if you don't do that the CPU rejects your reads. Modifying a kernel in the same way you should be able to perform side channel attacks on CPUs that have been mitigated.

This exploit... would be like failing a car in an emissions test after the tester takes a hammer and knocks off the muffler.
 
ChadD said:
Well intel has shipped 10nm parts and they are not completely mitigated vs side channel stuff. And granted its impossible to protect against every possible side channel in hardware. However Intels 10nm are still less mitigated vs AMD ARM and IBM chips. I'm not sure the we are having problems with our fancy new fabs is a real excuse. Not wanting to spin their old 14nm fabs down long enough to retool is more likely a reason for rehash parts that are still not properly mitigated. You need a spreed sheet to figure out which of Intels chips need software mitigation enabled and which don't. There really isn't an excuse for Intel having 3-4 steppings for say coffee lake parts... where only one if fully mitigated and they are not only selling but still producing all of them.

As for why they never heard anything from AMD... cause there isn't anything for AMD to do. This "Exploit" only works on modified kernels. In otherwords. It doesn't work on a standard Linux BSD OSx or windows install. If your exploit requires you to replace a systems kernel first.... then almost any CPU feature can be twisted into a exploit. The only thing this has in common with earlier side channel stuff is that its a timing attack. But it only works if you first modify the kernel... if you don't do that the CPU rejects your reads. Modifying a kernel in the same way you should be able to perform side channel attacks on CPUs that have been mitigated.

This exploit... would be like failing a car in an emissions test after the tester takes a hammer and knocks off the muffler.
Click to expand...

It works if you consider that Ice Lake should have been in design around 2015, since the expectation was that 10nm would be ready by 2017. Spectre and Meltdown were disclosed in 2018, which would have been at the tail end if not after Ice Lake's final design had been approved. There shouldn't be any excuses once Intel goes to 10nm++ or 7nm though, as any chips on those processes should have been designed after the exploits were released. Well, 10nm++ might just be a tweak of Ice Lake, so there is some leeway there. Definitely not 10nm+++ or 7nm.
 
Derangel said:
Did you even read the tweet? That group has found more Intel problems than any other platforms. Based on the guy’s profile it looks like they’re the ones that found Zombieload, Meltdown, and Spectre.
Click to expand...
What is your point? Nobody denies that this security vulnerability that can be mitigated from software actually exist. But the wording makes it sound much worse than it is. Like some gotcha to "prove" that AMD is no better than Intel in HW security.
 
M76 said:
What is your point? Nobody denies that this security vulnerability that can be mitigated from software actually exist. But the wording makes it sound much worse than it is. Like some gotcha to "prove" that AMD is no better than Intel in HW security.
Click to expand...

You are only reading what you want it to say. The title of the research paper is the exact same as all of their research papers.
 
Based on what we've learned, it sounds like the people screaming "omg Intel-funded conspiracy!" are just looking for a reason to be outraged. It's more reassuring to adopt a simplistic view where you're sticking it to The Man(tm) than to accept the nuanced reality where Intel's funding doesn't appear to have influenced the outcome in a meaningful way.
 
OK calm down everyone. This vulnerability. Is in old (and still good) cpus from amd. It doesn't exist in current amd cpu's. And it aparrently requires modifying the kernel to exploit the vulnerability if you can even call it one at that point. I need to read the ops article again to see if a cve was even issued.
 
DooKey said:
Who cares who funded it? If AMD has vulnerabilities we need to know about it.
Click to expand...
That's the thing, it's using already mitigated things,.it's not even a new vulnerability, just another way to use an existing one that has since been patched. Calling it severe or new is misleading at best.
 
We reverse-engineered AMD’s L1D cache way predictor in microarchitectures from 2011 to 2019, resulting in two new attack techniques.
Click to expand...

So Intel paid a university to reverse engineer a competitor's logic? Ahaha.
In any case, finding these security flaws is a good thing - doesn't matter who funded it.
 
tweret.png


this team is as disingenuous as fucking CTS labs

intel should ask for it's money back

maybe they could by a new + for 14nm
 
Aurelius said:
Based on what we've learned, it sounds like the people screaming "omg Intel-funded conspiracy!" are just looking for a reason to be outraged. It's more reassuring to adopt a simplistic view where you're sticking it to The Man(tm) than to accept the nuanced reality where Intel's funding doesn't appear to have influenced the outcome in a meaningful way.
Click to expand...

What we've learned is that this is a farce. It's one thing to have a real flaw but this isn't it. Simplistic view is BS, reality is more nuanced. Half the news out there is fake or disinformation. This included....
 
Master_shake_ said:
View attachment 228668

this team is as disingenuous as fucking CTS labs

intel should ask for it's money back

maybe they could by a new + for 14nm
Click to expand...
Holy shit someone on the internet actually quoted me lol.

Yeah this "exploit" is really overblown. Within hours of spectre/meltdown there were local userspace apps stealing keys right out of memory. This is no more than a metadata attack which can be used with conjoined attacks of course and yes you can technically get the metadata remotely using javascript, with that user installed kernel module lol.

The only interesting part is the novel covert IPC with a whopping 0.5Mbs data rate.

Edit: The actual paper for anyone to read and please let me know if I'm absolutely wrong here. It's been awhile since I was hardcore into uarch design.
https://mlq.me/download/takeaway.pdf
 
schoolslave said:
So Intel paid a university to reverse engineer a competitor's logic? Ahaha.
In any case, finding these security flaws is a good thing - doesn't matter who funded it.
Click to expand...
It does matter when it's a complete BS piece. They used an already mitigated issue and had to use a custom kernel mod to do it. Sorry, but if someone is already modifying your kernel you've got more issues than this.
 
Ready4Dis said:
It does matter when it's a complete BS piece. They used an already mitigated issue and had to use a custom kernel mod to do it. Sorry, but if someone is already modifying your kernel you've got more issues than this.
Click to expand...

That depends. There are and will be more kernel exploits. Hardening security on the software *and* hardware side is not a bad thing at all.
This does mean we should embrace research like this, point out the flaws where necessary, and hope that the researchers continue their work.

I will admit that there is an increasingly large focus on "sensational exploits" instead of actual research unfortunately.
This discredits the other, thorough work and creates distrust and skepticism towards new exploits.
I'm not entirely convinced this paper falls into that category though.
 
schoolslave said:
That depends. There are and will be more kernel exploits. Hardening security on the software *and* hardware side is not a bad thing at all.
This does mean we should embrace research like this, point out the flaws where necessary, and hope that the researchers continue their work.

I will admit that there is an increasingly large focus on "sensational exploits" instead of actual research unfortunately.
This discredits the other, thorough work and creates distrust and skepticism towards new exploits.
I'm not entirely convinced this paper falls into that category though.
Click to expand...
This was the point, this is a sensational piece. Real exploits are another story. To say it's "severe" and then state that it required custom kernels modifications to exploit an already mitigated exploit seems to be misleading. In reality the original (mitigated) cache issue should have been considered severe, not an exploit that requires kernel modifications and uses an already mitigated attack vector. If the paper said "a novel approach to using an existing known exploit"... Then sure, I'd agree with you, I think research is good and finding issues is good. When the conclusion doesn't match the results and you start wondering why, then you see it was funded by a companies main competitor, it doesn't take a genius to add 1+1.
 
The real question you all should be asking is, where is AMD's funded researchers who look for security flaws? Are there any?
 
Ready4Dis said:
This was the point, this is a sensational piece. Real exploits are another story. To say it's "severe" and then state that it required custom kernels modifications to exploit an already mitigated exploit seems to be misleading. In reality the original (mitigated) cache issue should have been considered severe, not an exploit that requires kernel modifications and uses an already mitigated attack vector. If the paper said "a novel approach to using an existing known exploit"... Then sure, I'd agree with you, I think research is good and finding issues is good. When the conclusion doesn't match the results and you start wondering why, then you see it was funded by a companies main competitor, it doesn't take a genius to add 1+1.
Click to expand...

How is it sensational? They found a thing, reported it to AMD, wrote a paper, and moved on. The only people making a big deal out of it are the people freaking the fuck out over them mentioning Intel. They never call it severe, the word does not even appear once in the paper.
 
schoolslave said:
That depends. There are and will be more kernel exploits. Hardening security on the software *and* hardware side is not a bad thing at all.
This does mean we should embrace research like this, point out the flaws where necessary, and hope that the researchers continue their work.

I will admit that there is an increasingly large focus on "sensational exploits" instead of actual research unfortunately.
This discredits the other, thorough work and creates distrust and skepticism towards new exploits.
I'm not entirely convinced this paper falls into that category though.
Click to expand...

Well this would take more then a simple kernel exploit... its a custom kernel that is ignoring memory read permissions that isn't a minor change of a few bits. You can't make these types of changes to a running kernel. You would have to replace it. There isn't a java script that is going to run over a browser or something that is going to tell your kernel to stop doing basic memory permission checks so it can over right the bits required. Nor one that is going to replace your kernel.

This exploit if we are still calling that... requires not only local access, but replacing a kernel. That is unrealistic. Its not as simple as installing something with local admin access. It requires convincing a running system to replace its kernel with a bogus one. Even in desktop focused OSes that isn't something that is easy to do. I mean nothing is impossible... however doing this to install a fairly shitty meta data read based on a cache timing. Its silly... unless that is your thing.... I guess there could be some nefarious Rube Goldberg devotes in the hacking community. lmao ;)

What makes this one completely over the top silly .... is this is a already mitigated "exploit". By the logic these guys employed.... forcing a kernel to turn off Specter/Meltdown mitigation would mean every Intel chip around is still vulnerable as well. Even intels newest chips rely on a mix of hardware and software mitigation to protect against side channels. If I can replace your kernel... or frankly I don't even need to do that the shipping kernels today have flags to disable specter mitigation they just need to be toggled. Then I can use all those much more effective side channel attacks.
 
Last edited:
ChadD said:
Well this would take more then a simple kernel exploit... its a custom kernel that is ignoring memory read permissions that isn't a minor change of a few bits. You can't make these types of changes to a running kernel. You would have to replace it. There isn't a java script that is going to run over a browser or something that is going to tell your kernel to stop doing basic memory permission checks so it can over right the bits required. Nor one that is going to replace your kernel.

This exploit if we are still calling that... requires not only local access, but replacing a kernel. That is unrealistic. Its not as simple as installing something with local admin access. It requires convincing a running system to replace its kernel with a bogus one. Even in desktop focused OSes that isn't something that is easy to do. I mean nothing is impossible... however doing this to install a fairly shitty meta data read based on a cache timing. Its silly... unless that is your thing.... I guess there could be some nefarious Rube Goldberg devotes in the hacking community. lmao ;)
Click to expand...

Sounds like it doesn't actually require physical access.

https://twitter.com/misc0110/status/1236411870313144320

It's still not a huge issue (something one of the paper's authors even says) but let's not get the details too mixed up.
 
Derangel said:
Sounds like it doesn't actually require physical access.

https://twitter.com/misc0110/status/1236411870313144320

It's still not a huge issue (something one of the paper's authors even says) but let's not get the details too mixed up.
Click to expand...

True if you have a system with a compromised kernel you can run this remotely.

But first you have to have a system with a compromised kernel. That is very difficult to achieve remotely.

This would be like someone claiming specter and meltdown on Intel chips is still good to go... because the hardware isn't fixed. The software is... but if I can replace the kernel with a old version or remotely flip the -no mitigation flags on, I can still remotely use specter and meltdown.

That is true I can do that.... so how is it news that you can do the same on AMD. If you can roll back a kernel a few years... ya you can do all manner of nasty things. Intel AMD IBM ARM... if I can force any system to run a 3 year old kernel, I can use all the stuff that has been patched since. This isn't really news.
 
ChadD said:
True if you have a system with a compromised kernel you can run this remotely.

But first you have to have a system with a compromised kernel. That is very difficult to achieve remotely.

This would be like someone claiming specter and meltdown on Intel chips is still good to go... because the hardware isn't fixed. The software is... but if I can replace the kernel with a old version or remotely flip the -no mitigation flags on, I can still remotely use specter and meltdown.

That is true I can do that.... so how is it news that you can do the same on AMD. If you can roll back a kernel a few years... ya you can do all manner of nasty things. Intel AMD IBM ARM... if I can force any system to run a 3 year old kernel, I can use all the stuff that has been patched since. This isn't really news.
Click to expand...

I mean...It really isn't news. It's a published research paper that people decided to freak out over and turn it into something it never was. If Intel's name hadn't been mentioned no one would give a shit about this paper. However, because Intel was indirectly involved, people decided to freak out and make it seem like the paper was something it isn't.
 
DooKey said:
Who cares who funded it? If AMD has vulnerabilities we need to know about it.
Click to expand...

Do you seriously not vet sources for news you read? A paper is released about AMD and the authors just happen to mention "additional funding was provided by generous gifts from [the only major competitor to AMD]." While you are correct that yes, we do need to know about vulnerabilities, this is such an obvious red flag that not noting it is essentially not providing the whole story.

These types of "generous gifts" often come with the right for the donator to suppress results they don't like, which we've seen with tobacco companies funding studies on the effects of smoking or oil companies funding studies on climate change or other environmental impacts. There's a reason why "follow the money" is a common phrase, so when something does get published and it was funded by Intel and it appears to be a hit piece on their director competitor, it may just behoove everyone here to ask some additional questions instead of saying "who cares who funded it?"
 
Aix. said:
Do you seriously not vet sources for news you read? A paper is released about AMD and the authors just happen to mention "additional funding was provided by generous gifts from [the only major competitor to AMD]." While you are correct that yes, we do need to know about vulnerabilities, this is such an obvious red flag that not noting it is essentially not providing the whole story.

These types of "generous gifts" often come with the right for the donator to suppress results they don't like, which we've seen with tobacco companies funding studies on the effects of smoking or oil companies funding studies on climate change or other environmental impacts. There's a reason why "follow the money" is a common phrase, so when something does get published and it was funded by Intel and it appears to be a hit piece on their director competitor, it may just behoove everyone here to ask some additional questions instead of saying "who cares who funded it?"
Click to expand...

According to one the authors, who is also an assistant professor at the school, Intel didn't directly fund the paper itself. They provide funding for two of his PhD students. So, should one or both of them serve as co-authors on a paper then the funding source needs to be mentioned.

This Zombieload paper also had the note about Intel funding.
 
Aix. said:
Do you seriously not vet sources for news you read? A paper is released about AMD and the authors just happen to mention "additional funding was provided by generous gifts from [the only major competitor to AMD]." While you are correct that yes, we do need to know about vulnerabilities, this is such an obvious red flag that not noting it is essentially not providing the whole story.

These types of "generous gifts" often come with the right for the donator to suppress results they don't like, which we've seen with tobacco companies funding studies on the effects of smoking or oil companies funding studies on climate change or other environmental impacts. There's a reason why "follow the money" is a common phrase, so when something does get published and it was funded by Intel and it appears to be a hit piece on their director competitor, it may just behoove everyone here to ask some additional questions instead of saying "who cares who funded it?"
Click to expand...
Take your tin foil hat off, you realize there are a lot of big companies out there that funds researchers at the University level, I would have more issues if it wasn't properly disclose where their funding source. If you read the paper itself, the exploit isn't even serious and they have notify AMD 6 month prior. Like Derangel said, this wouldn't be even news if Intel name wasn't attach to its funding source.
 
Derangel said:
I would argue that the people trying to turn this into a big deal and making wild claims are the ones grasping at straws.
Click to expand...

oh for sure not the researchers who used a modified kernel with no fixed mitigations to screw with the leader in CPU manufacturing not them and their grasping at straws nope.
 
Master_shake_ said:
oh for sure not the researchers who used a modified kernel with no fixed mitigations to screw with the leader in CPU manufacturing not them and their grasping at straws nope.
Click to expand...

You do realize that no one involved with the paper has tried to make it sound like a major problem, right? And the ONLY reason people like you are losing their shit is that Intel is mentioned.
 
Chimpee said:
Take your tin foil hat off, you realize there are a lot of big companies out there that funds researchers at the University level, I would have more issues if it wasn't properly disclose where their funding source. If you read the paper itself, the exploit isn't even serious and they have notify AMD 6 month prior. Like Derangel said, this wouldn't be even news if Intel name wasn't attach to its funding source.
Click to expand...

That's exactly what I said: my response was to someone who said "who cares who funded it?" It's not tin foil hat stuff to vet your sources by questioning who paid for them, who controls the medium of the message, etc.
 
Derangel said:
You do realize that no one involved with the paper has tried to make it sound like a major problem, right? And the ONLY reason people like you are losing their shit is that Intel is mentioned.
Click to expand...
They tried to make it an actual problem. Which it isn't at all in the slightest.
 
Master_shake_ said:
They tried to make it an actual problem. Which it isn't at all in the slightest.
Click to expand...

Okay. Show me a single co-author trying to make this out to be an actual, serious problem. The paper is neutral in tone and doesn't try to sensationalize anything. The ONLY people making this out to be more than what it says it is are people like you that want to throw a shit fit because Intel was, indirectly, involved. Not every published research paper like this is "trying to make" something a problem.

PS: If the kernel bit people are harping on was such a big deal, AMD would have called it out in their acknowledgement of the paper. They don't, which means IT ISN'T SOMETHING TO PISS AND MOAN ABOUT.
 
Aix. said:
That's exactly what I said: my response was to someone who said "who cares who funded it?" It's not tin foil hat stuff to vet your sources by questioning who paid for them, who controls the medium of the message, etc.
Click to expand...
I stand corrected, sorry I misinterpret your message and the tin foil comment.
 
  • Like
Reactions: Aix.
like this
Derangel said:
Okay. Show me a single co-author trying to make this out to be an actual, serious problem. The paper is neutral in tone and doesn't try to sensationalize anything. The ONLY people making this out to be more than what it says it is are people like you that want to throw a shit fit because Intel was, indirectly, involved. Not every published research paper like this is "trying to make" something a problem.

PS: If the kernel bit people are harping on was such a big deal, AMD would have called it out in their acknowledgement of the paper. They don't, which means IT ISN'T SOMETHING TO PISS AND MOAN ABOUT.
Click to expand...
all the authors are making this an issue, which it isn't

that's the point.
 
You must log in or register to reply here.
Back
Top