[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.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273557

--- Comment #6 from crest@rlwinm.de ---
(In reply to Bjoern A. Zeeb from comment #4)
The untested patch would still attempt to create a socket (which can fail),
closing the socket could be factored out (keep only the last close(s), but put
a label before and after it). It will allow bhyve to start, but bhyve will fail
to bring up the tap/vmnet interface on its own if it can't create an IP socket
(either IPv4 or IPv6). For example if bhyve is started inside very restrictive
jail with ip=disabled and ip6=disabled. In this case bhyve will start but the
tap/vmnet device will stay in its default link state forcing users to either
set sysctl net.link.tap.up_on_open=1 to change the default link state for all
tap/vmnet interface from DOWN to UP or have a wrapper poll the tap/vmnet device
aggressive enough until bhyve has opened it to bring the link state up before
the guest notices it. This is complicated by the fact that bhyve(8) exists if
the guest requests a reboot. While I've always run my bhyve hosts with
net.link.tap.up_on_open=1 bhyve users shouldn't be forced to do change their
global system configuration. The corner case I ran into is clearly a bug that
should be fixed. I see no advantage to addressing only one half of the bug by
still using an IP socket, but continuing if the socket creation or ioctl()s
fail.

Processes running inside a jail with both IPv4 and IPv6 disabled can't be
create new IP sockets of either IP version. The only way for bhyve to bring up
the tap/vmnet device from inside such a jail is to use the
ioctl(VMIO_SIOCSIFFLAGS) on the tap/vmnet device. It's also the only place in
bhyve that I found with a quick `grep -r` which creates IP sockets. From my
understanding ioctl(VMIO_SIOCSIFFLAGS) covers all cases (inside a jail and
outside), avoids creating and destroying a socket, saves a few syscalls,
removes a (theoretical) race condition, removes failure cases that have to be
handled (even if only to report and ignore them).

Am I overlooking a downside to using ioctl(VMIO_SIOCSIFFLAGS) on the tap/vmnet
device and getting rid of the IP socket and the variables holding the socket
file descriptor number and struct passed to ioctl()s on the socket?

-- 
You are receiving this mail because:
You are the assignee for the bug.