Intel bug incoming.

I find it very interesting that Intel first didn't tell about offering microcode updates.
Apparently they decided to do so when they found out that in some jurisdictions this would even entitle customers to get full refund if they do not fix the processors to be in the specs they originally promised.
 
And note that the Spectre "mitigation" is not a complete prevention; it just makes the the problem less likely to occur. I think that a complete prevention of Spectre (both variants) will require major redesign of the CPUs itself (much more than a microcode fix can do), to always perform memory accessibility checking during speculative execution. Fortunately, Spectre is not an easy exploit, so the current compromise with an imperfect mitigation is probably good enough. And when I say "CPUs" above, I mean nearly all CPUs that perform speculative execution, not just Intel, nor just x86 instruction set CPUs like Intel and AMD.
 
Mhh. Flashing stuff is fickle and can brick things.
Do you think it's safe just to take a LiveCD, just for installing the microcode?
Or is it better to install for example Debian base system on a spare HD?
 
Yeah, I have my doubts too. Trying to find out now if this stuff is safe to use. Can't afford my computer getting hosed.
 
Eric Pancoast said:
Variant 2: Requires IBRS (Indirect Branch Restricted Speculation) and CPU microcode updates to mitigate.
Click to expand...

It does make sense. Meltdown patches are easy(-ier) to understand, spectre one are confusing to me (a bit), updated microcode added to my confusion.

Funny though as there's pressure on Intel but lots of people are forgetting to mention Itanium. It seems there is no problem there. So there's CPU where Intel did it right.
 
_martin said:
It does make sense. Meltdown patches are easy(-ier) to understand, spectre one are confusing to me (a bit), updated microcode added to my confusion.
Click to expand...

