Monday, January 22nd 2018

Intel Announces Root Cause of Meltdown, Spectre Patch Reboot Issue Identified

Intel has finally come around towards reporting on the state of the reboot issues that have been plaguing Intel systems ever since the company started rolling out patches to customers. These patches, which aimed to mitigate security vulnerabilities present in Intel's chips, ended up causing a whole slew of other problems for Intel CPU deployment managers. As a result of Intel's investigation, the company has ascertained that there were, in fact, problems with the patch implementation, and is now changing its guidelines: where before users were encouraged to apply any issued updates as soon as possible, the company now states that "OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior." A full transcription of the Intel press release follows.
"As we start the week, I want to provide an update on the reboot issues we reported Jan. 11. We have now identified the root cause for Broadwell and Haswell platforms, and made good progress in developing a solution to address it. Over the weekend, we began rolling out an early version of the updated solution to industry partners for testing, and we will make a final release available once that testing has been completed.

Based on this, we are updating our guidance for customers and partners:
  • We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior. For the full list of platforms, see the Intel.com Security Center site.
  • We ask that our industry partners focus efforts on testing early versions of the updated solution so we can accelerate its release. We expect to share more details on timing later this week.
  • We continue to urge all customers to vigilantly maintain security best practice and for consumers to keep systems up-to-date.
I apologize for any disruption this change in guidance may cause. The security of our products is critical for Intel, our customers and partners, and for me, personally. I assure you we are working around the clock to ensure we are addressing these issues.

I will keep you updated as we learn more and thank you for your patience." Sources: Intel NewsRoom Reboot Issues, Intel newsRoom Udpated Guidance
Add your own comment

41 Comments on Intel Announces Root Cause of Meltdown, Spectre Patch Reboot Issue Identified

#2
pigulici
So in short : "the patch used until now it is broken, don't used, wait until we have another one"; glad I blocked and didn't do any update , even for bios, starting this month, the common sense it is to wait and see...
Posted on Reply
#3
AsRock
TPU addict
Classic
The security of our products is critical for Intel
If that was the case it would of been fixed many years ago.
Posted on Reply
#4
theoneandonlymrk
pigulici said:
So in short : "the patch used until now it is broken, don't used, wait until we have another one"; glad I blocked and didn't do any update , even for bios, starting this month, the common sense it is to wait and see...
Unless you are a consumer de general public ,in which case patch yo shit even if it f@@ks yo shit ????
What the actual f###

Im on an Amd Fx with all the latest patches and im seeing a lot of system hangs atm maybe unconnected since i mess with sliders and tune settings like theirs a prize involved but I'm just carrying on as Normal to be fair which to me makes more hangs someone elses fault:)
Posted on Reply
#5
R0H1T
Well Intel's spinning their usual BS & they don't seem intent on fixing spectre anytime soon ~
On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
> > All of this is pure garbage.
> >
> > Is Intel really planning on making this shit architectural? Has
> > anybody talked to them and told them they are f*cking insane?
> >
> > Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.


You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.


> Certainly it's a nasty hack, but hey â the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.


It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable â as long as it
> can die entirely by the next generation.


That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.


So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.


Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit â just "you don't have to worry any more, it got better".


It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.


The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".


So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.


I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.


> We do need the IBPB feature to complete the protection that retpoline
> gives us â it's that or rebuild all of userspace with retpoline.


BULLSHIT.

Have you _looked_ at the patches you are talking about? You should
have - several of them bear your name.


The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.


So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.


If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.


As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.


WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.


It's mis-designed for two major reasons:

- the "the interface implies Intel will never fix it" reason.

See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.


Do you really think that is acceptable?

- the "there is no performance indicator".

The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.


But since we already know that the IBRS overhead is huge on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.


I think we need something better than this garbage.

Linus
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html

It's probably because, as Linus hinted, the performance hit is huge & even then the (software) fix may not be 100% secure.
Posted on Reply
#6
Katanai
"OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior."

It seems that my point of view from the start of all this, not downloading beta software created in a panic and waiting for the final patch, was right. A lot of people on this forum criticized me for saying that is the way to go. I dare anyone, now after even Intel says you should uninstall the cancer patch they created, to tell me that I was wrong. Are there still any takers out there?
Posted on Reply
#7
trparky
R0H1T said:
Well Intel's spinning their usual BS & they don't seem intent on fixing spectre anytime soon ~
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html

