A Massive Intel Hardware Bug May Be on the Horizon

atarione said:
could be worse... news could have broke AFTER... I had pulled the trigger on an upgrade from my i7-4770K =)

but yeah..... this does sort of suck... AMD may however be slightly pleased currently.. I had been a pretty loyal team Red guy for many years, finally relenting to Intel's pretty clear advantage back in the C2D days...

next upgrade could be to AMD however... waiting on ryzen+
Click to expand...

I am sure AMD is quite pleased about this if Intel cant fix it with a microcode update. If this also effects Windows users as rumored then I expect a massive lawsuit on Intel as big companies will be pissed as well if they suddenly have their servers run slower. This is all kinds of ugly for Intel if the whole rumor is true, looks like January 4th is the supposed embargo date so will know soon.
 
This is bringing back memories of the Phenom TLB bug.
Still have one of those (as well as a FDIV affected Pentium) around :)
 
Armenius said:
The codebase looks like it is affecting both Intel and AMD going by the comments?

Code: 
+ * User space process size. This is the first address outside the user range.
+ * There are a few constraints that determine this:
+ *
+ * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
+ * address, then that syscall will enter the kernel with a
+ * non-canonical return address, and SYSRET will explode dangerously.
+ * We avoid this particular problem by preventing anything executable
+ * from being mapped at the maximum canonical address.
+ *
+ * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
+ * CPUs malfunction if they execute code from the highest canonical page.
+ * They'll speculate right off the end of the canonical space, and
+ * bad things happen. This is worked around in the same way as the
+ * Intel problem.
+ *
+ * With page table isolation enabled, we map the LDT in ... [stay tuned]
*/
#define TASK_SIZE_MAX ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
https://git.kernel.org/pub/scm/linu.../?id=5aa90a84589282b87666f92b6c3c917c8080a9bf

I guess you get more page hits by only going after Intel.
Click to expand...

Spot on. Also why AMDs request to be removed have been denied.
 
Shintai said:
Spot on. Also why AMDs request to be removed have been denied.
Click to expand...

Show it's been denied and not only that but if you read through the thread this is a different issue then the one were talking about. The patch as of now will hurt any x86 cpu, we dont know if that will change or not.

naib said:
No, two separate issues.

The AMD/Ryzen issue is associated with a memory hole causing hard lockups. The recomendation until now, for those affected by early Ryzen hardware issues, was to disable ASLR: https://wiki.gentoo.org/wiki/Ryzen#Troubleshooting this gentoo wiki page has the confirmed issues and potential work arounds

The Intel one is associated with this bug.

--edit--
This is the discussion of the linux fix

https://lkml.org/lkml/2017/12/27/2

Code: 
+   if (c->x86_vendor != X86_VENDOR_AMD)
+        setup_force_cpu_bug(X86_BUG_CPU_INSECURE);


--edit--
This is the actual commit to kernel.git
https://git.kernel.org/pub/scm/linu...c?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd

Code: 
+    /* Assume for now that ALL x86 CPUs are insecure */
+    setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

The proposed commit targeted non-AMD, the actual commit err'ed on the safe side until it is confirmed it doesn't affect AMD.

SHIT!! my linux-based gentoo setup is going to be slowed down in 4.15... I might stick with 4.14 a bit longer
Click to expand...
 
This really does smack of something where individuals may want an option to opt-out, if the remedies remain so heavy-handed. The brute force approach is fine for a "security above all else" hotfix, but seems horrendous for the rank-and-file who are not under significant local process security threat.

I'm cautiously optimistic both vendors will produce something less drastic in the coming days as it is almost certainly an all-hands-on-deck situation.
 
PhaseNoise said:
This really does smack of something where individuals may want an option to opt-out, if the remedies remain so heavy-handed. The brute force approach is fine for a "security above all else" hotfix, but seems horrendous for the rank-and-file who are not under significant local process security threat.

I'm cautiously optimistic both vendors will produce something less drastic in the coming days as it is almost certainly an all-hands-on-deck situation.
Click to expand...

