Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

Page 64 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,619
136
Encryption methods that were security best practices in 1980 or 1990 are unsafe now because researchers discovered ways to crack them. If you find someone using those methods now then they need to change them, but it's wrong to say using those methods showed incompetence at that time.

Speculative execution methods used by intel and AMD were best practices at the time the CPUs were designed, until years later researchers discovered ways to leak information because of them.
Privilege checks were and are best practices at any and all time.
 

DaveSimmons

Elite Member
Aug 12, 2001
40,730
670
126
Privilege checks were and are best practices at any and all time.

None of these variants allow directly accessing protected resources. Researchers found a way to guess (leak) information as a side effect of the timing of execution that produced correct results.

However, it's not possible to "prove" intel, AMD and ARM designers acted correctly or incorrectly because that comes down to opinion. If you set up your assumptions correctly it's possible to decide only intel made mistakes, everyone made mistakes that should never have happened, or (my opinion) everyone made mistakes that are only mistakes in hindsight.
 

Markfw

Moderator Emeritus, Elite Member
May 16, 2002
25,478
14,434
136
None of these variants allow directly accessing protected resources. Researchers found a way to guess (leak) information as a side effect of the timing of execution that produced correct results.

However, it's not possible to "prove" intel, AMD and ARM designers acted correctly or incorrectly because that comes down to opinion. If you set up your assumptions correctly it's possible to decide only intel made mistakes, everyone made mistakes that should never have happened, or (my opinion) everyone made mistakes that are only mistakes in hindsight.
If you read back on this thread, SOMEWHERE they dexcribed this in detail. I will paraphrase.

