early x86 microcode loading

[Mark Johnston]

On Thu, Jul 12, 2018 at 03:30:15PM -0400, Shawn Webb wrote:
> Hey Mark,
> 
> Thank you very much for working on this and opening the discussion.
> What you've drafted sounds reasonable to me, but perhaps with one
> edge case.
> 
> On Thu, Jul 12, 2018 at 02:31:16PM -0400, Mark Johnston wrote:
> > I've been working on support for early loading of microcode updates and
> > wanted to solicit feedback on the approach before starting to get any
> > code changes reviewed.
> > 
> > Currently we support microcode updates via cpuctl(4), where
> > cpucontrol(8) passes microcode blobs to the kernel via an ioctl
> > interface.  Updates are distributed by the sysutils/devcpu-data port.
> > The scheme has a few shortcomings:
> > - Microcode updates may introduce new CPU features, but since we load
> >   microcode from userland, updates are performed well after the kernel
> >   has done CPU feature detection.
> > - Updates need to be reapplied after an ACPI suspend/resume, and there's
> >   currently no mechanism to automatically reapply the update after a
> >   resume.
> > - Updates aren't applied until userspace starts running, so there exists
> >   a window in which the kernel is running without vulnerability
> >   mitigations provided by microcode updates.
> > 
> > The aim of this work is to instead use the boot loader to load microcode
> > updates into kernel memory, and modify the kernel to apply the updates
> > as the first step in BSP and AP initialization, as well as after an ACPI
> > resume.  To configure an update, one would then just need to add the
> > following lines to loader.conf:
> > 
> > cpu_ucode_load="YES"
> > cpu_ucode_name="/boot/firmware/microcode.bin"
> > cpu_ucode_type="cpu_ucode"
> > 
> > The kernel would then automatically load the update during processor
> > initialization in the subsequent boot-up.
> > 
> > A given Intel microcode update applies only to CPUs of a specific
> > <family, model, stepping> tuple, while AMD releases a single update per
> > processor family.  My plan is to extend cpucontrol(8) to determine the
> > correct microcode update for the running system, and have the devcpu-data
> > port install the corresponding file to /boot/firmware.  The port could
> > then add the following to loader.conf.local:
> > 
> > devcpu_data_load="YES"
> > devcpu_data_name="/boot/firmware/<update file>"
> > devcpu_data_type="cpu_ucode"
> 
> I'm curious about what would happen if I moved the drives to a new
> system and booted off of them, perhaps forgetting to comment out the
> above lines in loader.conf beforehand.
> 
> Additionally, how would I instruct the system in such a case to
> re-probe which firmware file I need?
> 
> I recognize this could be construed as an edge case, but I've done
> this multiple times (and, thanks to ZFS, really easily).

This is being discussed in another subthread.  Right now, an update
simply wouldn't be applied during the first boot.  My notion is that an
rc script provided by the port would automatically reconfigure the
update, so it'd be applied upon a subsequent reboot.