Date: Wed, 15 May 2019 16:29:46 +0200 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:07.mds Message-ID: <4d441f47-b81c-bcde-c7e2-a8906c4d134b@rlwinm.de> In-Reply-To: <cdf6982694db447985b15e9170256fe5@exch-02.redcom.com> References: <20190515000302.44CBB1AB79@freefall.freebsd.org> <cdf6982694db447985b15e9170256fe5@exch-02.redcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15.05.19 14:18, Wall, Stephen wrote: >> New CPU microcode may be available in a BIOS update from your system vendor, >> or by installing the devcpu-data package or sysutils/devcpu-data port. >> Ensure that the BIOS update or devcpu-data package is dated after 2014-05-14. >> >> If using the package or port the microcode update can be applied at boot time >> by adding the following lines to the system's /boot/loader.conf: >> >> cpu_microcode_load="YES" >> cpu_microcode_name="/boot/firmware/intel-ucode.bin" > Is this applicable in a virtualized environment, or only on bare metal? > If not applicable in a VM, is it at least harmless? Afaik you can't modify the microcode inside a VM, but give them time. I'm sure Intel optimized that security check away as well in some corner case yet to be discovered.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d441f47-b81c-bcde-c7e2-a8906c4d134b>