On 2018/01/15 17:34, Masanobu SAITOH wrote:
On 2018/01/15 3:42, Dave Huang wrote:On Jan 13, 2018, at 22:20, Emmanuel Dreyfus <manu%netbsd.org@localhost <mailto:manu%netbsd.org@localhost>> wrote:John Klos <john%ziaspace.com@localhost <mailto:john%ziaspace.com@localhost>> wrote:FWIW, Intel updated their microcode on 8-Jan-2018: https://downloadcenter.intel.com/download/27431/ I can't find any documentation which shows what exactly is fixed for each family of processors.It does not seems to fix much. I tried the tests from git repository http://github.com/IAIK/meltdown.git This is Linux-centric, but at least, the "secret" case seems to apply on NetBSD. It reports vulnerability before (cpu0: microcode version 0x58, platform ID 1) and after (cpu0: microcode version 0x80, platform ID 1) microcode upgrade. And I do not have a spectre test case. Anyone has that?My understanding is that the microcode update doesn't actually *fix* anything by itself. What it does is enable an OS to more easily fix things. The kernel would need to check for the new SPEC_CTRL CPUID bit, and if present, twiddle with the new speculation control-related MSRs at the appropriate times. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: khym%azeotrope.org@localhost <mailto:khym%azeotrope.org@localhost> | they raise a paw / the bat, the cat / Telegram: @DahanC | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++FYI: Diffs of "cpuctl -v identify 0" before microcode update and after on some my machines. Haswell:% diff -up o1.log o2.log --- o1.log 2018-01-11 18:11:36.897983031 +0900 +++ o2.log 2018-01-11 18:11:44.782255154 +0900 @@ -6,7 +6,7 @@ cpu0: 00000003: 00000000 00000000 000000 cpu0: 00000004: 1c004121 01c0003f 0000003f 00000000 cpu0: 00000005: 00000040 00000040 00000003 00042120 cpu0: 00000006: 00000077 00000002 00000009 00000000 -cpu0: 00000007: 00000000 00002fbb 00000000 00000000 +cpu0: 00000007: 00000000 000027ab 00000000 0c000000 cpu0: 00000008: 00000000 00000000 00000000 00000000 cpu0: 00000009: 00000000 00000000 00000000 00000000 cpu0: 0000000a: 07300403 00000000 00000000 00000603 @@ -35,8 +35,9 @@ cpu0: features1 0x7ffafbff<X2APIC,MOVBE, cpu0: features1 0x7ffafbff<F16C,RDRAND> cpu0: features2 0x2c100800<SYSCALL/SYSRET,XD,P1GB,RDTSCP,EM64T> cpu0: features3 0x21<LAHF,LZCNT> -cpu0: features5 0x2fbb<FSGSBASE,TSCADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID> -cpu0: features5 0x2fbb<RTM,FPUCSDS> +cpu0: features5 0x27ab<FSGSBASE,TSCADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID> +cpu0: features5 0x27ab<FPUCSDS> +cpu0: SEF edx 0xc000000<IBRS,STIBP> cpu0: xsave features 0x7<x87,SSE,AVX> cpu0: xsave instructions 0x1<XSAVEOPT> cpu0: xsave area size: current 832, maximum 832, xgetbv enabled @@ -55,4 +56,4 @@ cpu0: SMT ID 0 cpu0: DSPM-eax 0x77<DTS,IDA,ARAT,PLN,ECMD,PTM> cpu0: DSPM-ecx 0x9<HWF,EPB> cpu0: SEF highest subleaf 00000000 -cpu0: microcode version 0x17, platform ID 1 +cpu0: microcode version 0x23, platform ID 1Only IBRS and STIBP. No IA32_ARCH_CAPABILITIES. Kaby Lake (XXX on xen dom0):% diff -u xen-0.log xen-1.log --- xen-0.log 2018-01-15 15:39:37.350775248 +0900 +++ xen-1.log 2018-01-15 15:39:46.135931681 +0900 @@ -6,7 +6,7 @@ cpu0: 00000004: 1c004121 01c0003f 0000003f 00000000 cpu0: 00000005: 00000040 00000040 00000003 00142120 cpu0: 00000006: 000027f7 00000002 00000009 00000000 -cpu0: 00000007: 00000000 029c6fbf 00000000 00000000 +cpu0: 00000007: 00000000 029c6fbf 00000000 0c000000 cpu0: 00000008: 00000000 00000000 00000000 00000000 cpu0: 00000009: 00000000 00000000 00000000 00000000 cpu0: 0000000a: 07300804 00000000 00000000 00000603
oops, the test binary was old.
@ -47,6 +47,7 @@ cpu0: features5 0x29c6fbf<FSGSBASE,TSCADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS> cpu0: features5 0x29c6fbf<INVPCID,RTM,FPUCSDS,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT> cpu0: features5 0x29c6fbf<PT> +cpu0: SEF edx 0xc000000<IBRS,STIBP> cpu0: xsave features 0x1f<x87,SSE,AVX,BNDREGS,BNDCSR> cpu0: xsave instructions 0xf<XSAVEOPT,XSAVEC,XGETBV,XSAVES> cpu0: xsave area size: current 576, maximum 1088, xgetbv enabled
@@ -67,4 +67,4 @@ cpu0: DSPM-eax 0x27f7<HWP_EPP,HDC> cpu0: DSPM-ecx 0x9<HWF,EPB> cpu0: SEF highest subleaf 00000000 -cpu0: microcode version 0x48, platform ID 1 +cpu0: microcode version 0x80, platform ID 1Only IBRS and STIBP. No IA32_ARCH_CAPABILITIES. Denverton:% diff -u dnv-0.log dnv-1.log --- dnv-0.log 2018-01-15 17:25:58.655815447 +0900 +++ dnv-1.log 2018-01-15 17:26:12.429468878 +0900 @@ -6,7 +6,7 @@ cpu0: 00000004: 3c000121 0140003f 0000003f 00000001 cpu0: 00000005: 00000040 00000040 00000003 00002020 cpu0: 00000006: 00000055 00000002 00000009 00000000 -cpu0: 00000007: 00000000 2294e283 00000000 00000000 +cpu0: 00000007: 00000000 2294e283 00000000 2c000000 cpu0: 00000008: 00000000 00000000 00000000 00000000 cpu0: 00000009: 00000000 00000000 00000000 00000000 cpu0: 0000000a: 07300404 00000000 00000000 00000603 @@ -44,6 +44,7 @@ cpu0: features3 0x101<LAHF,PREFETCHW> cpu0: features5 0x2294e283<FSGSBASE,TSCADJUST,SMEP,ERMS,FPUCSDS,MPX,PQE,RDSEED> cpu0: features5 0x2294e283<SMAP,CLFLUSHOPT,PT,SHA> +cpu0: SEF edx 0x2c000000<IBRS,STIBP,ARCH_CAP> cpu0: xsave features 0x1b<x87,SSE,BNDREGS,BNDCSR> cpu0: xsave instructions 0xf<XSAVEOPT,XSAVEC,XGETBV,XSAVES> cpu0: xsave area size: current 576, maximum 1088, xgetbv enabled @@ -59,4 +60,4 @@ cpu0: DSPM-eax 0x55<DTS,ARAT,PLN,PTM> cpu0: DSPM-ecx 0x9<HWF,EPB> cpu0: SEF highest subleaf 00000000 -cpu0: microcode version 0x16, platform ID 0 +cpu0: microcode version 0x20, platform ID 0and with my local debug pritntf():cpu0: MSR_IA32_ARCH_CAPABILITIES=0x1I've not written this bit by myself. The bit 0 is RDCL_NO. 336996-Speculative-Execution-Side-Channel-Mitigations.pdf says the processor is not susceptible to Rogue Data Cache Load if this bit is set. So just updating microcode on some newer CPUs can mitigate Rogue Data Cache Load, right?
--
-----------------------------------------------
SAITOH Masanobu (msaitoh%execsw.org@localhost
msaitoh%netbsd.org@localhost)