4 ms·

Despite the name, this is not Linux-specific microcode. If you're running SmartOS or another illumos derivative, run ucodeadm(1) on the microcode.dat file (whic

Despite the name, this is not Linux-specific microcode. If you're running SmartOS or another illumos derivative, run ucodeadm(1) on the microcode.dat file (which will need to be renamed to have an "intel" prefix per the man page -- e.g., "intel-code.txt"). You can then run "ucodeadm -v" to validate that the new microcode has been loaded. (Note that this does not persist across a reboot, but we at Joyent are currently in the process of upstreaming the microcode into illumos, at which point it will.)

foxhop 9y ago
Awesome! Thanks for this!
1000units 9y ago
And slow down my computer? No thanks.
- djsumdog 9y ago
  A microcode update is applied directly to the processor, typically during the boot process, and is a common practice to fix CPU bugs. It changes the microcode running on the hardware itself. This is totally different from the kernel PTI fixes, which attempt to deal with Meltdown by changing the way the operating systems for Linux/Mac/Windows/DragonFly (and hopefully soon *BSD) interacts with the hardware and page tables. Also you're making a statement without the above comment even stating if this update is designed to address Spectre or Meltdown.
  - kev009 9y ago
    What he said isn't wrong, this new ucode changes fencing and branching prediction semantics regardless of using the instructions added for spectre. The problem is varied. While most people should run the new ucode and pending kernel and toolchain fixes, not all must. Most businesses buy computers on rated performance, and they are about to take an unexpected performance haircut. Intel ucode isn't really optional, as there is no public change log and it is unknowable what critical stability fixes are within. so even in a closed system you can't selectively ignore it without some amount of negligence. This presents a big problem for HPC and other closed systems. IBM, a more professional and customer focused HPC vendor, is offering a firmware flag to preserve pre-spectre behaviors. Most closed monolithic HPC clusters can ignore these vulns and the associated nvidia one.
    - djsumdog 9y ago
      I wonder if this will end with Intel selling a lot of new chips, or Intel having to issue massive recalls. I doubt Intel will be able to be able to get away with discount/trade-ins without some serious legal complications. I doubt we'll see entire data centers move to AMD as that would get stupid expensive. For the short term, we might see data centers order extra AMD blades and changing their provisioning systems to pin high IO tasks to those machines. And that's for people who co-locate or host their own stuff. I'm interested to see how this affects Infrastructure providers who abstract a lot of that away, like AWS, DigitalOcean, Rackspace and others. They might even be working on analysis and auto-migration to move high IO nodes to higher performance machines transparently. It will be interesting to see what hosting providers start blogging about in the next few weeks.
      - kev009 9y ago
        The first would set a strange precedent without some kind of good faith amends by intel, and so far they have signaled apathetic callousness. I think the legal implications haven't even begun to arise yet because large users are still scrambling to understand the impact and deal with what they have on hand. I speculate some kind of recall or prorate program will come out of it in time. Dieselgate is the closest thing I can think of recently where a product was marketed primarily on performance that was later rescinded through mechanical and/or software clamping. I wonder if there will be any FTC action for consumers. Separate from the above thoughts, intel was already testing customer patience with Skylake. It wasn't a substantial performance increase, but it was a substantial pricing increase. A lot of that, because, in merging the 4S (E5-4xxx) and 8S (E7) into one marketing line, a majority of users are paying big premiums for unwanted UPI scalability to get clock speed, cores, and caches they do want. They also gambled poorly on clamping I/O lanes to fight GPU, and with omnipath which is a niche at best. History will most likely judge Krzanich poorly. I expect AMD and IBM will have a good couple years coming up.
    - tedunangst 9y ago
      Doesn't the microcode expose new MSRs to control branch prediction? If you don't want to, don't clear the cache.

foxhop 9y ago

Awesome! Thanks for this!

1000units 9y ago

And slow down my computer? No thanks.

djsumdog 9y ago
A microcode update is applied directly to the processor, typically during the boot process, and is a common practice to fix CPU bugs. It changes the microcode running on the hardware itself. This is totally different from the kernel PTI fixes, which attempt to deal with Meltdown by changing the way the operating systems for Linux/Mac/Windows/DragonFly (and hopefully soon *BSD) interacts with the hardware and page tables. Also you're making a statement without the above comment even stating if this update is designed to address Spectre or Meltdown.
- kev009 9y ago
  What he said isn't wrong, this new ucode changes fencing and branching prediction semantics regardless of using the instructions added for spectre. The problem is varied. While most people should run the new ucode and pending kernel and toolchain fixes, not all must. Most businesses buy computers on rated performance, and they are about to take an unexpected performance haircut. Intel ucode isn't really optional, as there is no public change log and it is unknowable what critical stability fixes are within. so even in a closed system you can't selectively ignore it without some amount of negligence. This presents a big problem for HPC and other closed systems. IBM, a more professional and customer focused HPC vendor, is offering a firmware flag to preserve pre-spectre behaviors. Most closed monolithic HPC clusters can ignore these vulns and the associated nvidia one.
  - djsumdog 9y ago
    I wonder if this will end with Intel selling a lot of new chips, or Intel having to issue massive recalls. I doubt Intel will be able to be able to get away with discount/trade-ins without some serious legal complications. I doubt we'll see entire data centers move to AMD as that would get stupid expensive. For the short term, we might see data centers order extra AMD blades and changing their provisioning systems to pin high IO tasks to those machines. And that's for people who co-locate or host their own stuff. I'm interested to see how this affects Infrastructure providers who abstract a lot of that away, like AWS, DigitalOcean, Rackspace and others. They might even be working on analysis and auto-migration to move high IO nodes to higher performance machines transparently. It will be interesting to see what hosting providers start blogging about in the next few weeks.
    - kev009 9y ago
      The first would set a strange precedent without some kind of good faith amends by intel, and so far they have signaled apathetic callousness. I think the legal implications haven't even begun to arise yet because large users are still scrambling to understand the impact and deal with what they have on hand. I speculate some kind of recall or prorate program will come out of it in time. Dieselgate is the closest thing I can think of recently where a product was marketed primarily on performance that was later rescinded through mechanical and/or software clamping. I wonder if there will be any FTC action for consumers. Separate from the above thoughts, intel was already testing customer patience with Skylake. It wasn't a substantial performance increase, but it was a substantial pricing increase. A lot of that, because, in merging the 4S (E5-4xxx) and 8S (E7) into one marketing line, a majority of users are paying big premiums for unwanted UPI scalability to get clock speed, cores, and caches they do want. They also gambled poorly on clamping I/O lanes to fight GPU, and with omnipath which is a niche at best. History will most likely judge Krzanich poorly. I expect AMD and IBM will have a good couple years coming up.
  - tedunangst 9y ago
    Doesn't the microcode expose new MSRs to control branch prediction? If you don't want to, don't clear the cache.