If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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. |
Ads |
#2
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complexworkloads
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? |
#3
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complexworkloads
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 |
#4
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complexworkloads
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/... |
#5
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complex workloads
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 |
#6
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complexworkloads
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 ----------------------------------------------------------------------------- |
#7
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complex workloads
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 |
#8
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complex workloads
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? |
#9
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complex workloads
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/ |
#10
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complex workloads
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 |
#11
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complex workloads
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 |
#12
|
|||
|
|||
Intel Skylake CPU bug causes PCs to freeze during complexworkloads
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 ----------------------------------------------------------------------------- |
Thread Tools | |
Display Modes | Rate This Thread |
|
|