It's probably because, as Linus hinted, the performance hit is huge & even then the (software) fix may not be 100% secure.
Yeah, because they'd actually have to do some work to improve their products which of course we all know they don't want to do. They instead want to sit back, rake in the cash and the while screw us over and over because well... just because. What? Did you expect anything else? We're Intel remember!

Good God, it's a damn good thing that AMD has come back from behind because damn if I ever buy another Intel chip after this garbage that Intel has just handed us. #IntelFail #AMDFTW
Posted on Reply
#8
jsfitz54
Katanai said:
"OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior."

It seems that my point of view from the start of all this, not downloading beta software created in a panic and waiting for the final patch, was right. A lot of people on this forum criticized me for saying that is the way to go. I dare anyone, now after even Intel says you should uninstall the cancer patch they created, to tell me that I was wrong. Are there still any takers out there?
Question: Can the Patch be undone, for those that had it auto applied? (((OR))) Will it stay in place for some reason and leave behind remnants?
Posted on Reply
#9
Katanai
jsfitz54 said:
Question: Can the Patch be undone, for those that had it auto applied? (((OR))) Will it stay in place for some reason and leave behind remnants?
Any Windows update can be uninstalled without any negative repercussions as far as I know. If we are talking about a BIOS update, simply flashing the previous one should do the job. As for CPU firmware, I dunno how that works...
Posted on Reply
#10
lexluthermiester
AsRock said:
If that was the case it would of been fixed many years ago.
If they'd known about it, they likely would have redesigned the hardware to fix it as they're doing now. It actually would have been better if all of these problems would have been discovered before the release of the Core series of CPU's.
Posted on Reply
#12
Arctucas
I wondered about the microcode being reversible as well.

Does anyone know of a list of the various processor microcode numbers that are affected?

My 6700K is currently on C2.
Posted on Reply
#13
FordGT90Concept
"I go fast!1!11!1!"
I've applied the microcode update to my 6700K mobo and still have not encountered any issues.
Posted on Reply
#14
AsRock
TPU addict
lexluthermiester said:
If they'd known about it, they likely would have redesigned the hardware to fix it as they're doing now. It actually would have been better if all of these problems would have been discovered before the release of the Core series of CPU's.
I don't believe that for a second, they knew and didn't due to performance loss.
Posted on Reply
#15
mcraygsx
lexluthermiester said:
If they'd known about it, they likely would have redesigned the hardware to fix it as they're doing now. It actually would have been better if all of these problems would have been discovered before the release of the Core series of CPU's.
CPU does have a firmware of a sorts also known as microcode update. Intel distribute the microcode to vendors and they delivery microcode update as a part of BIOS update.
Posted on Reply
#16
kn00tcn
Katanai said:
It seems that my point of view from the start of all this, not downloading beta software created in a panic and waiting for the final patch, was right. A lot of people on this forum criticized me for saying that is the way to go. I dare anyone, now after even Intel says you should uninstall the cancer patch they created, to tell me that I was wrong. Are there still any takers out there?
"my point of view", "i was right", "i dare", "cancer", "tell me i was wrong", "i challenge others"

is this an esports match? a more humble attitude would make the points more clear, otherwise it's really hard to care to listen through the filler during an important topic such as security that is out of the user's control... nobody needs to know how much of a victim you were, not everyone read the previous threads

linus torvalds very recently was infuriated (with F bombs) about the intel 'garbage' being requested into the linux kernel, this isnt something to boast about, it's a very disappointing situation...

plus, controlling a few windows updates doesnt mean you're controlling the intial OS state, or the browsers losing performance, or not being able to undo specific items from a service pack, etc
Posted on Reply
#17
Aquinus
Resident Wat-man
mcraygsx said:
Intel distribute the microcode to vendors and they delivery microcode update as a part of BIOS update.
Microcode updates don't need to happen through the BIOS.
code:
$ apt list --upgradable intel-microcode
Listing... Done
intel-microcode/artful-updates,artful-security 3.20180108.0+really20170707ubuntu17.10.1 amd64 [upgradable from: 3.20180108.0~ubuntu17.10.1]

https://launchpad.net/ubuntu/+source/intel-microcode/3.20180108.0+really20170707ubuntu17.10.1
intel-microcode (3.20180108.0+really20170707ubuntu17.10.1) artful-security; urgency=medium

