Date: Thu, 12 Jul 2018 15:30:15 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180712193015.kvupmvmusqr3cy4y@mutt-hbsd> In-Reply-To: <20180712183116.GB15892@raichu> References: <20180712183116.GB15892@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
--5kuy3ysivzs6kzc7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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: >=20 > cpu_ucode_load=3D"YES" > cpu_ucode_name=3D"/boot/firmware/microcode.bin" > cpu_ucode_type=3D"cpu_ucode" >=20 > The kernel would then automatically load the update during processor > initialization in the subsequent boot-up. >=20 > 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: >=20 > devcpu_data_load=3D"YES" > devcpu_data_name=3D"/boot/firmware/<update file>" > devcpu_data_type=3D"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, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --5kuy3ysivzs6kzc7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAltHrEMACgkQaoRlj1JF bu7LQA//dVNHx9KaOEl52a4jOE4T7J5QxMPmD+SmDwVsoVcslkKvsPM5yciKrYTm s5CO7aAcNEJWmdpqjht3/IjKSXn3E3t7wr7y9+ca2ABGvuygPEa883R5IjNJD6i/ 4Oq3UPD4R6dOgyvtScm9qM0xKaQVM+CHgbA9YCUG048R3iGh/n7kbwX8g3BMkY2x dSwfR2Q05sArTgalxKreYWtsVTp/8LKnLhG/Un9weRJmwTHyWRTdw2Tq9AvT0uNM Xid0efGat8DDCHyLFCFP3rKwguqqFYNDjAmoxJSwnDxx30zd6JZIUqwwfghMEhuh dEpM6V9bR86YWnHWjXKLkobnVAzt/Bb42neQjxmvIDkzeAZOUOw3127p74zYR1lX Vbyiv9oYVv8Y2n2rT3W3IX6ZEEtqr81wlimLND7MDQLsHNsFO5tKJ2xAah/1njI0 SJ1qoBJwqBJYhKd/zAmPLsD7e3SDFTcH558kNQUCPgJR11lahM46VtMCAZweOB9y 0gbkVetaarY6mrVaIc7SwTacl+BfoD3n726Pr+gjQcxdyHMAPiGQCEuj4QtsOsDj Ab3xQ1FmKSdgK+u/w5PwUbWB0TV+Wbhr3epJ54R4o1WR16lr7RDQYU92TJVJSln0 Xc1WBkxsgDnV7Z23TOGesGDk+1pteXXF7MmDfk77oTdz8YxOl7I= =60x5 -----END PGP SIGNATURE----- --5kuy3ysivzs6kzc7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180712193015.kvupmvmusqr3cy4y>