https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251046
--- Comment #15 from Anatoli <m...@anatoli.ws> --- Mark, All, > --- Comment #3 from Mark Johnston <ma...@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. > --- Comment #8 from Mark Johnston <ma...@freebsd.org> --- > 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 -- You are receiving this mail because: You are on the CC list for the bug.
