# DF-5345 — Unguarded rdmsr() in print_svm_info()/print_vmx_info(): CPUID-advertised VMX/SVM without MSR backing → #GP → boot panic

## Where

`sys/platform/pc64/x86_64/identcpu.c`

```c
1272: static void
1273: print_svm_info(void)
1274: {
1275: 	u_int features, regs[4];
1276: 	uint64_t msr;
1277: 
1278: 	kprintf("\n  SVM: ");
1279: 	do_cpuid(0x8000000A, regs);            /* no cpu_exthigh >= 0x8000000a check */
1280: 	features = regs[3];
1281: 
1282: 	msr = rdmsr(MSR_AMD_VM_CR);             /* UNGUARDED raw rdmsr */
...
1339: print_vmx_info(void)
...
1345: 	msr = rdmsr(MSR_IA32_FEATURE_CONTROL);  /* UNGUARDED */
...
1350: 	basic = rdmsr(MSR_VMX_BASIC);           /* UNGUARDED */
1351: 	pin_ctls = vmx_settable(basic, MSR_VMX_PINBASED_CTLS,   /* rdmsr again */
```

Both printers are gated **only** on CPUID feature bits
(:498 `cpu_feature2 & CPUID2_VMX`, :501 `amd_feature2 & AMDID2_SVM`) — bits
that in a VM are written by the hypervisor and on metal by firmware. A
hypervisor that advertises the bit without implementing the MSRs makes the
kernel execute `rdmsr` on a non-existent MSR in ring 0 → #GP →
boot-time kernel panic. Neither printer is bootverbose-gated
(only print_AMD_info/print_INTEL_info are, :564-569).

The file itself documents this exact failure class and guards one instance
of it properly:

```c
689: 	if (cpu_stdext_feature3 & CPUID_STDEXT3_ARCH_CAP) {
690: 		if (rdmsr_safe(MSR_IA32_ARCH_CAPABILITIES, &cpu_ia32_arch_caps))
...
683: 	 * Some hypervisors fail to implement
684: 	 * MSR_IA32_ARCH_CAPABILITIES, catch any problems.
```

print_svm_info/print_vmx_info/vmx_settable were never given the same
treatment.

## Reproduction attempts (QEMU 7.2.22)

* **KVM, `-cpu qemu64,+svm,check=off`** (Intel host): QEMU clears
  host-unsupported feature bits during KVM CPU realize, so the SVM bit never
  reaches the guest (`boot-kvm-svm-bitstripped.log:37`
  `AMD Features2=0x1<LAHF>`) — the path is not reached this way.
* **TCG, `-cpu qemu64,+svm,check=off`** (`boot-tcg-svm.log`): the bit
  **does** reach the guest (`AMD Features2=0x7<LAHF,CMP,SVM>`, line 37) and
  `print_svm_info()` **runs and executes the raw `rdmsr(MSR_AMD_VM_CR)`**
  (`SVM: Features=0x0` at line 39 — printed *after* the rdmsr at :1282).
  QEMU TCG returns 0 for unimplemented MSRs instead of injecting #GP, so
  the guest survives; the *panic* is therefore not observable on stock
  QEMU — it requires a hypervisor that faults unsupported MSR reads
  (KVM does; VirtualBox-class bugs are the documented motivation for the
  rdmsr_safe guard at :690).

Honest classification: **not_reproduced** on this harness (boot completed,
no panic) with the dangerous path proven reached and the rdmsr proven
executed under a lying CPUID configuration.

## Files

* `boot-tcg-svm.log` — TCG boot: SVM bit exposed, print_svm_info executed
* `boot-kvm-svm-bitstripped.log` — KVM control: bit stripped, path not reached
* `run.sh` — exact QEMU commands
* `env.txt`, `fix.diff`