Date: Fri, 20 Nov 2015 09:43:59 -0600 From: Will Senn <will.senn@gmail.com> To: grarpamp <grarpamp@gmail.com>, freebsd-questions@freebsd.org Cc: freebsd-hardware@freebsd.org Subject: Re: Is processor microcode advised? Message-ID: <564F3FBF.8050603@gmail.com> In-Reply-To: <CAD2Ti2-0jKLn9RXR5hc5FgZac_CbMnFMHf_XK2vc9f_nuZM=NQ@mail.gmail.com> References: <CAD2Ti2-0jKLn9RXR5hc5FgZac_CbMnFMHf_XK2vc9f_nuZM=NQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/20/15 3:12 AM, grarpamp wrote: >> 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. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" Thank you for the reply and for covering so much territory. I checked dmesg for anything like cpu or micro and nothing about microcode updates was displayed. I did: ps aux|grep cpu and ps aux | grep micro and there were no processes running. I dug around and found the startup script: /usr/local/etc/rc.d/microcode_update I looked at it and ran it: sudo /usr/local/etc/rc.d/microcode_update start Updating cpucodes... Done. Still no processes. I looked at the microcode_update script again and thought about what you said about running with verbose, so working off of the script, I ran: sudo /usr/sbin/cpucontrol -v -u -d "/usr/local/share/cpucontrol/" /dev/cpuctl0 cpucontrol: skipping /usr/local/share/cpucontrol//m101067770A.fw of rev 0x70a: up to date cpucontrol: skipping /usr/local/share/cpucontrol/m101067770A.fw of rev 0x70a: up to date and the same for all 4 cpus What I infer from this is that my CPU's are already as up to date as the microcode database is and therefore no process is needed or kept resident. Am I understanding this correctly? Also, shouldn't there be messages in dmesg for the startup script? I have the /etc/rc.conf setting: microcode_update_enable="YES" and /usr/local/etc/rc.d/microcode_update has: ... microcode_update_start() { echo "Updating cpucodes..." ... I would think I would at lest see "Updating cpucodes..." with dmesg. What is going on? - Will
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?564F3FBF.8050603>