They did that for the TLB errata on AMD side but considering this a security hole, I doubt it.
 
No matter how huge this fuck up is it will not affect them as greatly as we may think. The big companies will be given some discounts on next gen tech and will keep quiet. Law suites. Good luck with that. Its just us little people that are truly affected as mentioned a few comments up.
 
Imhotep said:
No matter how huge this fuck up is it will not affect them as greatly as we may think. The big companies will be given some discounts on next gen tech and will keep quiet. Law suites. Good luck with that. Its just us little people that are truly affected as mentioned a few comments up.
Click to expand...

The consumer is pretty much unaffected. The only one affected is the datacenter people. Anything in user space is not affected. in any meaningful way So no or very little impact to gaming, encoding, rendering etc.
 
Shintai said:
The consumer is pretty much unaffected. The only one affected is the datacenter people. Anything in user space is not affected. in any meaningful way So no or very little impact to gaming, encoding, rendering etc.
Click to expand...

I/O seems to take a hit.
 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1553070.html

:LOL:

Code: 
2) Namespace

      Several people including Linus requested to change the KAISER name.

      We came up with a list of technically correct acronyms:

          User Address Space Separation, prefix uass_

          Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_

      but we are politically correct people so we settled for

        Kernel Page Table Isolation, prefix kpti_

      Linus, your call :)
 
My thoughts on this are ... WOW. The tech industry has started 2018 with a BANG! My concerns about this don't revolve around Intel vs AMD. This is much bigger than that. There is also something to be said on the dangers of having a single supplier of technology and I believe the industry is going to react to this in a big way.
 
martinmsj said:
My thoughts on this are ... WOW. The tech industry has started 2018 with a BANG! My concerns about this don't revolve around Intel vs AMD. This is much bigger than that. There is also something to be said on the dangers of having a single supplier of technology and I believe the industry is going to react to this in a big way.
Click to expand...

Totally agree. Always amazed at the twists and turns in the industry- especially since I do a lot of data center work as well.

This one looks like a showstopper. If my VMWare boxes take a 15-30 percent hit it will trigger a lot of problems.
 
Spirit_Retro said:
Totally agree. Always amazed at the twists and turns in the industry- especially since I do a lot of data center work as well.

This one looks like a showstopper. If my VMWare boxes take a 15-30 percent hit it will trigger a lot of problems.
Click to expand...


My virtual server thankfully has plenty of buffer, but still...


upload_2018-1-2_22-3-58.png


