[Bug 273557] Regression preventing bhyve from running inside a jail without IP after f74147e26999838e03a522bf59ea33bef470d356) breaks support for jailing bhyve with IPv4 and IPv6 disabled. Patch included.
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 273557] Regression preventing bhyve from running inside a jail without IP after f74147e26999838e03a522bf59ea33bef470d356) breaks support for jailing bhyve with IPv4 and IPv6 disabled. Patch included."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 08 Sep 2023 08:43:13 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273557 --- Comment #8 from crest@rlwinm.de --- I create the tap interface on the jail host and apply a jail specific devfs ruleset to it allowing only access to those devices bhyve needs e.g. vmm/$name vmm.io/$name.bootrom, tap$n and symlink tap-$name pointing to the renamed tap interface, nmdm devices matching certain patterns, one CTL port for virtio-scsi etc. The bhyve tap device is a member of a bridge on the jail host. The jail isn't vnet enabled because it doesn't require IP sockets at all except for the current code to set the tap interface state to UP. Bhyve doesn't need sockets to read/write Ethernet frames on tap devices. Having an extra vnet would require the jail to also contain an extra bridge with exactly two members (one half of an epair and the tap). The other half of the epair would take the place of the tap device on the host bridge. Such a configuration would be **noticeable** slower, harder to configure, and provide a larger attack surface. -- You are receiving this mail because: You are the assignee for the bug.