Intel Skylake CPU bug causes PCs to freeze during complex workloads

http://arstechnica.com/gadgets/2016/...lex-workloads/

"Intel has identified an issue that potentially affects the 6th Gen Intel
Core family of products. This issue only occurs under certain complex
workload conditions, like those that may be encountered when running
applications like Prime95. In those cases, the processor may hang or cause
unpredictable system behaviour."

Intel has developed a fix, and is working with hardware partners to
distribute it via a BIOS update.

No reason has been given as to why the bug occurs, but it's confirmed to
affect both Linux and Windows-based systems.

On Wed, 20 Jan 2016 15:39:37 -0800, Alice Yodel wrote:

No reason has been given as to why the bug occurs, but it's confirmed to
affect both Linux and Windows-based systems.

Does linux have a bios?

On 21/01/16 02:16, Ken Cito wrote:
On Wed, 20 Jan 2016 15:39:37 -0800, Alice Yodel wrote:

No reason has been given as to why the bug occurs, but it's confirmed to
affect both Linux and Windows-based systems.
Does linux have a bios?

You machine has a bios. Linux hasn't; Windows hasn't either.

http://whatis.techtarget.com/definition/BIOS-basic-input-output-system
https://en.wikipedia.org/wiki/BIOS

On 2016-01-21, Ken Cito wrote:
On Wed, 20 Jan 2016 15:39:37 -0800, Alice Yodel wrote:

No reason has been given as to why the bug occurs, but it's confirmed to
affect both Linux and Windows-based systems.

Does linux have a bios?
Computers have bioses, not operating systems. Linux does not use the
bios for (almost anything) after boot, but the bios controls the
computer before boot. It is what finds the disks/usb drives/...

Alice Yodel wrote:

Intel has developed a fix, and is working with hardware partners to
distribute it via a BIOS update.

If it can be fixed via BIOS, how is it a hardware issue? It sounds like
they just didn't give proper instructions to the vendors to begin with.



--

They who can give up essential liberty to obtain a little temporary safety,
deserve neither liberty nor safety. - Ben Franklin

On 2016-01-21, G Morgan wrote:
If it can be fixed via BIOS, how is it a hardware issue? It sounds like
they just didn't give proper instructions to the vendors to begin with.

The BIOS (or more properly, the UEFI) loads microcode to the CPU at boot time,
so it is entirely possible that a microcode update will fix the problem.

--
-----------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

NSA sedition and treason -- http://www.DeathToNSAthugs.com
-----------------------------------------------------------------------------

G. Morgan wrote:
Alice Yodel wrote:

Intel has developed a fix, and is working with hardware partners to
distribute it via a BIOS update.

If it can be fixed via BIOS, how is it a hardware issue? It sounds like
they just didn't give proper instructions to the vendors to begin with.

The BIOS installs a microcode patch at startup.

You may not know it, but since the Intel FDIV bug,
the processor makers have installed means to patch
CPUs at runtime. The patches are small (2KB) and
encrypted. They're stored in a BIOS (internal file
system) file. (Not every CPU bug can be fixed that
way.)

A typical Asus motherboard BIOS might have as many
as eight different 2KB patches, to handle Pentium this,
Celeron that, and so on. The header of the patch, has
recorded in it the family code of the processor it is
intended for. I've dissected a few of these from the
file in question, and that's how I know they are there.
The payload is encrypted, so we don't know what the
payload is doing. The CPU can check the encryption,
as a basic prevention against hacking attempts.
I have no idea what the encryption method might be.

Directory of N:\EDownload\845GVM\$MCTEMP