Intel gets the information, and puts it in the cache (which one I don't know) Then when its ready to execute, at that time its checks privs. If its not allowed it does not continue, but by then, if you read the cache, that cats out of the bag. And this all happens in nano-seconds. So if you read the cache, and write the results somewhere that you can read in the future, you are in, and the information is leaked. AMD checks before it loads the cache.

Again, that a laymans paraphase of what I read.
 

DaveSimmons

Elite Member
Aug 12, 2001
40,730
670
126
If you read back on this thread, SOMEWHERE they dexcribed this in detail. I will paraphrase.

Intel gets the information, and puts it in the cache (which one I don't know) Then when its ready to execute, at that time its checks privs. If its not allowed it does not continue, but by then, if you read the cache, that cats out of the bag. And this all happens in nano-seconds. So if you read the cache, and write the results somewhere that you can read in the future, you are in, and the information is leaked. AMD checks before it loads the cache.

Again, that a laymans paraphase of what I read.

I think you're not quite right about that. Spectre doesn't let anyone directly read the cache, it's that the cache data can be slowly guessed by looking at the execution time for other, allowed code.

There's a pretty simple explanation in the first answer here: https://stackoverflow.com/questions...-attack-read-the-cache-it-tricked-cpu-to-load
 

Markfw

Moderator Emeritus, Elite Member
May 16, 2002
25,478
14,434
136
  • Like
Reactions: Drazick

naukkis

Senior member
Jun 5, 2002
701
569
136
Encryption methods that were security best practices in 1980 or 1990 are unsafe now because researchers discovered ways to crack them. If you find someone using those methods now then they need to change them, but it's wrong to say using those methods showed incompetence at that time.

Speculative execution methods used by intel and AMD were best practices at the time the CPUs were designed, until years later researchers discovered ways to leak information because of them.

Intel's way of doing things, eg allow speculative execution to load and use data which running process hasn't privileges isn't fine at all. Looks like Intel didn't care about security at all. If Intel would have documented openly how they have implement speculative execution Meltdown would have happen way sooner. And end result from Intel engineering is that no data is safe with Intel servers, for critical servers Intel cpu's need to be replaced soon, they cannot patch all vulrenabilities without disabling speculative execution.
 
  • Like
Reactions: DarthKyrie

naukkis

Senior member
Jun 5, 2002
701
569
136
If you read back on this thread, SOMEWHERE they dexcribed this in detail. I will paraphrase.

Intel gets the information, and puts it in the cache (which one I don't know) Then when its ready to execute, at that time its checks privs. If its not allowed it does not continue, but by then, if you read the cache, that cats out of the bag. And this all happens in nano-seconds. So if you read the cache, and write the results somewhere that you can read in the future, you are in, and the information is leaked. AMD checks before it loads the cache.

Again, that a laymans paraphase of what I read.

Nope, Intel load unprivileged data to cache and lets it's speculative execution to use it for calculations. Privileges are checked only when retiring instructions which gives plenty of time to side channel leaks. That using non-privileged data is way to leak data way too easily from CPU.
 
Last edited:

naukkis

Senior member
Jun 5, 2002
701
569
136
None of these variants allow directly accessing protected resources. Researchers found a way to guess (leak) information as a side effect of the timing of execution that produced correct results.

However, it's not possible to "prove" intel, AMD and ARM designers acted correctly or incorrectly because that comes down to opinion. If you set up your assumptions correctly it's possible to decide only intel made mistakes, everyone made mistakes that should never have happened, or (my opinion) everyone made mistakes that are only mistakes in hindsight.

Side-channels aren't a new thing, they are studied and discovered as early as 80's and 90's. Looks like Intel didn't just care, or there was some high profile manager that decides that perf/watt was more important than security. Like Intel was doing mobile processors not server grade. Which of course is what their cpu lines are about.

Why AMD didn't implement it also? Probably they have at least one security-oriented engineer on board that was able to tell that implementing such techniques would be high risk for business and existence for small company, if it was AMD and not Intel whom CPU's were melting down would probably led to AMD out of business, Intel instead seems to manage be just fine even with this kind of problems.
 

DaveSimmons

Elite Member
Aug 12, 2001
40,730
670
126
Side-channels aren't a new thing, they are studied and discovered as early as 80's and 90's. Looks like Intel didn't just care, or there was some high profile manager that decides that perf/watt was more important than security. Like Intel was doing mobile processors not server grade. Which of course is what their cpu lines are about.

Why AMD didn't implement it also? Probably they have at least one security-oriented engineer on board that was able to tell that implementing such techniques would be high risk for business and existence for small company, if it was AMD and not Intel whom CPU's were melting down would probably led to AMD out of business, Intel instead seems to manage be just fine even with this kind of problems.

AMD has its own speculative execution flaws, just not all of intel's. So apparently they "didn't care about security" either?

Or like I said, only obvious in hindsight.
 

french toast

Senior member
Feb 22, 2017
988
825
136
AMD has its own speculative execution flaws, just not all of intel's. So apparently they "didn't care about security" either?

Or like I said, only obvious in hindsight.
I am not sure that your black and white thinking applies, I mean if a Toyota has a 3% theft rate and a GM car has a 15% theft rate, (pretend obviously) in your scenario both manufacturers have failed their customers with security and are both equally to blame?.

What is the difference in number of vulnerabilities between zen Vs skylake to date?...if it is only 20% difference then yes you can group them together...but if it is multiples..that is another story, every product will have some design faults/security issues to some extent, it is just whether they are far and few between or are negligently so numerous and severe or not.

Honest question, how big is the difference?
 

naukkis

Senior member
Jun 5, 2002
701
569
136
AMD has its own speculative execution flaws, just not all of intel's. So apparently they "didn't care about security" either?

Or like I said, only obvious in hindsight.

Yes they have and all of speculative executive flaws cannot even fixed at all. But obviously stupid decisions can be fixed and prevent cpu's from leaking kernel data to user level programs. Intel hardware fix will be coming soon, it's not total fix for speculative execution flaws but it will do privilege checks for data as it should, before execution and bring cpu's security to same level as it is now with AMD.

Why isn't any hardware site do a story that don't buy Meltdown cpu's for server use - they aren't suitable for that kind of use, or if there isn't alternatives at least get promise from hardware provider to offer free upgrade to fixed hardware when it come available, this kind of security flaw isn't tolerable.
 

PotatoWithEarsOnSide

Senior member
Feb 23, 2017
664
701
106
Until there's a real world attack, you won't get anyone advising customers not to purchase the relevant CPUs, simply because the potential costs of any legal challenge being made by Intel would be so high.​
 

naukkis

Senior member
Jun 5, 2002
701
569
136
Until there's a real world attack, you won't get anyone advising customers not to purchase the relevant CPUs, simply because the potential costs of any legal challenge being made by Intel would be so high.​

Now there's ongoing continuous patching systems against possible leaks - and so far it isn't looking like it's stopping. It has to be real pain in ass for system operators and I can't see how Intel could sue anybody who's recommending to not buying faulty hardware which operating expenses, downtime and hassle is unavoidable - and data leaking is always possible.

And it's pretty sure that Intel's commitment to patch systems with minimal performance affect will be lowering pretty much when they get fixed hardware out - and pretty sure recommendations to patch out faulty hardware will come sooner or later.
 

positivedoppler

Golden Member
Apr 30, 2012
1,103
171
106
Until there's a real world attack, you won't get anyone advising customers not to purchase the relevant CPUs, simply because the potential costs of any legal challenge being made by Intel would be so high.​

We're worried about Russia but China is owning everyone.
https://m.scmp.com/tech/article/213...rsecurity-experts-global-hacking-competitions
https://www.cyberscoop.com/pwn2own-chinese-researchers-360-technologies-trend-micro/

How do we know there is no real world exploit of these flaws? The top hacking nation on earth is not going to advertise, hey look guys we did it!
 

DaveSimmons

Elite Member
Aug 12, 2001
40,730
670
126
I don't think that's true at all. There were specific rules put in place to avoid these attacks. Intel made a decision to ignore those rules because it was quicker to ignore them.

And so did AMD for multiple Spectre variants. Also ARM. Hindsight is 20-20.
 

naukkis

Senior member
Jun 5, 2002
701
569
136
And so did AMD for multiple Spectre variants. Also ARM. Hindsight is 20-20.

There's two kind of out-of-order cpus, those which are melting down with side-channel attacks and those which aren't. Intel and some ARM designs are melting down, and from those ARM designs were mobile designs not so server-oriented.

Those cpu's which are melting with security practically haven't any kind of security against side-channel attacks, those allow speculative instructions to do anything so voiding all security features build to cpu. Spectre V3 aka Meltdown should not have happened, it's direct reading unprivileged memory which resulted that OS's have to redesigning to have at least some kind of protective memory boundaries - but as Meltdown was about the simplest possible way to read unprivileged data it's was certain that other possibilities will to be found.

But that's not even hindsight to tell people voiding Meltdown-vulnerable CPUs for server use after those were found, it should be plain obvious. Everything is broke, sandboxed bytecode applications can break out of sandboxes to run cpu native code for side-channel attacks and many more which just can't be happening with server-oriented cpu.
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,619
136
OpenBSD's Theo de Raadt is probably the most vocal critic of Intel right now, suggesting to disable HT which he considers fundamentally broken. What some people may not be aware of is that he already complained about the specific parts of Intel Core 2 back in June 2007.

"These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.
"
"- Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).
- Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences.
"
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

Coincidence? Prescient? It's certainly interesting that that time might also mark the point Intel redefined the implementation of MMU, something that made Meltdown possible at all, where today Intel claims everything works as intended.
 

dualsmp

Golden Member
Aug 16, 2003
1,626
44
91
OpenBSD's Theo de Raadt is probably the most vocal critic of Intel right now, suggesting to disable HT which he considers fundamentally broken. What some people may not be aware of is that he already complained about the specific parts of Intel Core 2 back in June 2007.

"These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.
"
"- Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).
- Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences.
"
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

Coincidence? Prescient? It's certainly interesting that that time might also mark the point Intel redefined the implementation of MMU, something that made Meltdown possible at all, where today Intel claims everything works as intended.

Theo made this comment just two days ago:

https://marc.info/?l=openbsd-tech&m=153504937925732&w=2

"A few months back, I urged people to disable hyperthreading on all Intel cpus. I need to repeat that:

DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS.

Also, update your BIOS firmware, if you can.

OpenBSD -current (and therefore 6.4) will not use hyperthreading if it is enabled, and will update the cpu microcode if possible."
 

thecoolnessrune

Diamond Member
Jun 8, 2005
9,670
571
126
I'm hearing from vendors that certifications are going to go out even later on Cascade Lake (VMWare, Nutanix, NetApp, and a couple others I spoke with) compared to previous platforms while they're auditing and developing around the new hardware mitigations. Sounds like while the new platforms will be here in not too long, it will be a little while before we're running validated software on it.