Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Aug 2021 00:05:27 +0000
From:      bugzilla-noreply@freebsd.org
To:        jail@FreeBSD.org
Subject:   [Bug 251046] bhyve PCI passthrough does not work inside jail
Message-ID:  <bug-251046-29815-3pgqnYxqPI@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-251046-29815@https.bugs.freebsd.org/bugzilla/>
References:  <bug-251046-29815@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251046

--- Comment #15 from Anatoli <me@anatoli.ws> ---
Mark, All,

> --- 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 processe=
s. 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 pr=
ocess
> - 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 t=
he
benefits of running bhyve under a non-root user and inside a jail by defaul=
t.

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 I=
MO.

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 <markj@FreeBSD.org> ---
> I am very skeptical that jailing bhyve with PCI passthrough enabled provi=
des
> 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 P=
CI
addresses specified via the args so to limit the impact of a bhyve compromi=
se
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

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251046-29815-3pgqnYxqPI>