Date: Fri, 20 Nov 2015 04:12:28 -0500 From: grarpamp <grarpamp@gmail.com> To: freebsd-questions@freebsd.org Cc: freebsd-hardware@freebsd.org Subject: Is processor microcode advised? Message-ID: <CAD2Ti2-0jKLn9RXR5hc5FgZac_CbMnFMHf_XK2vc9f_nuZM=NQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
> Is it important/necessary/advisable to install microcode for Microcode are fixes, tweaks, new stuff and restrictions, some documented, some not, it's all extremely closed source anyway (SHAME) to due to marketing, embarrassment, recalls, the NSA, and so on... so who knows. Examples.. TSX-NI in Haswell is broken, microcode update disables it so you don't fubar your databases, etc. 32bit VM PAE, and so on. > Intel CPU's? AMD and others too. > If so, how do you know which CPU's have updates? devcpu-data and cpuctl and file access times will tell you. It's resident on die until reboot, not flashed, and it's crypto signed, versioned and model specific, so you can't screw it up unless Intel does. > what do you look for in dmesg output? There are messages from the tools and/or kernel, you might need verbose, run them manually once, you'll see it. > Also, I see microcode_update has to load the cpuctl module. What are the > implications of this WRT security? It exposes /dev/cpuctl which may or may not have issues of its own. If you've got monkeys running around in your system as root or otherwise, whether or not you unload it is irrelavent. You'd likely get more security mileage by taking care of these... find -s / -perm +7022 -ls Until something bad hits the news, or your tinfoil hat starts arcing, just apply them by default and forget about it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti2-0jKLn9RXR5hc5FgZac_CbMnFMHf_XK2vc9f_nuZM=NQ>