8 ms·

Intel processor microcode security update

73 points by sehugg 13y ago

RachelF 13y ago
So what bug has Intel fixed?
- adestefan 13y ago
  Did you read the link? 1. It fixes a critical erratum, classified by Intel as a security issue, that affects any server running 32-bit VMs in PAE mode. Erratum AAK167/BT248: "If a logical processor has EPT (Extended Page Tables) enabled, is using 32-bit PAE paging, and accesses the virtual-APIC page then a complex sequence of internal processor micro-architectural events may cause an incorrect address translation or machine check on either logical processor. This erratum may result in unexpected faults, an uncorrectable TLB error logged in IA32_MCI_STATUS.MCACOD bits [15:0], a guest or hypervisor crash, or other unpredictable system behavior"
oakwhiz 13y ago
I don't understand why this would be the case: 3. It recently came to my attention that this microcode update might forbid unsupported (by Intel) overclocking on 4th gen Core "K" processors installed on motherboards that lack a Z-series chipset.
- pktgen 13y ago
  They only want people that pay extra for Z chipsets to be able to overclock. Pretty ballsy of them to release an update that disables functionality for no good reason. (Intel's bottom line isn't a good reason.)
- simcop2387 13y ago
  Following some of the links in the mail thread[1] it sounds like intel only allows it on the Z series chipsets for various reasons. And some mother board manufacturers have been enabling it on the sly to let people without them to do some amount of overclocking. [1] http://www.bit-tech.net/news/hardware/2013/07/25/intel-overclocking-block/1 http://www.bit-tech.net/news/hardware/2013/07/25/intel-overc...
  - yuhong 13y ago
    I wonder how does it detect the chipset being used.
    - 4ad 13y ago
      It's in the CPU which is connected to the physical memory. Detecting the chipset is as trivial as reading a few bytes from the memory.
- keeperofdakeys 13y ago
  This has mostly always been the case. Also consider the microcode has to be loaded every time the OS is booted (or be baked into the bios image). So it doesn't really mean much.
andyzweb 13y ago
>implying this isn't a new patch from the NSA
- bastawhiz 13y ago
  The NSA would have to be damn slick to fit any kind of spying tool into a CPU bitcode update. The CPU doesn't know what the code that it's running does or what the data that it's handling is. It would need to set aside memory to do pattern matching on the code/data being processed to introduce any kind of back door. Then, it would need to hide the back door so nobody notices, which would potentially involve huge amounts of code to disguise the fact that the data has been modified. An example of an attack would be for the NSA to muck with random number generation to bias it towards certain values in a very subtle way. That would mean that encryption would be less strong, since the total number of possible values needed to brute force is lower. This would be difficult to hide: if they attacked say, RdRand, anyone using/researching RdRand would be able to see that it's no longer NIST/FIPS/ANSI compliant. They would need to attack it such that the back door was only open when nobody was looking (when there's not a very large number of those commands being run, or when the command is part of a larger piece of code). Even then, anyone studying the final output from the affected code could potentially determine that the random number source was biased. Either way, I'd think that an attack like this would be pretty damn hard to pull off, and Intel has very little reason to help the NSA with that. Can you imagine if it was found out that Intel was helping the NSA by weakening encryption? Everyone would go out and buy an AMD machine.
  - crististm 13y ago
    To continue the conspiration theory further, the attack vector would certainly start with AMD when no one was looking :)
  - Someone 13y ago
    Would it be that hard? I would think of: - snoop the instructions being read. - continuously compute a CRC from those bytes, resetting the CRC to zero when encountering a magic value, say when encountering a jump instruction. - whenever the CRC hits some magic number, shortcut the random number generator to return a few hundred zeroes. Alternatively, one can have a similar circuit attempting to detect the password checking code, and have the first code set a 'please let the next password comparison instruction succeed' flag. The two circuits even could be the same: for a given sequence of 'check password' instructions, it is easy to make the hardware or microcode handle some special password as a universal key. And yes, that is 'for a given sequence of instructions', but those won't change that often in popular OSes, and you can always issue a microcode update if, say, a service pack, security update or compiler change changes that sequence. Tinfoil hat of: I think Intel could easily do something like that, but I doubt they do. Some day, somebody will reverse engineer that CPU, notice a small, weirdly connected part and get curious as to what it is doing.
