On Tue, Apr 04, 2017 at 09:07:08PM -0600, Theo de Raadt wrote:
> > 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,CFLUS
H,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,PA
GE1GB,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........
>
HardenedBSD fixed this a few months ago. Peter Grehan will pull in
HardenedBSD's fix soon.
For reference:
https://github.com/HardenedBSD/hardenedBSD/commit/cc91b57f4d1dabddfbf8b1e7655
bc19908f24f78
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
