The Linux Microcode Loader

Linux microcode loader 개요

이 문서는 `SPDX-License-Identifier: GPL-2.0`으로 배포되며 Fenghua Yu `<[email protected]>`, Borislav Petkov `<[email protected]>`, Ashok Raj `<[email protected]>`가 작성했습니다.

kernel의 x86 microcode loading facility는 OS에서 microcode를 load하는 방법을 제공합니다. OEM End-Of-Life 지원이 끝난 platform의 microcode를 update하거나, 장시간 실행 중인 system을 reboot하지 않고 update하는 것이 가능한 사용 사례입니다.

loader는 early load, late loading, builtin microcode의 세 가지 방법을 지원합니다.

early load와 combined initrd

kernel은 boot의 매우 이른 시점에 microcode를 update할 수 있습니다. early loading은 kernel boot 중 CPU 문제가 관찰되기 전에 이를 고칠 수 있습니다.

microcode는 initrd file에 저장되며 boot 중 읽혀 CPU core에 load됩니다. combined initrd image는 uncompressed cpio 형식의 microcode 뒤에 압축될 수도 있는 initrd image를 붙인 구조입니다. loader가 boot 중 이 combined image를 parse합니다.

cpio namespace 안의 microcode file은 vendor별로 다음 위치에 있습니다.

• Intel: `kernel/x86/microcode/GenuineIntel.bin`
• AMD: `kernel/x86/microcode/AuthenticAMD.bin`

BSP(BootStrapping Processor)가 pre-SMP boot를 수행하는 동안 kernel은 initrd의 microcode file을 scan합니다. CPU와 일치하는 microcode를 찾으면 BSP에 적용하고 나중에 모든 AP(Application Processor)에도 적용합니다.

loader는 CPU와 일치하는 microcode를 memory에 저장합니다. 따라서 CPU가 sleep state에서 resume할 때 cached microcode patch가 적용됩니다.

microcode initrd 작성 예시

다음은 microcode가 포함된 initrd를 준비하는 단순 예시입니다. 보통 distribution이 initrd를 다시 만들 때 자동으로 수행하므로 직접 실행할 필요는 없으며, 향후 참고를 위해 제공됩니다.

#!/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

system에는 `/lib/firmware` 아래 microcode package가 설치되어 있어야 합니다. 다른 위치에 있거나 processor vendor site에서 직접 내려받았다면 위 script의 path를 수정해야 합니다.

late loading 방법과 현재 상태

distribution이 제공하는 microcode package를 설치한 뒤 root로 다음 명령을 실행합니다.

# echo 1 > /sys/devices/system/cpu/microcode/reload

loading mechanism은 `/lib/firmware/{intel-ucode,amd-ucode}`에서 microcode blob을 찾습니다. 기본 distribution package가 이미 이 위치에 file을 설치합니다.

kernel 5.19부터 late loading은 기본으로 활성화되지 않습니다. `/dev/cpu/microcode` 방식도 5.19에서 제거되었습니다.

late loading 위험: 모든 CPU 동기화

SMT system에서는 microcode update를 받는 engine을 core의 두 logical thread가 공유합니다. 따라서 한 SMT thread에서 update를 실행하면 sibling도 자동으로 update됩니다.

microcode는 MSR도 simulate할 수 있으므로 update가 진행되는 동안 simulated MSR이 일시적으로 사라집니다. 이때 SMT sibling이 해당 MSR에 access 중이면 예측할 수 없는 결과가 생길 수 있습니다. 흔히 관찰되는 결과는 MSR이 존재하지 않는다는 의미로 access에서 `#GP`가 발생하는 것입니다.

사라지는 MSR은 관찰된 흔한 문제 중 하나일 뿐입니다. patch되는 다른 instruction을 SMT sibling이 동시에 실행해도 비슷하게 예측할 수 없는 동작이 발생할 수 있습니다.

