Intel gives Broadwells and Haswells their Meltdown medicine Intel slipped out a new Microcode Update Guidance on Monday, revealing that lots of Haswell and Broadwell Xeons can now receive inoculations against the Meltdown and Spectre CPU design flaws. The new document (PDF) says Broadwell processors with CPUIDs 50662, 50663, 50664, 40671, 406F1, 306D4 and 40671 are ready for their …
In general, CPUs are not re-flashable because they contain no field writable storage to hold updates, so non-persistent CPU microcode updates are developed by the CPU designer/manufacturer and are applied, and re-applied, by the OS every time the system boots. If you're on Windows it'll be down to Microsoft to package the microcode, once they get it from Intel/AMD (and possibly ARM, or ARM manufacturers), so that Windows can apply it during boot.
Motherboard manufacturers are responsible for the mobo BIOS, which controls how the different parts of the mobo operate and talk to each other. Mobos do have field writable storage to allow persistent updates to the BIOS.
(1) You probably aren't a target anyway. Virtualised server farms are.
(2) You can only buy a new one with a performance reducing bodge at the moment.
(3) This is possibly not the best way to reward poor design decisions over decades.
If you do buy new buy AMD. At least you only have Spectre issues.
I don't plan to replace my Core 2 Duos and Quad any time soon.
The microcode is needed for Spectre V2. Ubuntu already has the Retpoline workaround in their kernels addressing this. Call out to RedHat - why can't you do this?
Retpolines are faster than the microcode. If at all possible, use them instead. Below is an ancient Core Duo that is fully protected.
root@squib:~# ./spectre-meltdown-checker.sh ...
Kernel is Linux 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64
CPU is Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz...
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'...
> STATUS: NOT VULNERABLE (Mitigation: OSB (observable speculation barrier, Intel v6))
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'...
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'...
> STATUS: NOT VULNERABLE (Mitigation: PTI)
The retpoline fix, IMHO, is not a complete mitigation for Spectre V2.
What has been described is a change to the compiler/compiler flags used when the kernel was compiled.
As I understand it, retpoline will prevent a call from generating speculative execution at the time of the call, so now the kernel has been compiled with this fix, the kernel will not have any speculative execution occurring whenever it performs a call.
But what runs on these systems is more than just the kernel. Compile time fixes need to be performed on all code that runs on the system, and the kernel is just part of a running system.
You would also have to re-compile the whole of the repository if you wanted to also roll this out to a Ubuntu system, and that pre-supposes that you don't have any code compiled without the retpoline options present on your system.
But even this is not enough. If there was a remote execution vulnerability that allowed executable code to be dropped onto your system and executed, then you have ABSOLUTELY NO CONTROL over whether that has a retpoline fix in it, and you can bet your last dollar that the code would not have the workaround.
Add to that the possibility of locating sequences of bytes that form valid code for performing a Spectre type 2 attack on the system already, and you should be able to see that retpoline fixes in the kernel are seriously not enough to mitigate this attack.
Just my 2 penny's worth.
"nothing listed for mine yet - a Q6600 (yeah a 10 year old core quad)."
The outlook isn't good - Intel has published their Microcode Guidance document and it doesn't mention Kentsfield CPU's - which your Q6600 is. Intel seems to keep updating this doc but since your CPU wasn't mentioned even in the beginning it looks like anything over 10 years old will not be supported.
I've never had to bother much with the full CPUID before.
Is My CPUID 306C3 I Don't know
#Intel(R) Processor Identification Utility gives
(Search Intel Processor Identification Utility)
Processor Name: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Type: 0
Family: 6
Model: 3C
Stepping: 3
Revision: 1A
#CUP-Z from CPUID gives similar but different revision C0
(Search CPU-Z)
#Other apps like Speecy might show the numbers that compose it too.
Is My CPUID the 306C3 mentioned ?? Intel points to comments by the manufacturers
Manufacturer ACER doesn't list my system Aspire TC-603 their website anymore
I suppose I could try a similar model If I were desperate, but as I am applying the other patches and not accessing clouds or VM's, I'll assume for now the Spectre #1 is alright left alone (unpatched).
When you feed i5-4570 into ark.intel.com, you get it's a Haswell. I've not a clue what my CPUID's are here. I'm much rather go right to the source using the info from the processor. It adds much more than just the CPU family, which while important, is especially important about AMT, virtualization features.... That's just me being me though.
I'm glad there's no patches for esxi. Vmware's QA has been terrible the last couple of years, there's going to be a ton of bugs going forward. I bet they don't have a massive team of engineers that deal with cpu functionality anymore as that core functionality hasn't changed for many years.
I recently played with amending AMI type BIOS, as I wanted a new Intel BIOS for RST, and it worked. Hopefully if they drop the microcode in useful formats, people can try rolling their own (if they are suitably equipped).
At least my Gigabyte motherboard has Dual-BIOS, so I can't *totally* kill it...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
