freebsd security - May 2019 - [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:07.mds

On 5/15/2019 8:18 AM, 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?

Actually, just tried this on RELENG_11 (r347613)? and I get

don't know how to load module '/boot/firmware/intel-ucode.bin'

In boot/loader.conf I have

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

# ls -l /boot/firmware/intel-ucode.bin
-rw-r--r--? 1 root? wheel? uarch 2571264 May 15 08:47
/boot/firmware/intel-ucode.bin

# sha256 /boot/firmware/intel-ucode.bin
SHA256 (/boot/firmware/intel-ucode.bin)
1fdb3a25467d285394eded8039ee8ab488f074903654981d35a4cdfe6ebf12fc

> On 15 May 2019, at 15:32, mike tancsa <mike at sentex.net> wrote:
> 
> Actually, just tried this on RELENG_11 (r347613)  and I get
> 
> don't know how to load module '/boot/firmware/intel-ucode.bin'
> 
> In boot/loader.conf I have
> 
> cpu_microcode_load="YES"
> cpu_microcode_name="/boot/firmware/intel-ucode.bin?
I used this:
microcode_update_enable=?YES"


on /etc/rc.conf with the devcpu-data port installed and as far as I know it
updated the microcode.

The script in /usr/local/etc/rc.d used cpucontrol(8) to load it.

Or am I holding it wrong? 



Borja.

cpu_microcode_load="intel-ucode?

Don?t remember that as needing to be yes but could be wrong.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a
lot about anticipated traffic volume.
> On May 15, 2019, at 08:32, mike tancsa <mike at sentex.net> wrote:
> 
> cpu_microcode_load="
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20190515/3a934890/attachment.bin>

On Wed, May 15, 2019 at 8:33 AM mike tancsa <mike at sentex.net>
wrote:
>
> On 5/15/2019 8:18 AM, 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?
>
>
> Actually, just tried this on RELENG_11 (r347613)  and I get
>
> don't know how to load module '/boot/firmware/intel-ucode.bin'
>
> In boot/loader.conf I have
>
> cpu_microcode_load="YES"
> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
>
> # ls -l /boot/firmware/intel-ucode.bin
> -rw-r--r--  1 root  wheel  uarch 2571264 May 15 08:47
> /boot/firmware/intel-ucode.bin
>
> # sha256 /boot/firmware/intel-ucode.bin
> SHA256 (/boot/firmware/intel-ucode.bin) >
1fdb3a25467d285394eded8039ee8ab488f074903654981d35a4cdfe6ebf12fc
>
r337715 + r337716 were responsible for making this work, and they've
not yet been MFC'd as far as I can tell. CC markj@, because that's
probably good to sneak in soon.

On Wed, May 15, 2019 at 09:33:50AM -0500, Kyle Evans
wrote:
> On Wed, May 15, 2019 at 8:33 AM mike tancsa <mike at sentex.net>
wrote:
> >
> > On 5/15/2019 8:18 AM, 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?
> >
> >
> > Actually, just tried this on RELENG_11 (r347613)  and I get
> >
> > don't know how to load module
'/boot/firmware/intel-ucode.bin'
> >
> > In boot/loader.conf I have
> >
> > cpu_microcode_load="YES"
> > cpu_microcode_name="/boot/firmware/intel-ucode.bin"
> >
> > # ls -l /boot/firmware/intel-ucode.bin
> > -rw-r--r--  1 root  wheel  uarch 2571264 May 15 08:47
> > /boot/firmware/intel-ucode.bin
> >
> > # sha256 /boot/firmware/intel-ucode.bin
> > SHA256 (/boot/firmware/intel-ucode.bin) > >
1fdb3a25467d285394eded8039ee8ab488f074903654981d35a4cdfe6ebf12fc
> >
> 
> r337715 + r337716 were responsible for making this work, and they've
> not yet been MFC'd as far as I can tell. CC markj@, because that's
> probably good to sneak in soon.
I'm working on this.  In any case, 11.2 doesn't have and won't get
boot-time microcode update support, so an updated SA with instructions
for 11 will be released shortly.