> cpu0: 256KB 64b/line 8-way L2 cache
> rdmsr to register 0xc80 on vcpu 0
> fatal protection fault in supervisor mode
> trap type 4 code 0 rip ffffffff811c1d17 cs 8 rflags 202 cr2 0 cpl e rsp
> ffffffff81a05940
> panic: trap type 4, code=0, pc=ffffffff811c1d17
That's the problem with virtual cpus in x86. There are rather
stringent requirements -- features which are offered up must be
emulated, if the hardware vm features don't so in hardware.
And noone tested it in that combination of bhyve + real hardware you
have.
Commit from January:
revision 1.80
date: 2017/01/13 17:15:27; author: mikeb; state: Exp; lines: +20 -1;
commitid: xf3Mp5sczmZXop5L;
Disable and lock Silicon Debug feature on modern Intel CPUs
This implements one of the countermeasures against using Direct
Connect Interface (DCI) to debug CPUs via USB3 mentioned in the
"Tapping into the core" talk at the 33c3: identify and disable
the Silicon Debug feature found in Haswell and newer CPUs.
ok mlarkin, deraadt
/*
* Attempt to disable Silicon Debug and lock the configuration
* if it's enabled and unlocked.
*/
if (!strcmp(cpu_vendor, "GenuineIntel") &&
(cpu_ecxfeature & CPUIDECX_SDBG)) {
uint64_t msr;
msr = rdmsr(IA32_DEBUG_INTERFACE);
if ((msr & IA32_DEBUG_INTERFACE_ENABLE) &&
(msr & IA32_DEBUG_INTERFACE_LOCK) == 0) {
msr &= IA32_DEBUG_INTERFACE_MASK;
msr |= IA32_DEBUG_INTERFACE_LOCK;
wrmsr(IA32_DEBUG_INTERFACE, msr);
} else if (msr & IA32_DEBUG_INTERFACE_ENABLE)
printf("%s: cannot disable silicon debug\n",
ci->ci_dev->dv_xname);
}
Let me decipher the condition above: A cpu which claims it is
GenuineIntel, and that it has the SDBG feature.. let's see..
> cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.87 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
(see SDBG in the long line above?)
In that case the emulation of that cpu must support the feature it
claims to support, either by having the hardware do it, or by having
the vm code emulate it. It must emulate the MSR's associated with
the feature.
Or, not make the claim.
bhyve appears to be passing down feature bits from the host cpu
without sanitizing them.
I wonder what other features they are passing down.... some of them
are not really safe........