Most I ever used was ~35%, but I also wonder if I lose 35% of my already weak L5640 cores, if I might start pinning threads :(
 
I wouldn't claim to understand any of this,.. but if past is prelude it won't be 30% anything, it will it a blip. For some reason I doubt AMD enjoys Intel's fuck ups, not they should not capitalize on them.
 
Guys and gals, this shouldnt' be an issue for any of us really on personal systems. Where this is going to be an issue is when admins of systems doing over allocated virtualization in a server farm there by having some forced virtualization of memory it will be an issue.

I've always been against building VM clusers (in spite of OS) that over allocate memory or CPU resources. It is nothing but a recipe for failure.
 
For the pollyannas out there... we do have some initial benchmarks already...
 
I think this has been knon about for quite some time as BSD was the only OS to implment ASLR properly, Windows had the worst implmentation of it and while it was suported under Linux devs were dragging ther heels.

Question is, do I upgrade to AMD now before the price of AMD procesors go thrugh the roof.
 
Zarathustra[H] said:
Most I ever used was ~35%, but I also wonder if I lose 35% of my already weak L5640 cores, if I might start pinning threads :(
Click to expand...

My concern in our environment is the compound performance loss. VMWare will have to update it's kernel- then all the running virtual machines upgrade their kernels. In that world do I get a compound performance hit? How big?

Since virtual machines are basically large abstraction layers, what's the multiplication factor?

Maybe it will be a nothing. But 2% could end up bring 5%. 10% could end up being 20%.
 
stormy1 said:
Slow down old hardware 30%, sell them a new system.
Maybe they have been taking lessons from Apple.
Click to expand...

You laugh, but I've met marketing types that would demand a meeting to talk through that proposal.

In terms of outcome though, Intel deliberately slowing down chips would be met with a reaction closer to when John Deere started bricking tractors/combines remotely with bad software updates. My local IH dealer gets misty-eyed thinking about his install base growth when you mention that.
 
Grimlaking said:
Guys and gals, this shouldnt' be an issue for any of us really on personal systems. Where this is going to be an issue is when admins of systems doing over allocated virtualization in a server farm there by having some forced virtualization of memory it will be an issue.

I've always been against building VM clusers (in spite of OS) that over allocate memory or CPU resources. It is nothing but a recipe for failure.
Click to expand...

First and foremost, the details of the exploit and security bug are embargoed. This revelation if the work of people working backwards from the patches issued for testing. We don't know the full penetration details.

Another point I have to bring up (for those of you who did CS, think back to Operating Systems) in this exploit, an unprivileged user can access Kernel memory. That is HUGE. This defeats sandboxing (and some) for example.
 
Last edited:
Grimlaking said:
Guys and gals, this shouldnt' be an issue for any of us really on personal systems. Where this is going to be an issue is when admins of systems doing over allocated virtualization in a server farm there by having some forced virtualization of memory it will be an issue.

I've always been against building VM clusers (in spite of OS) that over allocate memory or CPU resources. It is nothing but a recipe for failure.
Click to expand...

This has nothing to do with virtualization other than it also utilizes virtual memory. Every program uses virtual memory.
 
Damn it! I just finished building a new i7-8700K system in lieu of a Ryzen after contemplating hard for 3 months. :(
 
Link said:
Damn it! I just finished building a new i7-8700K system in lieu of a Ryzen after contemplating hard for 3 months. :(
Click to expand...

Well you have a few days to see how bad the performance hit will be on Windows. If it's ugly box it back up and return it.
 
so what if the big performance lead intel has had since C2D days has all been because they are sloppy as heck on the security side? and AMD just been getting screwed for not being sloppy?


Also I think** from what I understand of this that it effects everyone.. and you really don't want to opt out of the fix because you are just casual user.. unless you like being pwn'd by every malware infested ad on any website you visit in future? I think this is going to be "interesting"... and kind of sh*t but interesting.

So anyone care to guess if Microsoft patches older OS out of extended support?
 
this is a very complex issue Ive been reading into it for most of the night it is a lot ot digest TLDR wait for the embargo to be up then is when the shit will meet the fan just how much shit i can speculate (Mexico City's yearly output) it has to be a huge issue for all cloud providers to be rebooting all their systems between this friday and next wednesday.
 
erek said:
AMD considered insecure currently just FYI:

For Now At Least AMD CPUs Are Also Reported As "Insecure"


Gaming performance:

Linux Gaming Performance Doesn't Appear Affected By The x86 PTI Work
Click to expand...

lets be clear amd is labeled insecure at this time but the issue does not affect them and has a work around that is waiting to be merged into the kernel.

"AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.

Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>"
 
atarione said:
could be worse... news could have broke AFTER... I had pulled the trigger on an upgrade from my i7-4770K =)

but yeah..... this does sort of suck... AMD may however be slightly pleased currently.. I had been a pretty loyal team Red guy for many years, finally relenting to Intel's pretty clear advantage back in the C2D days...

next upgrade could be to AMD however... waiting on ryzen+
Click to expand...

I was going to ride my delidded 4770k for a little more but the MC sale for the 1800X (I've owned the 1700 and 1700X when they came out originally) at $299 + $60 off the mobo/CPU combo put me at around the cost of an 8700k for the whole shebang so I picked that up instead. Just waiting for my 3200mhz RAM to show up to build it.
 
You must log in or register to reply here.
Back
Top