02/14/2012 12:00 AM 13,430 64N8IIP.BMP
02/17/2012 12:00 AM 17,030 64N8P4E.BMP
02/18/2012 12:00 AM 17,030 64N8P4HE.BMP
02/16/2012 12:00 AM 13,405 64N8P4HT.BMP
02/15/2012 12:00 AM 13,405 64N8P4P.BMP
04/29/2063 05:31 PM 131,072 6A69VM4V.BIN
01/03/2012 12:00 AM 16,939 ACPITBL.BIN
01/02/2012 12:00 AM 5,772 AWARDBMP.BMP
03/31/2012 12:00 AM 50,848 AWARDEXT.ROM
01/14/2012 12:00 AM 24,784 AWARDEYT.ROM
03/31/2012 12:00 AM 49,152 BDG_3243.DAT
01/14/2012 12:00 AM 1,456 BDG_3243.VBT
01/01/2012 12:00 AM 16,384 CPUCODE.BIN --- 8 microcode patches
02/06/2012 12:00 AM 307,980 LOGO.BMP
01/09/2012 12:00 AM 16,368 _EN_CODE.BIN

Later processors, the patch capability was extended
to accept multiple-of-2K patches. So another BIOS
I examined, it had 2KB and 4KB patches in it.

Both Linux and Windows have microcode patchers. The
Windows one runs as a service, and the service exits
seconds after the OS finishes booting. Microsoft occasionally
issues a patch for their microcode loader, delivering
newer versions of the 2KB patches. So your OS is also
a delivery vehicle for an Intel patch. Even if you
don't update the BIOS, you may (eventually) be covered.

The patches have a version number.

The CPU will only accept patches higher than the one
stored internally currently.

A power up, the "CPU Version" field is 00. The BIOS
might install a version 07 patch. The operating
system might have received version 11 patch last
week, and at boot, that would be installed.

Running the Intel PIU program, and checking the
"version" field, tells you your current patch level.
A CPU version of 00, spells trouble, and implies something
is broken.

The BIOS patch only has to work well enough, to allow
booting to finish. A bug such as the Skylake one, a microcode
patch delivered by the OS would be sufficient to cover
runtime issues. You don't need hyperthreaded AVX, to
get a computer to finish booting :-)

And when a CPU comes up (at T=0), it uses an onion skin
approach. For example, all the caches are initially disabled.
If a microcode patch needed to be installed, that had
something to do with caches, the CPU can be left in
a crude enough state, to finish the patching. So when your
CPU starts, it starts up in a pretty primitive state,
and things are "switched on" as the BIOS commissioning
procedures progress. It's not like the CPU turns on,
and every feature is perfectly running at T=0. It's
like a rocket launch, with pre-launch checks, guys
greasing the O-rings and so on.

The whole process used to make me chuckle, because
a large number of people at work had access to some
of those early procedures for our products. And I
was the guy with the logic analyzer helping them (I would
debug stuff that didn't work, even if it "wasn't my fault").
They used to turn the caches on and off like light switches,
so I asked them one day, what they thought they were
doing. And it appeared each involved individual, didn't
know what the other guy was doing. So unbelievably bad
stuff can be going on down there, and you'd never know :-)
All the customer cares about, is the screen lighted up :-)
It doesn't matter how convoluted the launch procedure is.

Just for the record, *every* CPU has errata, and a percentage
of issues can be fixed with microcode. For the AMD TLB bug,
that one was fixed by actual x86 code added to the BIOS
image. The TLB (translation lookaside buffer) is not
an "instruction", so you wouldn't expect microcode to
fix that.

Much of this stuff is fixed without fanfare.

For example, I only learned about this one, this evening.

https://en.wikipedia.org/wiki/Intel_TSX

"which resulted in disabling the TSX feature
on affected CPUs via a microcode update"

If they can't fix it, they prune off the capability bit
for it, so you can't use a broken feature by accident.

Paul

The computer that runs Linux does


--
AL'S COMPUTERS
"Ken Cito" wrote in message
...
On Wed, 20 Jan 2016 15:39:37 -0800, Alice Yodel wrote:

No reason has been given as to why the bug occurs, but it's confirmed to
affect both Linux and Windows-based systems.

Does linux have a bios?

