Re: [Bug 251046] bhyve PCI passthrough does not work inside jail

From: Ernie Luzar <>
Date: Wed, 25 Aug 2021 13:50:04 UTC wrote:
> --- Comment #15 from Anatoli <> ---
> Mark, All,
>> --- Comment #3 from Mark Johnston <> ---
>> PRIV_IO access is not required only by /dev/io, it is also required for
>> sysarch(I386_SET_IOPERM), which is otherwise available to jailed processes. So
>> the patch definitely should not be committed.  A better solution would be to
>> extend pci(4) so that bhyve can use it to do everything required for PCI
>> passthrough.  Even then I'm not sure why it's useful to jail the bhyve process
>> - what does it buy you?
> In light of the recently patched VM-escape vulnerability in bhyve
> (FreeBSD-SA-21:13.bhyve fixing the CVE-2021-29631), I'd like to highlight the
> benefits of running bhyve under a non-root user and inside a jail by default.
> If it were the case, this vulnerability, instead of a complete host takeover
> would just have a DoS impact on the malicious VM, which is perfectly fine IMO.
> That's why it's extremely important to make bhyve work correctly under all
> situations (including PPT) inside jail so we could make it run inside jail by
> default.
>> --- Comment #8 from Mark Johnston <> ---
>> I am very skeptical that jailing bhyve with PCI passthrough enabled provides
>> any meaningful security.  /dev/pci allows a jailed root to access all PCI(e)
>> devices in the system. Jails can be a useful deployment mechanism though, so I
>> think we should better support their integration with bhyve.
> With respect to this, isn't it possible to restrict the bhyve process (maybe
> self-restricting via Capsicum) to just the masked PCI addresses or to the PCI
> addresses specified via the args so to limit the impact of a bhyve compromise
> to
> just the intended device(s)?
> Or, as you already proposed, to extend pci(4) so that bhyve can use it to do
> everything required for PPT?
> Regards,
> Anatoli

jail is not a vm.