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

Mark, All,

On 23/11/20 13:11, bugzilla-noreply@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251046
> 
> Mark Johnston <markj@FreeBSD.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |markj@FreeBSD.org
>              Status|New                         |Open
> 
> --- Comment #3 from Mark Johnston <markj@FreeBSD.org> ---
> 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.


> 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