Paul writes:
You may not know it, but since the Intel FDIV bug,
the processor makers have installed means to patch
CPUs at runtime. The patches are small (2KB) and
encrypted. They're stored in a BIOS (internal file
system) file. (Not every CPU bug can be fixed that
way.)

A typical Asus motherboard BIOS might have as many
as eight different 2KB patches, to handle Pentium this,
Celeron that, and so on. The header of the patch, has
recorded in it the family code of the processor it is
intended for. I've dissected a few of these from the
file in question, and that's how I know they are there.
The payload is encrypted, so we don't know what the
payload is doing. The CPU can check the encryption,
as a basic prevention against hacking attempts.
I have no idea what the encryption method might be.

https://www.dcddcc.com/pubs/paper_microcode.pdf infers the following:

- A block cipher with a 64-bit block size (s6.2.1). Triple-DES would be
the most likely guess if they’re right about the block size.
- An RSA signature using a 2048-bit key (s4.1.2). They don’t offer any
conclusions on padding mode and aren’t sure which hash function is
used.

--
http://www.greenend.org.uk/rjk/

Paul wrote:

G. Morgan wrote:
Alice Yodel wrote:

Intel has developed a fix, and is working with hardware partners to
distribute it via a BIOS update.

If it can be fixed via BIOS, how is it a hardware issue? It sounds like
they just didn't give proper instructions to the vendors to begin with.

The BIOS installs a microcode patch at startup.

You may not know it, but since the Intel FDIV bug,
the processor makers have installed means to patch
CPUs at runtime. The patches are small (2KB) and
encrypted. They're stored in a BIOS (internal file
system) file. (Not every CPU bug can be fixed that
way.)

A typical Asus motherboard BIOS might have as many
as eight different 2KB patches, to handle Pentium this,
Celeron that, and so on. The header of the patch, has
recorded in it the family code of the processor it is
intended for. I've dissected a few of these from the
file in question, and that's how I know they are there.
The payload is encrypted, so we don't know what the
payload is doing. The CPU can check the encryption,
as a basic prevention against hacking attempts.
I have no idea what the encryption method might be.

Directory of N:\EDownload\845GVM\$MCTEMP

02/14/2012 12:00 AM 13,430 64N8IIP.BMP
02/17/2012 12:00 AM 17,030 64N8P4E.BMP
02/18/2012 12:00 AM 17,030 64N8P4HE.BMP
02/16/2012 12:00 AM 13,405 64N8P4HT.BMP
02/15/2012 12:00 AM 13,405 64N8P4P.BMP
04/29/2063 05:31 PM 131,072 6A69VM4V.BIN
01/03/2012 12:00 AM 16,939 ACPITBL.BIN
01/02/2012 12:00 AM 5,772 AWARDBMP.BMP
03/31/2012 12:00 AM 50,848 AWARDEXT.ROM
01/14/2012 12:00 AM 24,784 AWARDEYT.ROM
03/31/2012 12:00 AM 49,152 BDG_3243.DAT
01/14/2012 12:00 AM 1,456 BDG_3243.VBT
01/01/2012 12:00 AM 16,384 CPUCODE.BIN --- 8 microcode patches
02/06/2012 12:00 AM 307,980 LOGO.BMP
01/09/2012 12:00 AM 16,368 _EN_CODE.BIN

Later processors, the patch capability was extended
to accept multiple-of-2K patches. So another BIOS
I examined, it had 2KB and 4KB patches in it.

Both Linux and Windows have microcode patchers. The
Windows one runs as a service, and the service exits
seconds after the OS finishes booting. Microsoft occasionally
issues a patch for their microcode loader, delivering
newer versions of the 2KB patches. So your OS is also
a delivery vehicle for an Intel patch. Even if you
don't update the BIOS, you may (eventually) be covered.

The patches have a version number.

The CPU will only accept patches higher than the one
stored internally currently.

A power up, the "CPU Version" field is 00. The BIOS
might install a version 07 patch. The operating
system might have received version 11 patch last
week, and at boot, that would be installed.

