Nic na tom není, jen to zakompiluješ do jádra a necháš pracovat early update driver. Necháš si najít bundle:
# iucode_tool -S -l /lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000806e9
[...]
microcode bundle 068: /lib/firmware/intel-ucode/06-8e-09
microcode bundle 069: /lib/firmware/intel-ucode/06-8e-0a
[...]
selected microcodes:
068/001: sig 0x000806e9, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304
069/001: sig 0x000806ea, pf_mask 0xc0, 2018-01-04, rev 0x0080, size 98304
Pod selected microcodes ti vypíše kompatibilní, tak si jejich cesty v předešlém seznamu vyhledáš podle čísel (68, 69) a dáš do jádra:
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="intel-ucode/06-8e-09 intel-ucode/06-8e-0a"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
Rebuild, reboot... a pak by to měla být první věc, co jádro udělá:
# dmesg | head -n 1
[ 0.000000] microcode: microcode updated early to revision 0x80, date = <b>2018-01-04</b>
Nevím jistě, ale podle mě tohle není linking, takže to neovlivní GPL status jádra, tj. takové jádro lze dál distribuovat.
Bud jak psal kolega, nebo muzes pouzit i ten iucode-tool (ale obecne je lepsi ten early update pri startu jadra, nicmene pokud uz mas aktualizovany kernel a nechce se ti rebootovat tak je tohle reseni, RH patche automaticky i po pozdejsim updatu zjisti, ze je k dispozici IBRS ):
./iucode-tool -k -S microcode.dat
Vcera jsem to instaloval na nekolik stroju s Centos 7 / RHEL bezproblemu.
Většina distribucí umí "magii", že stačí nainstalovat balíček intel-ucode, který se postará o přidání parametrů do loaderu.
Případně lze přidat nahrávání microcode ručně jako parametr přímo kernelu (stejně jako se předává initramfs) a on se postará o zavedení do procesoru.
initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img
V dmesg se pak objeví hned na začátku:
[ 0.000000] microcode: microcode updated early to revision 0x7, date = 2013-08-20
...jo jo, mám Core i5 co dávno patří do šrotu, takže na něj aktuální mikrokód není.
Ten seznam ma mensi vypovidajici hodnotu nez predvolebni program.
V tom seznamu jsou vsechny procesory, pro ktere obsahuje balik aktualizaci microkodu - coz znamena vsechny procesory, pro ktere nekdy byla aktualizace mikrokodu vydana.
Takze treba na muj staricky Celeron obsahuje mikrokod z roku 2013, samozrejme ale Spectre neresi.
iucode-tool -k -S microcode.dat
iucode-tool: cpuid kernel driver unavailable, cannot scan system processor signatures
iucode-tool: Uploading selected microcodes to: /dev/cpu/microcode
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> STATUS: VULNERABLE (heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
Vybere vsechny.
Proc neexistuje /dev/cpu/x/cpuid.
CPU je Intel Xeon Processor E5-2690 v4
Jedna se o debian old stable (8) - Linux diamond 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
iucode-tool -lSvvv microcode.dat
iucode-tool: /dev/cpu/0/cpuid: returned error status on open(): No such file or directory
iucode-tool: cpuid kernel driver unavailable, cannot scan system processor signatures
iucode-tool: microcode bundle 1: microcode.dat (1613824 bytes)
iucode-tool: processed 164 valid microcode(s), 164 signature(s), 164 unique signature(s)
selected microcodes:
...
...
iucode-tool: selected 164 microcode(s), 164 signature(s)
Timto se chci Intelu omluvit jen tak jsem koukl na seznam v sekci ke stazeni(odkaz v clanku) na strankach intelu. Uvidel jsem svuj (i5-2540M), ale moc jsem nejasal, kdo si tu psal ze tam jsou i procesory bez opravy. Nedalo mi to kliknul jsem na nej a u "Microcode data file" datum posledni aktualizace 1.8.2018. Tak jsem to stahl updatenul a v clanku uvadeny nastrol po rebootu napsal ze mam ochranu aspon pro Meltdown(spectre zatim nic :/).
Myslim, ze se nemas Intelu za co omlouvat :-)
Meltdown: Resi se pomoci KPTI, zadna aktualizace mikrokodu neni potreba, staci jen oprava v jadre (stejne tak napr. ve Windows)
Spectre: Existuje nekolik variant tohoto utoku, da se resit bud pomoci retpoline upravou v kodu (pozor, nejen jadra, ale i celeho userspace). Problemem retpoline je, ze i tak vyzaduje na Broadwellu a vys upravu mikrokodu, protoze prediktor je zde proste prilis chytry na to, aby se tim dal zblbnout :-)
HW obrana spocita v technikach IBRS a IBPB. A zde je nutny novy mikrokod, ktery pridava prislusne bity do CPU, ktere umoznuji tyto features zapnout.
TL;DR: Obrana proti meltdown je snadna, staci aktualizovat jadro, obrana proti Spectre je slozita, vetsinou to znamena pockat na slitovani Intelu az vyda mikrokod :)
Pro ArchLinux to vypadá, že intel-ucode v Testing už také obsahuje opravu: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/intel-ucode&id=3dcc5ec72be2e090b49804ae5013f7b33af7b424
podla releasenote microcode-20180108 (overenene cez diff microcode-20171117.tgz vs microcode-20180108.tgz:) je zmenenych 19 z 94 mikrokodov:
2013 haswell
HSW Cx/Dx (06-3c-03:32) 22->23
HSW-ULT Cx/Dx (06-45-01:72) 20->21
HSX C0 (06-3f-02:6f) 3a->3b
HSX-EX E0 (06-3f-04:80) 0f->10
2014 broadwell
BDW-H E/G (06-47-01:22) 17->1b
BDW-U/Y E/F (06-3d-04:c0) 25->28
BDX-DE V0/V1 (06-56-02:10) 0f->14
BDX-DE V2 (06-56-03:10) 700000d->7000011
2015 skylake
SKL-H/S R0 (06-5e-03:36) ba->c2
SKL-U/Y D0 (06-4e-03:c0) ba->c2
SKX H0 (06-55-04:b7) 2000035->200003c
2016 kaby lake
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0 (06-9e-09:2a) 5e->80
KBL-U/Y H0 (06-8e-09:c0) 62->80
2017 coffee lake
CFL B0 (06-9e-0b:02) 72->80
CFL U0 (06-9e-0a:22) 70->80
???
Crystalwell Cx (06-46-01:32) 17->18
GLK B0 (06-7a-01:01) 1e->22
IVT C0 (06-3e-04:ed) 428->42a
format:
microarchitecture version (family-model-stepping) old->new
Meltdown:
Upgradol som CentOS-7.4 beziaci na Xenon X5650 (Nehalem/Westmere EP, 06-1A-04 z roku 2010), zdvihlo sa jadro z 3.10.0-693.2.2.el7.x86_64 na 3.10.0-693.11.6.el7.x86_64, microcode_ctl je teraz vo verzii 2.1-22.2.el7.x86_64 a mikrokod CPU sa zdvihol z 0x15 na 0x16 a meltdown test pise NOT VULNERABLE (pred upgradom a rebootom meltdown test pisal VULNERABLE). Spomalenie pre git svn clone task je cca 16% (resp. 125 vs 146 sekund).