Intel bug incoming.

Perhaps because the model CPUs with that stepping were only sold to OEMs (such as HP/Dell/IBM/...), and therefore only installed in systems supported by those vendors? In that case, firmware support should come from those vendors.

Now, whether those vendors chose to release firmware updates for systems that are old enough to have become unsupported is another question.
 
Perhaps because the model CPUs with that stepping were only sold to OEMs (such as HP/Dell/IBM/...
No it's not. I see Snurg already asked the same question on communities.intel.com but it's not answered at least on public. All we have same statement that updates are coming.
 
ralphbsz, good point.
However, this does not seem to be the case with the Westmere-EP class which members mostly share the same family/model/stepping. If it were an OEM-only processor, I am not sure Intel would have listed "recommended customer prices". On the CPU-World pages for these processors for all of these I looked at there are OEM and boxed versions listed.
In addition, there is even an Intel page of the boxed processor I use, so it seems they were available for sale to everybody.
 
I have a question about my CPU, it's an old Core 2 Duo, Intel E6850. From what I understand, only newer Intel CPUs will receive a microcode update. Did I understand correctly? Because if yes, it would mean that my CPU will not be patched against Meltdown/Spectre and I would be forced to migrate to AMD. I really dislike being forced to migrate because of Intel's fault.
 
I have a question about my CPU, it's an old Core 2 Duo, Intel E6850. From what I understand, only newer Intel CPUs will receive a microcode update. Did I understand correctly? Because if yes, it would mean that my CPU will not be patched against Meltdown/Spectre and I would be forced to migrate to AMD. I really dislike being forced to migrate because of Intel's fault.

I happen to be using a machine with the exact same CPU. Amazing you can get that much mileage off a computer these days.

I have some experience with micro-controllers and when those have silicon bugs they'll put out an errata sheet. The only way to fix it is to replace the chip with a newer part. I wonder if Intel has an errata for that one. As mentioned, if it's a silicon bug there's no way to fix it other than replacing the processor. It's unfortunate a bug like that happened, but the silicon side of things is not immune to bugs either. It will be interesting to see how Intel deals with this.
 
...Core 2 Duo, Intel E6850...
According to this page, your cpu is probably Family 6, Model 15, Stepping 6. There seems to be no microcode file available for this kind of cpu.
But as there are some cpus which exist in varieties you might want to double-check using my small cpupdate program's -i option, which shows you the installed processor's family-model-stepping and the microcode version it is running.
 
Before more of this thread progresses, I must say Snurg, you need to get an Award for outstanding technical reporting and investigation on this matter! I think I can say on behalf of others reading this that you have done alot of work on this, thank you!
 
According to this page, your cpu is probably Family 6, Model 15, Stepping 6. There seems to be no microcode file available for this kind of cpu.
But as there are some cpus which exist in varieties you might want to double-check using my small cpupdate program's -i option, which shows you the installed processor's family-model-stepping and the microcode version it is running.

I will give it a try, although I'm not too optimistic. How can I run your program?
 
... but it's not answered at least on public.
At least they promised they'll answer...
How can I run your program?
Just download the files into some directory and run make. After that there should be an executable cpupdate program in the directory. You need to run it as root because as normal user it cannot access the cpuctl devices.
The program requires the cpuctl kernel module being loaded. As this is usually not loaded by default, you'll probably have to kldload cpuctl.
When you have done that, you can get the processor information by ./cpupdate -i.
Code:
# ./cpupdate -i
Found CPU(s) from Intel
/dev/cpuctl0 identification successful!
Processor Core: 0
ProcessorType:  00
ExtFamily: 00  ExtModel: 02
IntFamily: 06  IntModel: 0C  Stepping: 02
-> Family: 06  Model:    2C
Flags: 1
-> Family: 06  Model:    2C  uCodeRev: 001D
/dev/cpuctl1 identification successful!
Processor Core: 1
<snip>
#
It will output the information for every core it found. The reason for that is that one might have multiple processors with different microcode revisions.
The program's usage information is this:
Code:
# ./cpupdate
Usage: cpupdate [-i] | [-h] | -f <microcodefile> | <-u> <datadir> [-q] [-w]
  -i  show processor information
  -f  show version information of microcode file
  -u  update microcode using microcode files in <datadir>
  -w  write it: without this option cpupdate only simulates updating
  -q  quiet mode
  -h  show this help
#
Please be aware that the microcode upload function is still untested. But as it is similar to the devcpu-data microcode uploader, except that several bugs of the latter program have been removed, I think it should work. Will have to extract microcodes for my other PC first to test it.
Aside of some bugs removed (like wrongly set registers, missing safety and compatibility checks) the cpupdate program differs from devcpu-data in that it also works on older FreeBSD versions (possibly even down to 7.2).


.
 
Snurg, I have run your program, here is the output:

Code:
./cpupdate -i
Found CPU(s) from Intel
/dev/cpuctl0 identification successful!
Processor Core: 0
ProcessorType:  00
ExtFamily: 00  ExtModel: 00
IntFamily: 06  IntModel:0F  Stepping: 0B
-> Family: 06  Model:   0F
Flags: 1
-> Family: 06  Model:   0F  uCodeRev: 00B6
/dev/cpuctl1 identification successful!
Processor Core: 1
ProcessorType:  00
ExtFamily: 00  ExtModel: 00
IntFamily: 06  IntModel:0F  Stepping: 0B
-> Family: 06  Model:   0F
Flags: 1
-> Family: 06  Model:   0F  uCodeRev: 00B6

What's the verdict?
 
Dendros Last microcode update was 2010.
2010/10/03: 06-0f-0b

For a graphical client checkout sysutils/cpu-x
It shows the Family,Model and Stepping.

It is rather bloated though:
Code:
Number of packages to be installed: 59

The process will require 261 MiB more space.
46 MiB to be downloaded.
 
Code:
./cpupdate -i
<snip>
IntFamily: 06  IntModel:0F  Stepping: 0B
-> Family: 06  Model:   0F
Flags: 1
-> Family: 06  Model:   0F  uCodeRev: 00B6
What's the verdict?

Code:
# ./cpupdate -f microcode-20180108/intel-ucode/06-0f-0b
Update file properties:
Header version 1 (0x1)
Revision 186 (0xba)
Date 10032010
File is to be used for processors with these stats:
<snip>
IntFamily: 06  IntModel: 0F  Stepping: 0B
<snip>
#

The microcode update file contains microcode version 0xba, which is more recent than the version 0xb6 in your processor.
However, updating won't fix meltdown due to the age of the microcode update (Oct 3, 2010, as Phishfry correctly stated)...

(I really must rework the output of cpupdate to make it readable easier... it's a hard-to-read mess this way... :eek: Will do that tomorrow and update the github repo)

Edit: Phishfry, I think cpu-x tells nothing more relevant here than you can find yourself with # dmesg | grep Origin, but this won't tell you the microcode revision...
 
Am I out of luck too?

I have two desktops: i3-530 and i3-3220 running Windows 7 (the 530 dual boots FreeBSD) The last BIOS updates were from 2010 and 2013 respectively. What options do I have? Buy two new systems?

Also I regularly work doing tech support for small business, the majority of the equipment I see are old desktops and laptops with 2nd - 4th generation Intel CPUs.

I know all of these are legacy cpus but performance is fine for the given use. It's unreasonable to expect that people will just throw away all these perfectly working systems and get new ones.
 
So I'm out of luck. Now I really dislike Intel because I'm forced to make a financiar effort to replace a perfectly working processor and all of that is because they screwed things up.
 
So I'm out of luck.
Most or even all of us FreeBSD users are, until 11.2 gets rushed out. It's still not certain whether Intel will ever manage to release working (i.e. not autorebooting etc) microcode updates even for their newest cpus.
I guess atm our kernel guys are testing the table isolation and trampoline fixes thoroughly so that 11.2 will not be a disaster.
And I fully agree, Intel is really worth being shown the middle finger up. In future I'll avoid Intel products whereever there exist alternatives.
 
Also from me a big thank you to our herold! Nice work!

As to why a microcode update may solve the sinkhole problem (that one got me banging my head into the desk, what in hades had they been thinking?) this requires two instructions to work. One to set up the bad position for the APICs, one to trigger the SM thing. It is highly likely that at least one of them is microcoded, so adding to that microcode program a check if the setup to be done or present is faulty and then tripping some other trap handler would solve it. Even if it is burried deep in the silicon, you can put a road block in front of it. That does not solve it, but it will make abusing it a lot harder.

Having an interest into the dark arts of verilog and VLSI design for half my life now, I would like to point you lot into the direction here: $SEARCHENGINE "openSPARC T2 verilog source"
Just before oracle bugg..^W bought up SUN, they decided to drop the T2 design to the public. An interesting read, if you can understand it. I did not get deep enough to see if the pipeline is hardcoded or uses microcode (would suspect: NO), but it is a pretty fast CPU and shows what hoops you have to jump trough while juggling burning chainsaws.

Why does AMD not do anything media-wise? I could imagine that they will avoid being seen as unprofessional now, and a "smear campaign" against intel might impact the dealings for funds they might now be doing to be able to buy up some fabs or other stuff from intel. The current CEO there seens to have cached in his chips as far as he could, so I assume the thing is already FUBAR from his point of view.
 
I had to do some reading about this business. I usually don't get too worried about security bugs since most of them can be avoided just by being careful about the web sites and emails you deal with. So yeah The Register being what it is I don't really don't like to quote them, but they do concentrate on the technical side of things. They said this in their article;

– the flaw is in the Intel x86-64 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.

Still reading, came across an article that says this;
 
AFAIK both meltdown and spectre making hackers life much much easier and you can't avoid intrusion just by washing your hands and using respirator, when surfing the web, this thing is on low level like radiation and in this case paranoia is not a disease.
 
Intel is really worth being shown the middle finger up.

Still reading older replies in this thread, one comment I'd like to make. I'd like to think Intel did not set out to ignore security in the arms race of execution speed. But I don't know, you'd have to be an Intel engineer to form an opinion of their engineering environment.

At the least this failure on Intel's part says something about their way of doing business and may warrant avoiding their products, but I'm not convinced malice was there. On the other hand, it seems this issue has actually been around for a very long time and it wasn't until Google made it public that it came to a head. In that case you have to wonder why Intel didn't deal with it way back when. That may in fact be malice on Intel's part.
 
  • Thanks
Reactions: w0w
Perhaps because the model CPUs with that stepping were only sold to OEMs (such as HP/Dell/IBM/...), and therefore only installed in systems supported by those vendors? In that case, firmware support should come from those vendors.

Good point.

ralphbsz, good point.
However, this does not seem to be the case with the Westmere-EP class which members mostly share the same family/model/stepping. If it were an OEM-only processor, I am not sure Intel would have listed "recommended customer prices". On the CPU-World pages for these processors for all of these I looked at there are OEM and boxed versions listed.
In addition, there is even an Intel page of the boxed processor I use, so it seems they were available for sale to everybody.

A OEM vendor buys lots of CPUs so they may ask for something slightly custom. The big difference between CPUs destined for OEM and those in boxes is the packaging. OEMs, more often than not (and definitely with laptops) will solder the CPU directly to the mainboard. They usually use BGA packaging to do this. Boxed CPUs are packaged with pins so they can be inserted into sockets.

Why does AMD not do anything media-wise? I could imagine that they will avoid being seen as unprofessional now, and a "smear campaign" against intel might impact the dealings for funds they might now be doing to be able to buy up some fabs or other stuff from intel. The current CEO there seens to have cached in his chips as far as he could, so I assume the thing is already FUBAR from his point of view.

It reminds me of those old PC vs. Apple commercials during the 2000's. It's one of the reasons why I will not buy an Apple computer. To make disparaging remarks about your competitor like that is completely unprofessional. If you cannot sell your product on its merits without trashing your competitor at the same time, then perhaps there is a reason why people are not buying your product.

AMD has lead by example on this. They have made no disparaging remarks against Intel regarding the meltdown bug. In fact, the only thing that AMD has stated is that their CPUs are immune to meltdown but vulnerable to spectre. Intel tried to say that AMD CPUs are vulnerable to meltdown in a round-about way which was immediately debunked by AMD. Intel is just trying to change the narrative because they are looking really bad right now. Especially since Intel's CEO stated that there will be no recall to replace the defective hardware. With the up to 65% performance hit, their customers are really, really upset by that. Which is probably why there is not one, not two, but three class-action lawsuits against Intel right now.

AMD followed Arm's example of publishing errata about which CPUs are affected by what. Completely professional. Intel should have done the same but all they did was try to cloud the issue and treat us like we are stupid and don't know anything. Based on this, and past behavior with the F00F and FDIV bugs, I think that I will be sticking with AMD products for the foreseeable future.

Seriously, the CEO of Intel should be investigated by the SEC for insider trading with the massive stock selloff on November 29, 2017. Could you make it even more suspicious?
 
Also from me a big thank you to our herold! Nice work!
Concur.

Why does AMD not do anything media-wise? ... and a "smear campaign" against intel ...
AMD has been very shaky for a long time now. They have been through so many deaths, they have learned that they have to be careful. I happen to know two of their top brass (silicon valley is a small town), and they have a healthy dose of paranoia, which is earned and sensible. Some of them even spent many years working at Intel. Intel is also one of their biggest business partners. It would be pointless and unwise for AMD to go beat up Intel at this point, and anger them. We can leave that job to the press and the courts.

Still reading older replies in this thread, one comment I'd like to make. I'd like to think Intel did not set out to ignore security in the arms race of execution speed. But I don't know, you'd have to be an Intel engineer to form an opinion of their engineering environment.

At the least this failure on Intel's part says something about their way of doing business and may warrant avoiding their products, but I'm not convinced malice was there. On the other hand, it seems this issue has actually been around for a very long time and it wasn't until Google made it public that it came to a head. In that case you have to wonder why Intel didn't deal with it way back when. That may in fact be malice on Intel's part.
Sadly, I fear that the short-sightedness (at the engineering side) and duplicity and kleptomania (at the executive side) of Intel will be forgotten soon. The next time Trump tweets something outrageous, this will become old news. That's really too bad, because that incompetent/duplicity/kleptomania are an outgrowth of Intel's corporate culture, which much of the valley here likes to make fun of (but only in private, over a beer). What Intel needs is a really big kick in the behind, to change their culture towards engineering excellence and honesty, but that is unlikely to happen.

In Intel's defense: Most other CPUs (of all architectures, not just x86 and x86-64) that use speculative execution have some of the same issues. The failure is endemic; but Intel as the thought (and market) leader had a special responsibility to "Think". (I put that term in quotes because it used to be the motto of some long-forgotten computer company.)

Unfortunately, avoiding Intel products is virtually impossible at the large scale. Individual hobbyists can buy AMD machines for desktops, AMD will probably garner 5-20% market share in the commercial market, and Google/Facebook/... and the federal government are keeping alternative instructions sets and alternative CPU sources alive using artificial life support. But we have to admit that for now, Intel has won the CPU war, and competition is not their problem.
 
As to why a microcode update may solve the sinkhole problem (that one got me banging my head into the desk, what in hades had they been thinking?) this requires two instructions to work. One to set up the bad position for the APICs, one to trigger the SM thing. It is highly likely that at least one of them is microcoded, so adding to that microcode program a check if the setup to be done or present is faulty and then tripping some other trap handler would solve it. Even if it is burried deep in the silicon, you can put a road block in front of it. That does not solve it, but it will make abusing it a lot harder.
There is this memory sinkhole PoC code. However, it seems incomplete, as I can see no payload handler included (probably for good reason).
Does anybody know of an open-source test app that can easily tell whether the sinkhole bug (still) works?
If possible, I would like to verify whether the alleged fix actually fixes the issue...
 
Back
Top