Page MenuHomeFreeBSD

vmm: Rework mapping of PCI passthrough bars into guests.
Needs ReviewPublic

Authored by jhb on Aug 11 2022, 11:32 PM.

Details

Reviewers
emaste
markj
grehan
Group Reviewers
bhyve
Summary

The existing VM_MAP_PPTDEV_MMIO ioctl permitted the userland
hypervisor to specify the host physical address of a BAR trusting the
hypervisor to only pass valid host physical addresses. Rather than
trusting the host physical address provided by userland, introduce a
new ioctl which accepts a BAR register and relative offset in place of
the host physical address. This ensures that only host physical
addresses belonging to a BAR of a passthrough device can be mapped
into the guest address space.

Sponsored by: The FreeBSD Foundation

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 46869
Build 43758: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Aug 11 2022, 11:32 PM
sys/amd64/vmm/io/ppt.c
455

I think this is a reasonable #ifdef to use for now, but we likely want to be more aggressive in removing this than waiting until COMPAT_FREEBSD13 naturally ages out. Or maybe we could add a sysctl to allow/disallow the old insecure ioctl. I'd be happy for that to be a followup (either by you or me).

sys/amd64/vmm/io/ppt.c
357

Will this conflict with bhyve's use of the PCIOCBARIO ioctl for mapping the MSI-X table and PBA? See the discussion about the use of RF_SHAREABLE in D31307.

sys/amd64/vmm/io/ppt.c
357

Hmm, yes it will.

Perhaps it would be best if we did something that I think I suggested against before which is to add new vmm ioctls for bhyve to use for that in place of the generic PCI ioctls. That would ensure that bhyve can only read/write BARs of ppt(4) devices and not BARs of arbitrary devices.