early x86 microcode loading

[Shawn Webb]

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).

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20180712/cb035a46/attachment.sig>