Running the Intel PIU program, and checking the
"version" field, tells you your current patch level.
A CPU version of 00, spells trouble, and implies something
is broken.

The BIOS patch only has to work well enough, to allow
booting to finish. A bug such as the Skylake one, a microcode
patch delivered by the OS would be sufficient to cover
runtime issues. You don't need hyperthreaded AVX, to
get a computer to finish booting :-)

And when a CPU comes up (at T=0), it uses an onion skin
approach. For example, all the caches are initially disabled.
If a microcode patch needed to be installed, that had
something to do with caches, the CPU can be left in
a crude enough state, to finish the patching. So when your
CPU starts, it starts up in a pretty primitive state,
and things are "switched on" as the BIOS commissioning
procedures progress. It's not like the CPU turns on,
and every feature is perfectly running at T=0. It's
like a rocket launch, with pre-launch checks, guys
greasing the O-rings and so on.

The whole process used to make me chuckle, because
a large number of people at work had access to some
of those early procedures for our products. And I
was the guy with the logic analyzer helping them (I would
debug stuff that didn't work, even if it "wasn't my fault").
They used to turn the caches on and off like light switches,
so I asked them one day, what they thought they were
doing. And it appeared each involved individual, didn't
know what the other guy was doing. So unbelievably bad
stuff can be going on down there, and you'd never know :-)
All the customer cares about, is the screen lighted up :-)
It doesn't matter how convoluted the launch procedure is.

Just for the record, *every* CPU has errata, and a percentage
of issues can be fixed with microcode. For the AMD TLB bug,
that one was fixed by actual x86 code added to the BIOS
image. The TLB (translation lookaside buffer) is not
an "instruction", so you wouldn't expect microcode to
fix that.

Much of this stuff is fixed without fanfare.

For example, I only learned about this one, this evening.

https://en.wikipedia.org/wiki/Intel_TSX

"which resulted in disabling the TSX feature
on affected CPUs via a microcode update"

If they can't fix it, they prune off the capability bit
for it, so you can't use a broken feature by accident.


Good post. Thanks.



--

They who can give up essential liberty to obtain a little temporary safety,
deserve neither liberty nor safety. - Ben Franklin

Richard Kettlewell wrote:
Paul writes:
You may not know it, but since the Intel FDIV bug,
the processor makers have installed means to patch
CPUs at runtime. The patches are small (2KB) and
encrypted. They're stored in a BIOS (internal file
system) file. (Not every CPU bug can be fixed that
way.)

A typical Asus motherboard BIOS might have as many
as eight different 2KB patches, to handle Pentium this,
Celeron that, and so on. The header of the patch, has
recorded in it the family code of the processor it is
intended for. I've dissected a few of these from the
file in question, and that's how I know they are there.
The payload is encrypted, so we don't know what the
payload is doing. The CPU can check the encryption,
as a basic prevention against hacking attempts.
I have no idea what the encryption method might be.

https://www.dcddcc.com/pubs/paper_microcode.pdf infers the following:

- A block cipher with a 64-bit block size (s6.2.1). Triple-DES would be
the most likely guess if they’re right about the block size.
- An RSA signature using a 2048-bit key (s4.1.2). They don’t offer any
conclusions on padding mode and aren’t sure which hash function is
used.


And the thing is, the processor has to handle that itself, without
BIOS help. Crazy.

Paul

On 2016-01-22, Paul wrote:
And the thing is, the processor has to handle that itself, without
BIOS help. Crazy.

Modern Intel systems have a dedicated microcontroller in the Management
Engine which is completely separate from the main CPU. Possibly that can
handle the microcode update though I have no idea if they are actually
doing it that way.

http://recon.cx/2014/slides/Recon%20...Skochinsky.pdf

--
-----------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

NSA sedition and treason -- http://www.DeathToNSAthugs.com
-----------------------------------------------------------------------------