I guess we'll never know exactly how the microcode update alters the processor's function to expose additional functionality to the kernel to achieve IBRS (https://lkml.org/lkml/2018/1/4/615).

Update: I think it's also worth reiterating that it seems the microcode update is not everything you need to protect against certain aspects of Spectre. An OS kernel update is also required to make use of the microcode update.
 
MarcoB said:
Itanium is also in the list of the microcode update, so maybe it's for the Spectre variant?
Click to expand...

That's actually a good catch!

Today we were talking about the issue , I can't talk too much about it, but the oficial statement is - not affected. I was actually saying (and mentioned it even in this thread) that I have doubt about that unless there's something really different in the design (predicament regs, cache flush, etc..).

This surprised me now ..
 
lyuts said:
I don't think it is sufficient. My understanding is that microcode has to be updated on every boot.
Click to expand...

Hornpipe2 said:
Remember that this wears off on reboot, so if you want it to stick then you must enable the update at boot: edit rc.conf and add
microcode_update_enable="YES"
Click to expand...

According to this thread, the microcode itself is managed by the port, so I'd be careful about updates to that port introducing new microcode without you being fully aware.
 
The microcode here needs to be re-applied on every reboot; it is not a permanent flash/burn/whatever of the CPU. With respect to who manages the port, the microcode updates themselves are encrypted by intel, so I'd think it highly unlikely that you can get a non-intel-blessed microcode update to apply itself, unless Intel accidentally releases the encryption key...

https://superuser.com/questions/1229317/can-intel-microcode-updates-be-rolled-back
 
I built the sysutils/devcpu-data port and ran it with the proper line in etc/rc.conf on one of my Thinkpads with Intel Core2 Duo T7300 @ 2.00GHz.

During the boot cycle it showed:

Code: 
Updating CPU Microcode...
Re-evaluation of CPU flags Failed
I get the same result running # service microcode_update start.

So evidently it didn't do anything, it is almost 10 years old, but at least it didn't brick it cause I'm using it now. :)
 
Trihexagonal said:
I built the sysutils/devcpu-data port and ran it with the proper line in etc/rc.conf on one of my Thinkpads with Intel Core2 Duo T7300 @ 2.00GHz.

During the boot cycle it showed:

Code: 
Updating CPU Microcode...
Re-evaluation of CPU flags Failed
I get the same result running # service microcode_update start.

So evidently it didn't do anything, it is almost 10 years old, but at least it didn't brick it cause I'm using it now. :)
Click to expand...

grep micro /var/log/messages ?
 
Code: 
root@relentless:/ # grep micro /var/log/messages
Jan 10 17:05:46 relentless microcode_update: /usr/local/share/cpucontrol/m806fbBA.fw: updating cpu /dev/cpuctl0 from rev 0xb6 to rev 0xba... done.
Jan 10 17:05:46 relentless microcode_update: /usr/local/share/cpucontrol/m806fbBA.fw: updating cpu /dev/cpuctl1 from rev 0xb6 to rev 0xba... done.

I couldn't even tell it had applied them so if it took a performance hit I don't see it yet.

Edit: I tried it on my i386 box with Intel Dual Core T2060 @ 1.60GHz with the same

Code: 
Updating CPU Microcode...
Re-evaluation of CPU flags Failed
message but don't get a return on # grep micro /var/log/messages.
 
Eric A. Borisch said:
With respect to who manages the port, the microcode updates themselves are encrypted by intel, so I'd think it highly unlikely that you can get a non-intel-blessed microcode update to apply itself, unless Intel accidentally releases the encryption key...
Click to expand...

This is a great point.

Also, for those who haven't necessarily had to worry about microcode updates for the security of their systems in the past, I think it makes sense to recognize that introducing this port, and the rc.conf option, could represent an unexpected source of instability. Especially because if you ran "pkg upgrade" without a restart, you could be introducing new microcode updates into "/usr/local/share/cpucontrol/" that would only be loaded when the system is rebooted.

Of course, there should be a process for applying updates like these to "staging" environments and verifying the systems operate as expected before applying them to critical systems, but I think it's still worth mentioning.
 
Eric Pancoast said:
Of course, there should be a process for applying updates like these to "staging" environments and verifying the systems operate as expected before applying them to critical systems, but I think it's still worth mentioning.
Click to expand...

Which is what ZFS + boot environments excel at.

Easiest path:
  1. beadm create YYYYMMDD
  2. Do install/upgrade process
  3. Reboot
If the upgraded system fails for some reason, reboot again, and choose your old BE from the loader menu. (Or use beadm activate YYYYMMDD if you can login.) Be sure to “activate” it when you are up such that it persists for the next reboot.

Edit: As with any snapshot of a running system, if you have services (e.g. a database) modifying critical on-disk state that is managed by beadm (under zroot/ROOT/*), you'll want to shut those down before performing the beadm create.
 
MarcoB said:
Itanium is also in the list of the microcode update, so maybe it's for the Spectre variant?
Click to expand...
Very strange. I had heard a while ago that Itanium was immune from Meltdown and Spectre. If you think about the Itanium architecture, that actually makes perfect sense: Instead of a single stream of narrow (CISC or RISC) instructions, every instruction word is very wide (thence VLIW), and explicitly directs the various parts of the chip on what to do. Instead of speculative execution and parallelism by implicitly running instructions from multiple threads at once, the parallelism is made explicit in the instruction stream. Without speculative execution, Itanium should not be vulnerable to these two problems.

So now I wonder: why is Itanium getting a microcode update? Something doesn't quite add up here. Perhaps what I wrote above is not 100% correct?
 
There is a thread about this on Phoronix (yes, I know :)), where someone stated that this microcode is only helping to mitigate the risk on Spectre. I think this could be true and that this microcode is not a patch in itself but is some kind of preparation to make the fixes of the different os's possible.
 
Where does this sysutils/devcpu-data stuff install to?
whereis doesn't tell anything where I can look at the files.
Code: 
# service microcode_update onestart
Updating cpucodes...
Done.
#
No information in /var/log/messages either.
How do I find out whether it actually did something except of printing the message?

Regarding Itanium, the fact that it also got a patch despite being "not affected", is telltale about the trustworthiness of Intel official statements.
 
Snurg said:
Where does this sysutils/devcpu-data stuff install to?
whereis doesn't tell anything where I can look at the files.
Click to expand...
In /usr/local/share/cpucontrol.
Regarding Itanium, the fact that it also got a patch despite being "not affected", is telltale about the trustworthiness of Intel official statements.
Click to expand...
Intel is doing damagecontrol at the moment and spreading some fud. But afaik only Intel x86 is vulnerable for Meltdown, and just about all processors with branch prediction are vulnerable for Spectre.
 
You must log in or register to reply here.
Back
Top