* Revert to 20170707 version of microcode because of regressions on
certain hardware. (LP: #1742933)

-- Marc Deslauriers
If I'm reading this correctly, it is telling me that microcode was reverted back to the version from July last year because this regression was so bad, that it's almost like Intel conceding that their fix was worse than the security hole it was attempting to patch. :fear:
Posted on Reply
#18
kn00tcn
Aquinus said:
If I'm reading this correctly, it is telling me that microcode was reverted back to the version from July last year because this regression was so bad, that it's almost like Intel conceding that their fix was worse than the security hole it was attempting to patch. :fear:
it's not 'so bad', it either has an issue or it doesnt, it's also a single distro's point of reference

dont think about the date, microcode isnt supposed to have updates every month
Posted on Reply
#19
Aquinus
Resident Wat-man
kn00tcn said:
dont think about the date, microcode isnt supposed to have updates every month
Yet, this is update #2 this month.
kn00tcn said:
it's not 'so bad', it either has an issue or it doesnt, it's also a single distro's point of reference
Undoing the patch for meltdown because it can crash certain systems? I'm not sure how that qualifies as "not so bad." :laugh:

Also:
Debian distributes each individual Intel microcode update unmodified, as downloaded from Intel.
https://launchpad.net/ubuntu/artful/+source/intel-microcode/+copyright
Posted on Reply
#20
lexluthermiester
AsRock said:
they knew and didn't due to performance loss.
There is no evidence of that and Intel isn't the only company effected. Meltdown yes, but the many variants of Spectre? No. And for more than two decades? Come on, that would have to be the best kept secret in history..
Posted on Reply
#21
OSdevr
kn00tcn said:
it's not 'so bad', it either has an issue or it doesnt, it's also a single distro's point of reference

dont think about the date, microcode isnt supposed to have updates every month
If Ubuntu was a server distro I might understand pulling the update for 'mission critical' reliability reasons but it's a desktop distro, and as the most popular Linux distro (and one which I personally use) others are likely to follow suit. There are a lot of distros based on Ubuntu, it's not some no name.

AsRock said:
I don't believe that for a second, they knew and didn't due to performance loss.
There would be little performance loss if done in hardware compared to this software kludge.
Posted on Reply
#23
Katanai
kn00tcn said:
"my point of view", "i was right", "i dare", "cancer", "tell me i was wrong", "i challenge others"

is this an esports match? a more humble attitude would make the points more clear, otherwise it's really hard to care to listen through the filler during an important topic such as security that is out of the user's control... nobody needs to know how much of a victim you were, not everyone read the previous threads

linus torvalds very recently was infuriated (with F bombs) about the intel 'garbage' being requested into the linux kernel, this isnt something to boast about, it's a very disappointing situation...

plus, controlling a few windows updates doesnt mean you're controlling the intial OS state, or the browsers losing performance, or not being able to undo specific items from a service pack, etc
My message was not intended for you. I am not boasting about anything. This was my original post on this forum:

Katanai said:
I will not install anything on my computer that degrades performance. For Windows 7 the update is KB4056894 I have already hidden it and will never install it...
As you can see I have just said what I am going to do and written the specific windows update number so that maybe other people who want to do the same thing know which one it is. To this message that was meant to maybe help other people the replies I got where:

Assimilator said:
Aren't you the badass. Betting your next post will be "OMG my pc got exploited because of meltdown intel is teh evil no of course it's not my fault that i didn't install the mitigation because i'm a moron".
R-T-B said:

No one here is a moron. Not installing these updates is foolish in most instances however.
TheinsanegamerN said:
Part of the reason this vulnerability is so dangerous is people like you that leave their systems vulnerable. By the time you hear about widespread exploits, it will likely be too late for you.
As you can see, I have been called a moron, a fool, people like me are dangerous etc. I refuse to be humble in front of such people, who should be eating their words right now. I can tell you to rest assured that my Operating System is fully under my control, my browser is not losing any performance and if I have to undo a specific item from a service pack I'll find a way to do it. Nothing about this situation was out of a user's control, anyone could have chosen not to take part in it. Yet some people on this forum, when such an alternative was presented to them, started throwing stones and insults, trying to drag everyone down with them...
Posted on Reply
#24
OSdevr
Aquinus said:
"If Ubuntu was a server distro"? It's only like, the most widespread Linux server distro
Ubuntu Server is. It is distinct from Ubuntu Desktop.
Posted on Reply
#25
R-T-B
Katanai said:
As you can see, I have been called a moron, a fool, people like me are dangerous etc
For my part, I didn't call you a fool. I said your actions were foolish. There is a very big difference.
Posted on Reply
Add your own comment