sounds 13y ago
More information about the bug: https://launchpad.net/debian/+source/intel-microcode/1.20130808.2 https://launchpad.net/debian/+source/intel-microcode/1.20130... https://bugs.launchpad.net/intel/+bug/1212497 https://bugs.launchpad.net/intel/+bug/1212497 Intel.com link for downloading the raw microcode update: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23082 https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Dwnl...
comex 13y ago
What I'd give to see a textual diff of the source code to that microcode update (which is, for the record, encrypted and signed).
- 4ad 13y ago
  The microassembly means nothing unless you have the full schematics of the CPU.
GICodeWarrior 13y ago
Intel releases new microcode relatively frequently. There appear to be about 13 microcode updates for the i7 since launch. https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Processors&ProductLine=Desktop&ProductProduct=Intel%C2%AE+Core%E2%84%A2+i7+Desktop+Processor&ProdId=3426&LineId=3004&FamilyId=24 https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&... If I understand correctly, most of the updates are designed to fix bugs related to surrounding hardware (motherboards, memory). If you look at the BIOS updates for your computer/motherboard, you might notice notes about microcode updates. The BIOS can apply these just as easily as the OS, and when they are hardware compatibility issues, that is the only way for it to work. Not every update makes it into a BIOS version for every board, and not every version makes it into a Windows update (AFAIK).
- zurn 13y ago
  This addesses a real vuln though, "classified by Intel as a security issue, that affects any server running 32-bit VMs in PAE mode"
ck2 13y ago
I wonder if this will make it to Redhat/CentOS and how long it will take.
- BuildTheRobots 13y ago
  I got a CentOS announcement this morning in my email, so it should already be there: https://rhn.redhat.com/errata/RHEA-2013-1202.html https://rhn.redhat.com/errata/RHEA-2013-1202.html
superkuh 13y ago
http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ provides a good background summary of microcode on AMD/Intel CPU in general.

73 points by sehugg 13y ago

RachelF 13y ago

So what bug has Intel fixed?

adestefan 13y ago
Did you read the link? 1. It fixes a critical erratum, classified by Intel as a security issue, that affects any server running 32-bit VMs in PAE mode. Erratum AAK167/BT248: "If a logical processor has EPT (Extended Page Tables) enabled, is using 32-bit PAE paging, and accesses the virtual-APIC page then a complex sequence of internal processor micro-architectural events may cause an incorrect address translation or machine check on either logical processor. This erratum may result in unexpected faults, an uncorrectable TLB error logged in IA32_MCI_STATUS.MCACOD bits [15:0], a guest or hypervisor crash, or other unpredictable system behavior"

oakwhiz 13y ago

I don't understand why this would be the case: 3. It recently came to my attention that this microcode update might forbid unsupported (by Intel) overclocking on 4th gen Core "K" processors installed on motherboards that lack a Z-series chipset.

pktgen 13y ago
They only want people that pay extra for Z chipsets to be able to overclock. Pretty ballsy of them to release an update that disables functionality for no good reason. (Intel's bottom line isn't a good reason.)
simcop2387 13y ago
Following some of the links in the mail thread[1] it sounds like intel only allows it on the Z series chipsets for various reasons. And some mother board manufacturers have been enabling it on the sly to let people without them to do some amount of overclocking. [1] http://www.bit-tech.net/news/hardware/2013/07/25/intel-overclocking-block/1 http://www.bit-tech.net/news/hardware/2013/07/25/intel-overc...
- yuhong 13y ago
  I wonder how does it detect the chipset being used.
  - 4ad 13y ago
    It's in the CPU which is connected to the physical memory. Detecting the chipset is as trivial as reading a few bytes from the memory.
keeperofdakeys 13y ago
This has mostly always been the case. Also consider the microcode has to be loaded every time the OS is booted (or be baked into the bios image). So it doesn't really mean much.

andyzweb 13y ago

>implying this isn't a new patch from the NSA

