• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Intel bug incoming.

Snurg

Aspiring Daemon

Thanks: 250
Messages: 705

WTF? Can this be true??

The microcode updater program I am working on shows this with the -i(dentify) option:
Code:
# cpupdate -i                                      
Found CPU(s) from Intel                                                        
/dev/cpuctl0 identification successful!                                        
Processor Core: 0                                                              
ProcessorType:  00
ExtFamily: 00  ExtModel: 01                                                    
IntFamily: 06  IntModel: 0A  Stepping: 05                                      
-> Family: 06  Model:    1A                                                    
Flags: 2                                                                      
-> Family: 06  Model:    1A  uCodeRev: 001B                                    
/dev/cpuctl1 identification successful!                                        
<snipped identical output for the other cores>
#
This is confirmed by dmesg:
Code:
CPU: Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz (2666.72-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a  Stepping=5
And now, I look at the microcode update file supplied by Intel in the Jan 8 update release:
Code:
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-1a-05
Update file properties:
Header version 1 (0x1)
Revision 25 (0x19)
Date 06212013
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 01
IntFamily: 06  IntModel: 0A  Stepping: 05
-> Family: 06  Model:    1A
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 3 (0x00000003)
Data size 10192 (0x27d0)
Has no extended header.
#
Can this be real?
Look at the date - Jun 21, 2013.
Look at the microcode revision: 0x19.
It is lower than the built-in version of the processor...
Am I hallucinating?

The microcode update file format is described in detail in section 9.11.1 (pages 9-28 to 9-31) of the
Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A.
I believe I programmed strictly after the Intel instructions.

Further examinations of other microcode files from that release seem no less irritating:
Code:
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-17-06
Update file properties:
Header version 1 (0x1)
Revision 1551 (0x60f)
Date 09292010
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 01
IntFamily: 06  IntModel: 07  Stepping: 06
-> Family: 06  Model:    17
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 1 (0x00000001)
Data size 4048 (0xfd0)
Has no extended header.
#
This release seems even older. Sep 29, 2010.
Examining more of the files gives me the impression most of them seem to be quite old microcode releases, some around 10 yrs old or more...

I wonder what is going on... so let's examine the biggest files, assuming these are for the most modern, most complex processors of which still some are in production use.
Code:
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-4e-03
Update file properties:
Header version 1 (0x1)
Revision 194 (0xc2)
Date 11162017
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 04
IntFamily: 06  IntModel: 0E  Stepping: 03
-> Family: 06  Model:    4E
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 192 (0x000000c0)
Data size 99280 (0x183d0)
Has no extended header.
#
The biggest file is from Nov 17, 2017. Quite recent, but still from last year.

After examining a few of the biggest files which all were from Nov 2017, I finally managed to find a file updated this year, which is more recent than Intels' last microcode release. Which was on Nov 17, 2017:
Code:
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-9e-0b
Update file properties:
Header version 1 (0x1)
Revision 128 (0x80)
Date 01042018
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 09
IntFamily: 06  IntModel: 0E  Stepping: 0B
-> Family: 06  Model:    9E
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 2 (0x00000002)
Data size 98256 (0x17fd0)
Has no extended header.
#
Yeah... Jan 4, 2018. At least one file.

I have to admit, I did not at all expect to find out such when attempting to test the microcode uploader.
Code:
# cpupdate
Usage: cpupdate [-i] | [-h] | -f <microcodefile> | -u <datadir> [-q]
  -i  show processor information
  -f  show version information of microcode file
  -u  update microcode using microcode files in <datadir>
  -q  quiet mode
  -h  show this help
#
I can still not believe what I see.
I will add another function to give a neat output of all microcode file stats, each a line.
So one can see at a glimpse what internal date and revision every microcode file has.

After that I will put the program onto Github. This will be today afternoon/evening (German time), as it is now 5 a.m. here and I am tired as hell.

So everybody can check out whether I made some mistake, or something other is foul.

Did Intel actually release updated microcodes?
Or did they only pretend to do so, hoping that nobody actually will take a deep look into the microcode files and notice the con art?

If it's true what I suspect, I guess Intel will have to explain some more things.
 

Maelstorm

Active Member

Thanks: 92
Messages: 247

Well now, that's very interesting. If they are trying to con people, it may be so that they can avoid a recall. Lull people into a false sense of security. Either that, or it's a test microcode that they had laying around and they rushed it out the door hoping it will fix the problem. Or it could be just a typo. The issues with Intel CPUs may not be able to be fixed with microcode, which means that there will be a recall. Imagine having a recall on every CPU that you sold over the past 3 years. It will be in the billions, if not tens of billions.

I am actually surprised that AMD hasn't really capitalized on the Intel bug. All is fair in love and war, and business is a war between companies. Perhaps AMD's strategy is to just sit back, watch what happens, and let the chips fall where they may (pun intended).
 

PacketMan

Aspiring Daemon

Thanks: 107
Messages: 777

Is it possible that these microcode updates were written as early as Jun 21, 2013 because they knew about the problem as early as Jun 21, 2013?
 

gofer_touch

Active Member

Thanks: 113
Messages: 243

If that is true then it might signify that certain customers might have been provided with the fix...government agencies and so on, while everyone else was left in the cold.
 

dlegrand

Active Member

Thanks: 42
Messages: 148

I did some test with Spectre POC from https://spectreattack.com/spectre.pdf.

Firstly with my Intel Pentium G2010 CPU original microcode: POC succeeded.
Tried with updated microcode from ports: POC succedeed.

As Intel screwed me over, I decided to buy an AMD CPU based motherboard: Asus M5A78L-M LX3 with AMD FX 6300 CPU.
With original microcode 0x600081c: POC succeeded.
With new microcode 0x600084f from ports: POC failed.

Interesting because the microcode 0x600084f from ports was made available by AMD on 2016-03-17.
 

Trihexagonal

Aspiring Daemon

Thanks: 314
Messages: 738

I'm considering shelving my Netgear router and either re-purposing one of my laptops or dragging out my old pfSense tower router/firewall and take my chances with that.
 

shepper

Aspiring Daemon

Thanks: 197
Messages: 617

I'm considering shelving my Netgear router
Many routers utilize a linux OS and per the GPL2 license, they were required to publish their source. Some projects have taken that source and updated kernels and userland. My Trendnet router initially utilize linux kernel 2.6 but is now running 4.4 lts. See LEDE/OpenWRT. Note the web site is slow right now - perhaps due to LEDE and Openwrt merging?

Edit: FreeBSD also has a router project although it does not support as many devices.
 
Last edited:

Crivens

Moderator
Staff member
Moderator

Thanks: 341
Messages: 1,191

I would like to add some points to this thead.

Is it only me or is meltdown a wee bit bigger than most think it is?
To explain this, meltdown lets you read memory even if you do not have access to
it, right? But, even when that hole is plugged, you still need to do something
more. For those who practice the dark arts of verilog or other means to tell
electrons which way to go, there is the term "strobe register". This is a
register in a hardware interface that acts as a trigger for some action. For
some chip, you would set up the registers for some operation and then pull the
trigger for that operation by accessing that strobe register. Now imagine a
speculative memory load instruction behind a conditional branch which simply
goes bart simpson on some DMA controller in some part of the machine. Maybe this
can even be used in a more surgical way, if possible, but I am sure there were No Serious
Attempts thinking in that direction, right?

Also, on the 34C3, there was a talk about x86 micocode and what you never wanted
to ask about it. I had to leave that one after about 10 minutes because junior
was getting bored. However, they demonstrated that on at least some CPUs they
were reverse engineering micocode the hard way, by flipping bits in the stream
and looking with a debugger what happens to register contents. Maybe there are
systems where there is no, or inadequate, protection against messing with
microcode. Maybe I can watch the recording tonight and see what they did. In the
worst case, you can change the microcode with some javascript or maybe by
triggering certain rules in the JIT enabled firewall?
 

ralphbsz

Aspiring Daemon

Thanks: 325
Messages: 764

If people (outside Intel) can take an Intel microcode file and modify it, and then download that modified file to the CPU and get it to execute with that modified microcode, then there is no reason to trust the CPU chip. I had never bothered to think through how Intel (and AMD and Sun and IBM and ...) secure the microcode; some cryptographic signature that's verified by the hardware would have seemed plausible. But if the CPU does not authenticate the microcode before accepting it, then the bottom falls out.

And those of you who have ever worked on secure computing devices (TCB, self-encrypting disks, key distribution and the like) should give up all hope at this thought.

In the end, as I keep pointing out, this is all solving the wrong problem. All these bugs allow a bad guy to do things they shouldn't do, once they are running code on your computer. The better solution is to prevent them from getting on your computer in the first place. And as discussed over and over, that simply means not running web browsers with javascript (and the like) on machines that also have information that needs to be kept secure. The real problem is that our computer culture has embraced bells and whistles in web pages which need general-purpose programming languages, and forgotten in the process that these things need to be sandboxed. Early in the development of Java (not javascript), there was serious consideration about sandboxing and running applets with reduced privileges; all that seems to have been forgotten again, just so we can serve picture galleries and auto-playing videos every time we need some simple technical information. Really, yesterday I had too look up what model stand is required for Pearl Philharmonic tom drums, and it took 5 minutes, because the web site of Pearl Percussion insists on spamming me with all forms of advertising before the javascript mouse-over menus allow me to click on "specifications". We think of the web as a machine to deliver the eyeballs of the users to advertiser.

Quote from Douglas Adams: "First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII — and we thought it was a typewriter. Then we discovered graphics, and we thought it was a television. With the World Wide Web, we've realized it's a brochure."
 

JAW

New Member


Messages: 12

WTF? Can this be true??

So everybody can check out whether I made some mistake, or something other is foul.

Did Intel actually release updated microcodes?
Or did they only pretend to do so, hoping that nobody actually will take a deep look into the microcode files and notice the con art?

If it's true what I suspect, I guess Intel will have to explain some more things.
It's not that microcode updates are applied incrementally? So the package intel releases contains all micrcode updates going back?
 

Snurg

Aspiring Daemon

Thanks: 250
Messages: 705

I thought about it and decided it would be the best to make a small Perl script that just puts out a sorted list of the internally stored release dates of Intel's microcode files.

This enables everybody to check out the thing easily. As I currently do not have a microcode file that is more recent than what is hard-coded (respective uploaded by the BIOS) in the processors I own, I have no way of actually testing my microcode updater anyway without hacking the files. Thus I am in no hurry to release the program asap, will do that later today or tomorrow.

So here is the list of microcode files supplied by Intel with their Jan 8, 2018 update, sorted by their internal release date:
(YYYY/MM/DD: Family-Model-Stepping)
Code:
1998/06/10:  06-03-02
1998/08/11:  06-07-01
1999/03/12:  06-06-0d
1999/05/05:  06-06-00
1999/05/05:  06-06-05
1999/05/05:  06-06-0a
1999/05/12:  06-05-02
1999/05/25:  06-05-00
1999/05/25:  06-05-01
1999/06/28:  06-05-03
1999/09/10:  06-07-03
1999/09/21:  06-08-01
1999/09/22:  06-07-02
1999/10/15:  06-08-03
2000/01/10:  06-0a-00
2000/03/06:  06-0a-01
2000/05/05:  06-08-06
2000/11/02:  06-08-0a
2001/02/15:  06-0b-01
2002/01/10:  06-0b-04
2002/07/16:  0f-00-07
2002/07/16:  0f-00-0a
2003/05/02:  0f-01-02
2003/06/04:  0f-02-07
2003/06/05:  0f-02-04
2004/05/11:  0f-03-02
2004/08/05:  0f-02-06
2004/08/11:  0f-02-05
2004/08/11:  0f-02-09
2004/10/17:  06-0d-06
2004/11/09:  06-09-05
2005/04/21:  0f-03-03
2005/04/21:  0f-03-04
2005/04/21:  0f-04-01
2005/04/21:  0f-04-03
2005/04/21:  0f-04-04
2005/04/21:  0f-04-07
2005/04/21:  0f-04-09
2005/11/15:  06-0e-08
2005/12/14:  0f-04-0a
2005/12/15:  0f-06-02
2005/12/15:  0f-06-04
2006/04/26:  0f-06-05
2006/05/01:  06-0e-0c
2006/05/08:  0f-04-08
2006/07/14:  0f-06-08
2009/04/10:  06-1c-02
2009/08/25:  06-1c-0a
2009/10/23:  06-26-01
2010/09/28:  06-17-0a
2010/09/29:  06-17-06
2010/09/29:  06-17-07
2010/09/30:  06-0f-06
2010/09/30:  06-1d-01
2010/10/02:  06-0f-02
2010/10/02:  06-0f-07
2010/10/02:  06-0f-0a
2010/10/02:  06-0f-0d
2010/10/03:  06-0f-0b
2010/10/04:  06-16-01
2012/05/22:  06-2d-06
2013/06/12:  06-2a-07
2013/06/17:  06-2d-07
2013/06/18:  06-2f-02
2013/06/19:  06-3e-06
2013/06/21:  06-1a-04
2013/06/21:  06-1a-05
2013/06/26:  06-25-02
2013/06/28:  06-25-05
2013/08/20:  06-1e-05
2014/05/29:  06-3e-07
2015/02/26:  06-3a-09
2016/06/02:  06-56-04
2017/03/01:  06-4f-01
2017/03/25:  06-5c-09
2017/11/16:  06-4e-03
2017/11/16:  06-5e-03
2017/11/17:  06-3d-04
2017/11/17:  06-3f-02
2017/11/17:  06-3f-04
2017/11/17:  06-47-01
2017/11/20:  06-3c-03
2017/11/20:  06-45-01
2017/11/20:  06-46-01
2017/12/01:  06-3e-04
2017/12/08:  06-55-04
2017/12/16:  06-56-02
2017/12/16:  06-56-03
2017/12/26:  06-7a-01
2018/01/04:  06-8e-09
2018/01/04:  06-8e-0a
2018/01/04:  06-9e-09
2018/01/04:  06-9e-0a
2018/01/04:  06-9e-0b
The oldest files are almost 20 years old!
Only a few files have been updated after the Meltdown thing became known to Intel.

So I am having a hard time to believe that Intel's statement is correct, that they provided updates for about 90% of the processors and will provide updates for the remaining ones until end of January.

What do you think?

Anyway, here is the Perl script with which I produced the list above:
Code:
#!/usr/bin/env perl
use strict;
use warnings;

my $dir = '/home/myname/Downloads/microcode-20180108/intel-ucode';
my @updatefiles = ();
opendir( DIR, $dir) or die "Cannot open directory\n";
my @files = readdir( DIR);
closedir( DIR);
foreach my $file (@files) {
  next if (-d $file);
  my $fpath = "$dir/$file";
  open FILE, $fpath or die $!;
  my $header;
  my $count = read( FILE, $header, 64);
  close FILE;
  my ( $header_version, $update_revision, $date) = unpack( 'N' x 3, $header );
  my ( $month, $day, $decade, $year) = unpack( 'c' x 4, pack ('I', $date));
  $year &= 0xff;
  push @updatefiles, sprintf "%02X%02X/%02X/%02X:  %s\n", $decade,  $year, $month, $day, $file;
}
foreach (sort @updatefiles) { print $_; }
Just copy+paste the script, change the directory path in the "my $dir = ..." line to where you unpacked the archive downloaded by Intel, and see yourself.

I guess it will be interesting how Intel will explain this.

Edit:
It's not that microcode updates are applied incrementally? So the package intel releases contains all micrcode updates going back?
No. There is only one file to be applied, this is not incremental. The file name format is FF-MM-SS, two hex nibbles each for family, model, stepping respective, so you can easily find which file is to be applied to your processor.
 

Crivens

Moderator
Staff member
Moderator

Thanks: 341
Messages: 1,191

In the end, it is the complexity that gets you.
 

Snurg

Aspiring Daemon

Thanks: 250
Messages: 705

... secure the microcode; some cryptographic signature that's verified by the hardware would have seemed plausible. But if the CPU does not authenticate the microcode before accepting it, then the bottom falls out.
Well, according to section 9 (microcode updating) of the Intel programmers handbook, there is some encryption and "security checking" for processors P6 and later. These should return the error code "SECURITY_FAILURE" in case the cryptographic checksum is invalid. With older processors, they thus admit that every program can freely put into the microcode what (s)he wants. But I have little trust in Intel anymore, so I will believe the "security" thing only if it has been independently verified.
 

w0w

New Member

Thanks: 10
Messages: 9

Just download older archives and compare checksums of MCU in different releases, not dates, also read release notes. https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File
The last archive contains ALL MCU over decade or even more, but this does not mean every MCU is updated every time, when INTEL releases new archive. I walked right into it also, and lost 2 hours installing old MCU onto my old x3350 and yes it was same old as 2010. I don think any cpu older then 5 years will get MCU ever.
 

Snurg

Aspiring Daemon

Thanks: 250
Messages: 705

w0w shepper
The strange thing still is that the microcodes Intel released with their Jan 8 "update", as well as their older releases, like that from Nov 17, 2017, and the earlier ones are not the most recent.
For example, they seem not to contain the memory sinkhole bug updates for the processors I have.

The list I posted above in post #238 suggests that Intel never released updated microcodes against that nasty sinkhole bug to the public.
But, the fact that manufacturers like HP released BIOS updates that upload updated microcodes to the affected CPUs proves that there exist updates.

Thus the only way to protect against memory sinkhole bug for computers that were not BIOS-updated by their manufacturers seems to extract the microcodes from HP (or other manufacturers') BIOS upgrades, like described in the last post of this Gentoo forums' thread.

This puts up the question why Intel does not give these crucial safety fixes to the public.

To me, it looks like that hotaronohanako could be correct.
Maybe only governments and manufacturers with sufficient pressure power, like HP, actually get microcode updates, leaving all others vulnerable on purpose.

For example, Trihexagonal pointed to an interesting article in this thread that Intel was willing to provide a way to disable the IME backdoor only after pressure from the NSA.
This leaves me with the feeling that Maelstorm might be correct, that the whole "update" thing has only the purpose to lull people into a false sense of security...

I wonder how far back they do update the microcode. Maybe one Generation?
5 years sound generous looking at those MCU dates.
I understood the wording of Intel that way, that they promised to deliver updates for all those processors listed on their update page. Apparently they only pretend to do so, calculating that nobody, or only a few people will notice, and that the broad public won't take notice.
I got the impression, and from the posts on various forums, I know that many others also interpreted the wording "This download is valid for the product(s) listed below" that way, that there would be patches included for the processors displayed in the list on the microcode download page.

Edit:
The last archive contains ALL MCU over decade or even more
Sadly this is incorrect.
The archive (and all the older ones that I examined) do not contain all updates. Intel itself admitted that there are microcode updates only for about 90% (i.e. about 9 models) of their most recent cpus. For example, I was unable to find updates for the 36xx/56xx series. And these are one of these affected by the memory sinkhole thing. However, there exist updated microcodes against that bug, issued more than a year ago. The only way to obtain them I know of is to extract them from HP BIOS update blobs, like described in the Gentoo forum link above.
 

Snurg

Aspiring Daemon

Thanks: 250
Messages: 705

I just got an email from a guy who was in contact with Intels' support staff, that Intel told him per email that Intel will never release a microcode update for the Xeon E/X36xx and E/X56xx processors.
So it seems confirmed that Intel did not tell the truth to the public when they made people believe they'd get microcode updates.
This really sucks, as my main computers use these processors.

I guess I will never ever again buy a computer with Intel processor.
 

Chris_H

Aspiring Daemon

Thanks: 111
Messages: 829

Heh, well, unless it's pre 2012. Or so it seems. I'm guessing the prices on Intel CPU's should be dropping significantly.
Not that I really care. There's just too many other options, and those other options are looking a whole lot better. :D

--Chris
 

w0w

New Member

Thanks: 10
Messages: 9

Sadly this is incorrect.
Yes you are right. I just mean it contains MCU for a lot of CPU but not updated recently.
If we compare 20180108 and 20171117, we find only those MCU files changed, that are listed in the release note. I don't know who is the first stated that Intel would release MCU for all CPUs affected, but it was not true.

EDIT:

It's possible that UBU contains more recent versions of microcode than Intel provides for public.
EDIT2:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
Intel admitted that did crap again, oh... no... just tired of it.
 

Maelstorm

Active Member

Thanks: 92
Messages: 247

Well Snurg,

If that's the case, I would go to the media. Intel's name is already in the mud, a little more just might bring them around. Especially if it can be proven that Intel is lying to the general public about fixing security issues when in fact they are only giving the updates to select companies/agencies. The Register, C|NET, Tom's Hardware, and Ars Technica come to mind.

There is only *1* reason why Intel would do this: To allow government surveillance. The problem, any sufficiently motivated hacker can get in too, which exposes the general public to attacks.

EDIT:

I just did a little research on the memory sinkhole bug. Turns out there is a ring -1 and -2. You can remap the APIC to the protected memory address that the ring -2 software uses and redirect it to a GDT of your choosing. The problem is in the hardware itself and deals with how the logic gates are physically wired together.

An example is if you have a bug in the ALU where it doesn't perform integer multiplication correctly. That's a gate wiring problem in which a microcode update can't fix it. The chip must be replaced. So the memory sinkhole bug is a true hardware bug in the same class as the FDIV bug from the Pentium days.

For a more detailed explanation of what microcode really is, it's the program that runs in the CPU's control unit. The control unit takes the opcode aka instruction and decodes it into a series of control signals which is then fed to the other units on the chip. As such, it's VERY hardware oriented. So if the opcode is for an ADD instruction, the control bits for the ALU will be set to a pattern that selects the add output from the ALU. Wikipedia has a pretty good writeup on it...better than I can do here in the limited space that I have. Another website that I found also has a basic explanation of how this all works.

In short, you have a datapath and a controller. The datapath actually performs the calculations and has various hardware resources which performs those operations. The big one is the ALU. But you also have the register file, the sign/zero extend unit, various muxes, register forwarding unit and hazard detection unit for pipelined processors, the 2-bit branch predictors (which are themselves a hardware finite state machine), instruction and data memories, etc.... All of this is wired together and under control of the control unit. For a pipelined CPU, the control unit is generally just wired logic. However, you can have a CU that's both wired logic AND microcode programmed. Simple math/logic instructions are handled by the wired logic of the CU. More complex instructions are done by the microcode part of the CU. A modern x86 CPU understands more than 1,000 instructions. So their control units are incredibly complex. They are also resource allocation based which adds to that complexity with out-of-order execution units.

I never thought the classes that I have taken on microprocessor and advanced microprocessor design would come in handy so soon. The term project that I did last semester, CSC-142 Advanced Computer Organization, we built a 16-bit 5 stage pipelined CPU datapath with a RISC control unit from scratch in Verilog. That was an interesting project to say the least. With the complexity of the class project still fresh in my mind, I can appreciate the skill of the computer engineers who design these CPUs that we use. Remember, they are human too and make mistakes like everyone else.
 

Snurg

Aspiring Daemon

Thanks: 250
Messages: 705

Maelstorm, good writeup!
However this still does not explain why there have been a few microcode updates in the wake of the memory sinkhole thing that were apparently given only to major hardware manufacturers, but not to end-users.

For example, for the 06-2c-02 family-model-stepping processors (i.e. the X and E 36xx and 56xx processors) the out-of-the box microcode version is at maximum 0x1a. As I mentioned, there are HP (and I think Dell and IBM also) BIOS updates that push them up to 0x1e. There are a few other processors which still were quite recent back then and for which microcode fixes were released, but apparently only to big players, not to the public.
These microcodes one has to extract from BIOS update blobs.

This makes me curious.
Because, if it is actually true that the sinkhole thing is unfixable, what then could be the reasons for updating the microcodes for this and apparently a number of other processors also, that allegedly fixed the sinkhole thing, but not to make the fixes available to the broad public?

I am still confused, because this seems contradictory to me.