A user with the vm-admin role can change the storage I/O backend driver for any VBD by writing to VBD.other_config:backend-kind. This key selects which storage driver handles the VBD's I/O path - kernel blkback or userspace tapdisk. An attacker can force a VBD to use kernel blkback instead of tapdisk (or vice versa), changing the I/O path, feature negotiation, and capabilities for that virtual disk. This bypasses tapdisk-level access controls, monitoring, and security features, and can destabilize the storage I/O path.
The backend-kind key in VBD.other_config controls which storage backend driver handles I/O for a virtual block device. The key is read at xapi_xenops.ml:662 and passed to xenopsd as part of extra_backend_keys, which is then written to xenstore for the backend driver to consume.
VBD.other_config["backend-kind"]
-> xapi_xenops.ml:662 (of_vbd function)
-> extra_backend_keys map
-> xenstore: /local/domain/0/backend/vbd/<domid>/<devid>/sm-data/backend-kind
-> blkback/tapdisk reads the key and selects I/O path
The backend-kind key is defined as a constant in xapi_globs.ml:237 (vbd_backend_key = "backend-kind"). During VBD creation, xapi_vbd.ml:282-288 auto-populates this key from VDI.sm_config. However, any vm-admin can overwrite it afterward via VBD.add_to_other_config.
The storage subsystem uses backend-kind to determine the I/O driver:
vbd = kernel blkback (direct block device passthrough)vbd3 = tapdisk (userspace I/O with VHD processing, coalesce support, caching)Forcing kernel blkback (vbd) on a VHD-backed VDI bypasses all tapdisk processing:
Missing per-key RBAC. VBD.other_config has zero map_keys_roles entries. The backend-kind key is writable by vm-admin without restriction.
No validation on backend-kind values. The key accepts arbitrary strings. Invalid values cause undefined behavior in the backend selection logic.
Infrastructure key in user-writable field. The storage backend driver type is an infrastructure-level decision that should not be modifiable by delegated administrators.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Tapdisk bypass | Force kernel blkback on VHD VDI; bypass tapdisk access controls and monitoring | Target VBD exists on a VHD-backed SR | PoC ready (boc-1-v2-backend-kind.sh) |
| Coalesce disruption | Switch backend mid-operation; GC cannot signal tapdisk for VHD chain operations | Active GC cycle on target VDI | Modeled (source trace) |
| Feature negotiation manipulation | Change guest-visible block device capabilities by switching backend type | Guest running with specific I/O assumptions | Modeled (source trace) |
VBD.other_config:backend-kind writes by non-pool-admin sessionsbackend-kind values that differ from the expected type for the VDI's SR type/local/domain/0/backend/vbd/*/sm-data/backend-kind for unexpected valuesVBD.other_config entries for unexpected backend-kind valuesbackend-kind against expected values from VDI.sm_config on each SR typevm-admin role grants to trusted personnelRBAC: Add map_keys_roles entry for backend-kind requiring _R_POOL_ADMIN in datamodel.ml.
Validation: Validate backend-kind values at write time against a whitelist of known backend types (vbd, vbd3). Reject unknown values.
Immutability: Consider making backend-kind immutable after VBD creation, matching the auto-populated value from VDI.sm_config.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_xenops.ml:662 (backend-kind read in of_vbd), xapi_globs.ml:237 (vbd_backend_key constant), xapi_vbd.ml:282-288 (auto-population from VDI.sm_config)disclosure/advisories/boc-1-security-advisory.md (V2)research/investigations/vbd-other-config.mdresearch/boc-1/poc/boc-1-v2-backend-kind.sh (available to CSIRTs on request)Discovered and reported by Jakob Wolffhechel, Moksha.