From owner-freebsd-security@freebsd.org Wed May 15 14:29:57 2019 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E56E1592F1E for ; Wed, 15 May 2019 14:29:57 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 920D38D6E3 for ; Wed, 15 May 2019 14:29:56 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.bultmann.eu (unknown [IPv6:2a00:c380:c0d5:1:4173:7ee5:560:b0c1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id C9829D12E for ; Wed, 15 May 2019 14:29:46 +0000 (UTC) Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:07.mds To: freebsd-security@freebsd.org References: <20190515000302.44CBB1AB79@freefall.freebsd.org> From: Jan Bramkamp Message-ID: <4d441f47-b81c-bcde-c7e2-a8906c4d134b@rlwinm.de> Date: Wed, 15 May 2019 16:29:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 920D38D6E3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-4.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[rlwinm.de]; MX_GOOD(-0.01)[mail.rlwinm.de]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; IP_SCORE(-0.78)[ipnet: 2a01:4f8::/29(-2.09), asn: 24940(-1.78), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 14:29:57 -0000 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.