bastawhiz 13y ago
The NSA would have to be damn slick to fit any kind of spying tool into a CPU bitcode update. The CPU doesn't know what the code that it's running does or what the data that it's handling is. It would need to set aside memory to do pattern matching on the code/data being processed to introduce any kind of back door. Then, it would need to hide the back door so nobody notices, which would potentially involve huge amounts of code to disguise the fact that the data has been modified. An example of an attack would be for the NSA to muck with random number generation to bias it towards certain values in a very subtle way. That would mean that encryption would be less strong, since the total number of possible values needed to brute force is lower. This would be difficult to hide: if they attacked say, RdRand, anyone using/researching RdRand would be able to see that it's no longer NIST/FIPS/ANSI compliant. They would need to attack it such that the back door was only open when nobody was looking (when there's not a very large number of those commands being run, or when the command is part of a larger piece of code). Even then, anyone studying the final output from the affected code could potentially determine that the random number source was biased. Either way, I'd think that an attack like this would be pretty damn hard to pull off, and Intel has very little reason to help the NSA with that. Can you imagine if it was found out that Intel was helping the NSA by weakening encryption? Everyone would go out and buy an AMD machine.
- crististm 13y ago
  To continue the conspiration theory further, the attack vector would certainly start with AMD when no one was looking :)
- Someone 13y ago
  Would it be that hard? I would think of: - snoop the instructions being read. - continuously compute a CRC from those bytes, resetting the CRC to zero when encountering a magic value, say when encountering a jump instruction. - whenever the CRC hits some magic number, shortcut the random number generator to return a few hundred zeroes. Alternatively, one can have a similar circuit attempting to detect the password checking code, and have the first code set a 'please let the next password comparison instruction succeed' flag. The two circuits even could be the same: for a given sequence of 'check password' instructions, it is easy to make the hardware or microcode handle some special password as a universal key. And yes, that is 'for a given sequence of instructions', but those won't change that often in popular OSes, and you can always issue a microcode update if, say, a service pack, security update or compiler change changes that sequence. Tinfoil hat of: I think Intel could easily do something like that, but I doubt they do. Some day, somebody will reverse engineer that CPU, notice a small, weirdly connected part and get curious as to what it is doing.

sounds 13y ago

More information about the bug: https://launchpad.net/debian/+source/intel-microcode/1.20130808.2 https://launchpad.net/debian/+source/intel-microcode/1.20130... https://bugs.launchpad.net/intel/+bug/1212497 https://bugs.launchpad.net/intel/+bug/1212497 Intel.com link for downloading the raw microcode update: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23082 https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Dwnl...

comex 13y ago

What I'd give to see a textual diff of the source code to that microcode update (which is, for the record, encrypted and signed).

4ad 13y ago
The microassembly means nothing unless you have the full schematics of the CPU.

GICodeWarrior 13y ago

Intel releases new microcode relatively frequently. There appear to be about 13 microcode updates for the i7 since launch. https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Processors&ProductLine=Desktop&ProductProduct=Intel%C2%AE+Core%E2%84%A2+i7+Desktop+Processor&ProdId=3426&LineId=3004&FamilyId=24 https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&... If I understand correctly, most of the updates are designed to fix bugs related to surrounding hardware (motherboards, memory). If you look at the BIOS updates for your computer/motherboard, you might notice notes about microcode updates. The BIOS can apply these just as easily as the OS, and when they are hardware compatibility issues, that is the only way for it to work. Not every update makes it into a BIOS version for every board, and not every version makes it into a Windows update (AFAIK).

zurn 13y ago
This addesses a real vuln though, "classified by Intel as a security issue, that affects any server running 32-bit VMs in PAE mode"

ck2 13y ago

I wonder if this will make it to Redhat/CentOS and how long it will take.

BuildTheRobots 13y ago
I got a CentOS announcement this morning in my email, so it should already be there: https://rhn.redhat.com/errata/RHEA-2013-1202.html https://rhn.redhat.com/errata/RHEA-2013-1202.html

superkuh 13y ago

http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ provides a good background summary of microcode on AMD/Intel CPU in general.