From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752266AbdHDLYH (ORCPT ); Fri, 4 Aug 2017 07:24:07 -0400 Received: from mx3.molgen.mpg.de ([141.14.17.11]:41805 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752220AbdHDLYF (ORCPT ); Fri, 4 Aug 2017 07:24:05 -0400 Subject: Re: [tip:x86/microcode] x86/microcode: Document the three loading methods To: hpa@zytor.com, bp@suse.de, torvalds@linux-foundation.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, mingo@kernel.org, peterz@infradead.org References: <20170724101228.17326-3-bp@alien8.de> From: Paul Menzel Message-ID: <7e438573-b35d-eea8-8f8a-c341c4dd91a4@molgen.mpg.de> Date: Fri, 4 Aug 2017 13:24:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Borislav, Hopefully, it’s alright to reply to this message. I am sorry for the late reply. On 07/25/17 15:51, tip-bot for Borislav Petkov wrote: > Commit-ID: 0e3258753f8183c63bf68bd274d2cc7e71e5f402 > Gitweb: http://git.kernel.org/tip/0e3258753f8183c63bf68bd274d2cc7e71e5f402 Could you the script(?) please be updated to use HTTPS URLs? > Author: Borislav Petkov > AuthorDate: Mon, 24 Jul 2017 12:12:27 +0200 > Committer: Ingo Molnar > CommitDate: Tue, 25 Jul 2017 11:26:24 +0200 > > x86/microcode: Document the three loading methods > > Paul Menzel recently asked how to load microcode on a system and I realized > that we don't really have all the methods written down somewhere. > > Do that, so people can go and look them up. > > Reported-by: Paul Menzel > Signed-off-by: Borislav Petkov > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Link: http://lkml.kernel.org/r/20170724101228.17326-3-bp@alien8.de Here to please HTTPS. (It’s even using HTTP/2 then. Kudos to the administrators.) > [ Fix whitespace noise in the new description. ] > Signed-off-by: Ingo Molnar > --- > Documentation/x86/early-microcode.txt | 70 ----------------- > Documentation/x86/microcode.txt | 137 ++++++++++++++++++++++++++++++++++ > 2 files changed, 137 insertions(+), 70 deletions(-) > > diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt > deleted file mode 100644 > index 07749e7..0000000 > --- a/Documentation/x86/early-microcode.txt […] > --- /dev/null > +++ b/Documentation/x86/microcode.txt > @@ -0,0 +1,137 @@ > + The Linux Microcode Loader > + > +Authors: Fenghua Yu > + Borislav Petkov > + > +The kernel has a x86 microcode loading facility which is supposed to > +provide microcode loading methods in the OS. Potential use cases are > +updating the microcode on platforms beyond the OEM End-Of-Life support, > +and updating the microcode on long-running systems without rebooting. > + > +The loader supports three loading methods: > + > +1. Early load microcode > +======================= > + > +The kernel can update microcode very early during boot. Loading > +microcode early can fix CPU issues before they are observed during > +kernel boot time. > + > +The microcode is stored in an initrd file. During boot, it is read from > +it and loaded into the CPU cores. > + > +The format of the combined initrd image is microcode in (uncompressed) > +cpio format followed by the (possibly compressed) initrd image. The > +loader parses the combined initrd image during boot. > + > +The microcode files in cpio name space are: > + > +on Intel: kernel/x86/microcode/GenuineIntel.bin > +on AMD : kernel/x86/microcode/AuthenticAMD.bin > + > +During BSP (BootStrapping Processor) boot (pre-SMP), the kernel > +scans the microcode file in the initrd. If microcode matching the > +CPU is found, it will be applied in the BSP and later on in all APs > +(Application Processors). > + > +The loader also saves the matching microcode for the CPU in memory. > +Thus, the cached microcode patch is applied when CPUs resume from a > +sleep state. > + > +Here's a crude example how to prepare an initrd with microcode (this is > +normally done automatically by the distribution, when recreating the > +initrd, so you don't really have to do it yourself. It is documented > +here for future reference only). > + > +--- > + #!/bin/bash > + > + if [ -z "$1" ]; then > + echo "You need to supply an initrd file" > + exit 1 > + fi > + > + INITRD="$1" > + > + DSTDIR=kernel/x86/microcode > + TMPDIR=/tmp/initrd > + > + rm -rf $TMPDIR > + > + mkdir $TMPDIR > + cd $TMPDIR > + mkdir -p $DSTDIR > + > + if [ -d /lib/firmware/amd-ucode ]; then > + cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin > + fi > + > + if [ -d /lib/firmware/intel-ucode ]; then > + cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin > + fi > + > + find . | cpio -o -H newc >../ucode.cpio > + cd .. > + mv $INITRD $INITRD.orig > + cat ucode.cpio $INITRD.orig > $INITRD > + > + rm -rf $TMPDIR > +--- Maybe it could be added, that certain bootloaders like GRUB allow to specify several `initrd` images. So you wouldn’t need to concatenate the file [1]. > + > +The system needs to have the microcode packages installed into > +/lib/firmware or you need to fixup the paths above if yours are The verb *fix up* is spelled with a space. > +somewhere else and/or you've downloaded them directly from the processor > +vendor's site. > + > +2. Late loading > +=============== > + > +There are two legacy user space interfaces to load microcode, either through > +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file > +in sysfs. The *legacy* confuses me a little. Is it because `/sys` is used? > +The /dev/cpu/microcode method is deprecated because it needs a special > +userspace tool for that. > + > +The easier method is simply installing the microcode packages your distro > +supplies and running: > + > +# echo 1 > /sys/devices/system/cpu/microcode/reload > + > +as root. > + > +The loading mechanism looks for microcode blobs in > +/lib/firmware/{intel-ucode,amd-ucode}. The default distro installation > +packages already put them there. > + > +3. Builtin microcode > +==================== > + > +The loader supports also loading of a builtin microcode supplied through > +the regular firmware builtin method CONFIG_FIRMWARE_IN_KERNEL. Only > +64-bit is currently supported. > + > +Here's an example: > + > +CONFIG_FIRMWARE_IN_KERNEL=y > +CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" > +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" > + > +This basically means, you have the following tree structure locally: > + > +/lib/firmware/ > +|-- amd-ucode > +... > +| |-- microcode_amd_fam15h.bin > +... > +|-- intel-ucode > +... > +| |-- 06-3a-09 > +... > + > +so that the build system can find those files and integrate them into > +the final kernel image. The early loader finds them and applies them. > + > +Needless to say, this method is not the most flexible one because it > +requires rebuilding the kernel each time updated microcode from the CPU > +vendor is available. Thank you again for improving and extending the documentation for people like me. Kind regards, Paul [1] https://wiki.gentoo.org/wiki/Intel_microcode#Grub_2.x