> > Not all the microcode is to fix Spectre! True enough, but I don't feel an urgency to fix anything else. ;-)
> > My experience is that intel microcode for older processors does not > get changed, but they copy it into the latest tarball. Intel took some heat for their early attempts at deflection, which is why they've released this ancient microcode, I suppose. The question remains whether it, say the P3 microcode, patches the Spectre flaw--if anybody still at Intel even knows the P3 microcode well enough to do it! > > And no, I also don't think CPUs before the Pentium4 can have > microcode updated at runtime. But the P3 is apparently used in > embedded products, perhaps manufacturers can use the microcode to > refresh their bios. Perhaps, but one sees little incentive for them. I think we have to go straight for the CPU ourselves with the Linux kernel. > > If you get microcode for an old Intel CPU, and load it, you should > be able to see in dmesg the before/after versions, and the date. > Alternatively, your motherboard may already be using that version. /proc/cpuinfo says I've got microcode 0xcb on my twin Conroes. I'm not even going to *try* to update the microcode unless and until I can establish it's going to mitigate Spectre. Only one good thing can happen, many bad things. A couple years ago, when I backed up my i7-940 with an i7-870, I checked for microcode updates. The 870 had one/some, the 940 did not. Likewise, even if updates are published, I need to know what they do before I make a move. > > For matching filenames to hardware, I guess you mean the family - > - model - stepping part : I don't know of any way to convert that to > particular CPUs, /proc/cpuinfo gives us that, plus the microcode level. > > If you still have a problem, please ask. I'm not going to *create* a problem until I have some confidence it's worth the risk. I'm certainly not going to take the risk, just to end up with the same microcode level. I want to see something from Intel that details what microcode levels each of those files are at, and given the nature of things, that Spectre is or is not mitigated. > > One further comment: although the debian microcode that I posted > about last week does work as a (large) initrd to cover multiple > machines (in early loading), I have no idea how to generate such a > multi-machine initrd. That is why near the top of the page I wrote: > "Preparing firmware for multiple different machines, as a distro > would do, is outside the scope of this book." > > ĸen I have avoided using initrds, and want to continue to do so. I don't build POD with the idea it will be thrown at arbitrary hardware. Initial kernels are built monolithically to boot on reasonably common hardware of a certain vintage, but after booting the sysadmin is expected to soon build a customized kernel, eliminating a lot of HD drivers, adding NIC, ALSA, AGP/FB/DRI--none of which are *necessary* to boot. -- Paul Rogers paulgrog...@fastmail.fm Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
