A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can set VM.platform:device-model to influence QEMU device model selection. A double whitelist limits the impact: XAPI's sanity_check at vm_platform.ml:38 validates the value against known profile names (qemu-upstream-compat, qemu-upstream-uefi, qemu-upstream), and xenopsd's Profile.of_string at xenops_server_xen.ml:70-71 resolves the profile to a hardcoded binary path. Unknown values silently default to Qemu_upstream_compat. The attacker cannot force qemu-trad (legacy QEMU) or an arbitrary binary path. The impact is limited to selecting between three supported QEMU profiles, which differ in device emulation compatibility but not in security posture. The VM.platform field has zero map_keys_roles entries.
VM.platform is a Map(String, String) field defined at datamodel_vm.ml:2717-2720 with zero map_keys_roles entries.
The device-model key passes through two validation layers:
Layer 1 - XAPI sanity_check (vm_platform.ml:38):
The sanity_check function runs at VM start time and checks the device-model value against a list of recognized profiles. Unrecognized values are logged but not rejected - the default profile is used instead.
Layer 2 - xenopsd Profile.of_string (xenops_server_xen.ml:70-71):
Profile.of_string resolves the profile name:
"qemu-upstream-compat" -> Qemu_upstream_compat
"qemu-upstream-uefi" -> Qemu_upstream_uefi
"qemu-upstream" -> Qemu_upstream
_ -> Qemu_upstream_compat (default)
The QEMU binary path is hardcoded based on the profile. There is no path from the device-model key to an arbitrary binary execution.
The three supported profiles differ in PCI device emulation behavior (IDE vs AHCI, i440FX vs Q35 chipset) but share the same QEMU binary and security features. Switching between them changes guest device compatibility, not security posture.
Missing RBAC protection. VM.platform has zero map_keys_roles entries in datamodel_vm.ml. The device-model key is writable by vm-admin.
Write-time vs. start-time validation gap. XAPI accepts any device-model value at write time. Validation occurs only at VM start, where unrecognized values silently default to the compatible profile.
set_platform RBAC bypass. The set_platform method replaces the entire map and bypasses map_keys_roles per-key checks.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Profile switch | Guest sees different PCI device topology, possible driver issues | vm-admin, HVM VM | Source-traced |
| Invalid value injection | Silent fallback to Qemu_upstream_compat, no operational impact | vm-admin | Source-traced |
| BOC-1 chain | vm-admin changes device model across all VMs via RBAC collapse | vm-admin, BOC-1 | Source-traced |
VM.platform for changes to the device-model keyqemu-upstream-compat, qemu-upstream-uefi, qemu-upstream)disclosure/vendor-detection-guidance.mdVM.platform entries for unexpected device-model valuesAdd write-time validation. Reject device-model values not in the recognized set at write time, not just at start time.
Add map_keys_roles protection. Restrict the device-model key to _R_POOL_ADMIN in datamodel_vm.ml. QEMU variant selection is an infrastructure-level decision.
Replace with typed field. The device-model key has exactly three valid values. It should be an enumeration field.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
datamodel_vm.ml:2717-2720 (VM.platform field definition), vm_platform.ml:38 (sanity_check - device-model profile validation), xenops_server_xen.ml:70-71 (Profile.of_string - hardcoded binary resolution)disclosure/advisories/plat-security-advisory.md (PLAT-3)research/investigations/vm-platform.mdDiscovered and reported by Jakob Wolffhechel, Moksha.