tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: amd64: svs

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 1


 Only 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
@@ -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 1


 Only 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 0


and with my local debug pritntf():

cpu0: MSR_IA32_ARCH_CAPABILITIES=0x1

I'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)
Home | Main Index | Thread Index | Old Index