이 상황을 없애기 위해 `stop_machine()` 기반 CPU synchronization을 도입했습니다. 모든 logical CPU가 다른 code를 실행하지 않고 atomic variable을 polling하는 spin loop에서 대기하도록 보장합니다.

이 방법은 device interrupt, external interrupt, CMCI 같은 LVT interrupt를 포함한 IPI를 처리하지만 끌 수 없는 special interrupt는 막지 못합니다. 해당 interrupt는 Machine Check(`#MC`), System Management(`#SMI`), Non-Maskable Interrupt(`#NMI`)입니다.

Machine Check, SMI, NMI

Machine Check(`#MC`)는 mask할 수 없습니다. MCE에는 치명적이고 복구 불가능한 유형과 복구 가능한 유형이 있습니다. 복구 불가능한 오류는 치명적이며, kernel context에서도 발생할 수 있는 복구 가능한 오류 역시 kernel은 치명적으로 처리합니다.

일부 Intel machine에서는 MCE가 system의 모든 thread에 broadcast됩니다. 한 thread가 `WRMSR` 실행 중이면 flow 끝에서 MCE를 받습니다. 어느 경우든 `wrmsr(0x79)`를 수행하는 thread가 MCE handler rendezvous에 도착하기를 기다리고, system의 thread 중 하나라도 확인되지 않으면 결국 shutdown합니다.

예측 가능한 보수적 동작을 위해 OS는 `MCG_STATUS.MCIP`를 설정할 수 있습니다. 한 system에는 MCE가 최대 하나만 존재할 수 있으므로 MCE가 signal되면 위 조건은 자동으로 system reset으로 승격됩니다. OS는 해당 core의 update가 끝날 때 MCIP를 끌 수 있습니다.

SMI도 platform의 모든 CPU에 broadcast됩니다. microcode update는 MSR `0x79`에 쓰기 전에 core에 대한 exclusive access를 요청합니다. 한 thread가 `WRMSR` flow에 있고 두 번째 thread가 SMI를 받으면, 그 thread는 SMI handler의 첫 instruction에서 멈춥니다.

secondary thread가 SMI의 첫 instruction에서 멈추므로 patch 중인 instruction을 실행하던 중일 가능성은 매우 낮습니다. 또한 OS가 SMI 발생을 막을 방법은 없습니다.

core의 thread0이 microcode update 중일 때 thread1이 NMI로 끌려 들어가면 앞서 설명한 이유로 예측할 수 없는 동작이 발생할 수 있습니다. OS는 이 상황을 피하기 위해 여러 방법 가운데 하나를 선택할 수 있습니다.

late loading 적합성을 선언할 수 없는 이유

late loading은 system이 완전히 동작하며 실제 workload를 실행 중일 때 수행됩니다. 동작 결과는 새 patch로 upgrade하기 전 CPU의 base patch에 따라 달라집니다. 이 설명은 Intel CPU에 적용됩니다.

예를 들어 CPU의 patch level이 1이고 level 3으로 update한다고 가정합니다. patch1과 patch3 사이의 patch2가 software-visible feature를 deprecated했을 수 있습니다.

software가 그 feature를 사용할 가능성만 있어도 이는 허용할 수 없습니다. 예를 들어 update 뒤 `MSR_X`를 더 이상 사용할 수 없다면 해당 MSR access에서 `#GP` fault가 발생합니다.

결국 새 microcode update가 late loading에 적합하다고 선언할 방법은 없습니다. 이 문제도 late loading이 기본으로 활성화되지 않게 된 이유 중 하나입니다.

builtin microcode

loader는 일반 builtin firmware 방식인 `CONFIG_EXTRA_FIRMWARE`로 제공한 builtin microcode도 load할 수 있습니다. 현재는 64-bit만 지원합니다.

configuration 예시는 다음과 같습니다.

CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

build system이 file을 찾을 수 있도록 local tree를 다음과 같이 구성합니다.

build system은 이 file을 찾아 최종 kernel image에 통합하고 early loader가 이를 찾아 적용합니다.