lima-vm / vde_vmnet Goto Github PK

lima-vm/lima#119

Or at least it didn't work for me.

I believe it is due to being installed as a symlink owned by my user instead of by root:

# ls -l vde_switch
lrwxr-xr-x  1 jan  admin  36 14 May 16:00 vde_switch -> ../Cellar/vde/2.3.2_1/bin/vde_switch

launchd refuses to load it:

(io.github.virtualsquare.vde-2.vde_switch.plist[5719]): Could not find and/or execute program specified by service: 13: Permission denied: /usr/local/bin/vde_switch

It started working after I replaced the symlink with the file itself:

# ls -l vde_switch
-r-xr-xr-x  1 root  staff  94904 29 Jul 10:48 vde_switch

Could probably have just changed the owner of the symlink itself, but didn't test it yet.

The tarball should include both vde_switch and vde_vmnet binaries with an /opt/vde prefix compiled in.

Allowing password-less execution of /usr/local/bin/vde_vmnet as root is a vulnerability when the user has non-sudo write access to /usr/local/bin (which is typically the case when using homebrew), because they could simply replace vde_vmnet with any other command or script and then execute that under root.

This can be mitigated by including a checksum of the executable in the sudo rule, e.g.

$ sha256sum /usr/local/bin/vde_vmnet
cabb4c8bac4a2923a1feb21f597ae6c8145de25e44f408b75ec254da6ffa09ce  /usr/local/bin/vde_vmnet

should lead to a rule such as (untested):

%staff ALL=(root:root) NOPASSWD:NOSETENV: sha256:cabb4c8bac4a2923a1feb21f597ae6c8145de25e44f408b75ec254da6ffa09ce /usr/local/bin/vde_vmnet --vmnet-gateway=192.168.105.1 /var/run/vde.ctl

This issue was automatically created by Allstar.

Security Policy Violation
PR Approvals not configured for branch master

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

while the vde_vmnet daemon is running as root?

I noticed that on my system the only other process running as the daemon user is rpcbind.

Currently the instructions show using QEMU with -device virtio-net-pci. I'm thinking about using this project for embedded development based on the Zephyr RTOS which already has a QEMU integration. Depending on the target device, different drivers are used by Zephyr, such as e1000. Is there a specific dependency on this configuration of virtio? Apologies if that's a naive question, I'm rather new to QEMU networking.

Homebrew casks are just wrappers around regular macOS installers (typically *.dmg or *.pkg), that can install anywhere, and that can require sudo during installation.

We need an installer that can take the tarball created by #22 and install it into /opt/vde.

Let's find out if we can use an installer script with just a tarball instead of a full-blown DMG or PKG installer.

We should probably also create our own tap to host the cask, at least initially.

When trying to start vde_vmnet while "Internet Sharing" is active in "System Settings > Sharing > Internet Sharing", vde_vmnet fails to start:

$ sudo /opt/vde/bin/vde_vmnet --vmnet-gateway=192.168.122.1 /tmp/vde.ctl          
Initializing vmnet.framework (mode 1001)
start(): vmnet_return_t 1009
start: Undefined error: 0

It works after disabling Internet Sharing.

Perhaps at least document this issue in the README.

I setup networking for lima/colima a few weeks ago and it had been working fine, but today, even after some troubleshooting, I can not ping the colima VM from my host. I have updated lima, colima, and macOS with patch releases lately, so that might be related, but I am not really sure what to check at this point.

On the mac I can see this:

bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
	options=3<RXCSUM,TXCSUM>
	ether 16:7d:da:6a:3e:64
	inet 192.168.105.1 netmask 0xffffff00 broadcast 192.168.105.255
	inet6 fe80::147d:daff:fe6a:3e64%bridge100 prefixlen 64 scopeid 0x14
	inet6 fdce:1812:ad25:915f:834:c0bf:f47f:b16e prefixlen 64 autoconf secured
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x0
	member: vmenet0 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 19 priority 0 path cost 0
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: **active**

but I can not ping 192.168.105.1

One the colima VM, I can see this:

lima0     Link encap:Ethernet  HWaddr 52:55:55:74:18:4D
          inet addr:192.168.105.2  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fdce:1812:ad25:915f:5055:55ff:fe74:184d/64 Scope:Global
          inet6 addr: fe80::5055:55ff:fe74:184d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:42873 (41.8 KiB)  TX bytes:1720 (1.6 KiB)

and I can ping both 192.168.105.2 and 192.168.105.1

I'm not sure exactly what the next step would be in figuring out what bit is likely broken.

Pointers would be much appreciated.

https://manpages.debian.org/bullseye/qemu-system-x86/qemu-system-i386.1.en.html

-netdev socket,id=id[,fd=h][,listen=[host]:port][,connect=host:port]

It looks like we can create an equivalent of vde_vmnet without depending on VDE.
Passing the FD is not easy with the qemu CLI, but easy for Lima.

VMware Fusion 12.1.2 on macOS 11.5.1 cannot use vmnet when vde_vmnet is running

vmware.log:

2021-07-29T15:58:30.456+09:00| vmx| I005: VNET: MACVNetMacosGetRealAdapterType: network type for adapter 0: 8
2021-07-29T15:58:30.456+09:00| vmx| I005: VNET: MACVNetMacosGetVnetProperties: vnet properties: vnet=vmnet8, nat=yes, dhcp=yes (ignored), subnet=192.168.60.0, mask=255.255.255.0, firstAddr=192.168.60.1, lastAddr=192.168.60.127, isIPv6=no, IPv6Prefix=fd15:4ba5:5a2b:1008::, IPv6PrefixLen=64
2021-07-29T15:58:30.456+09:00| vmx| I005: VNET: MACVNetPortVirtApiStartInterface: Waiting on semaphore for adapter: 0
2021-07-29T15:58:30.505+09:00| host-28146| I005: VNET: MACVNetPortVirtApiStartHandler: starting interface for adapter: 0, status: 1001
2021-07-29T15:58:30.505+09:00| host-28146| W003: VNET: MACVNetPortVirtApiStartHandler: unable to create virtual intrface for device: 0, status: 1001
2021-07-29T15:58:30.505+09:00| vmx| I005: VNET: Semaphore signalled for adapter: 0, timeoutMs=5000, waitMs=49
2021-07-29T15:58:30.505+09:00| vmx| W003: VNET: MACVNetPortVirtApiStartInterface: Failed to create interface for adapter: 0, handlerStatus: 1001
2021-07-29T15:58:30.509+09:00| vmx| I005: VNET: MACVNetPort_Connect: Ethernet0: can't start virtual interface
2021-07-29T15:58:30.511+09:00| vmx| I005: Msg_Post: Error
2021-07-29T15:58:30.511+09:00| vmx| I005: [msg.vnet.connectvnet] Could not connect 'Ethernet0' to virtual network '/dev/vmnet8'. More information can be found in the vmware.log file.
2021-07-29T15:58:30.511+09:00| vmx| I005: [msg.device.badconnect] Failed to connect virtual device 'Ethernet0'.
2021-07-29T15:58:30.511+09:00| vmx| I005: ----------------------------------------

Hi,

I just compiled vde-2 and vde_vmnet as described in your readme. But though

vde.bridged.en0.stderr
vde.bridged.en0.stdout
vde.stderr
vde.stdout
vde_vmnet.bridged.en0.stderr
vde_vmnet.bridged.en0.stdout
vde_vmnet.stderr
vde_vmnet.stdout

are in /var/run/, vde.ctl and vde.bridged.en0.ctl are missing.

Do you have any suggestions as to how this can be solved?

Firstly, kudos to this project, it has saved me hours of fiddling with networking myself. I couldn't get the tap and bridge stuff working using older guides and found this when Limactl hit the top of HN.

This isn't a complaint more a expectations check.

I've a 400mbit internet connection and generally see downloads of 10+MB/s. I followed the guide to get networking on qemu on MacOSX working and buil the tool using the latest master branch (current top commit 14e1c9e06f4dbdddc6fe4e85fc72a1d583b049ad) and am seeing downloads of this:

72.2 kB/s 19min 46s while doing an apt-get of various libraries.

So the question is, is there anything that can be done to speed this up? or is this expected behaivor?

Below is the qemu script I use to start my VM:

qemu-system-x86_64 \
  -m 8G \
  -vga virtio \
  -display default,show-cursor=on \
  -usb \
  -device usb-tablet \
  -machine type=q35,accel=hvf \
  -smp 4 \
  -device virtio-net-pci,netdev=net0 -netdev vde,id=net0,sock=/var/run/vde.ctl \
  -drive file=./disks/ubuntu.qcow2,if=virtio \
  -cpu Nehalem

I should note that iperf3 showed speeds of 41mbits from the MacOS host and this VM.

output of configure:

Configure results:

 - VDE CryptCab............ disabled
 + VDE Router.............. enabled
 - TAP support............. disabled
 + pcap support............ enabled
 - Experimental features... disabled
 - Profiling options....... disabled

This issue was automatically created by Allstar.

Security Policy Violation
Security policy not enabled.
A SECURITY.md file can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible. Examples of secure reporting methods include using an issue tracker with private issue support, or encrypted email with a published key.

To fix this, add a SECURITY.md file that explains how to handle vulnerabilities found in your repository. Go to https://github.com/lima-vm/vde_vmnet/security/policy to enable.

For more information, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Lima Version: 0.6

For creating a local k8s cluster I started two instance with --vmnet-mode=bridged specified for networking. After the initialization (by Kubeadm) of control-plane, node instance was expected to join the cluster.

Howerver, node instance kept stuck into NoReady status and I found the console of vde_switch kept printing "vde_switch: send_sockaddr port 3: No buffer space available".

I tried to increase wmem_max using:

echo 83886080 | sudo tee /proc/sys/net/core/wmem_max

But nothing resolved.

I wonder if this is a bug?

$ sudo vde_vmnet --vmnet-mode=bridged --vmnet-interface=en0 /tmp/vde.ctl
Initializing vmnet.framework (mode 1002)
Using network interface "en0"
* vmnet_mtu: 1500
* vmnet_interface_id: CD65D0DC-6BC7-4E0F-9F31-FD8A255DDD3E
* vmnet_max_packet_size: 1514
* vmnet_mac_address: 72:7e:fd:a5:36:a7

$ vde_switch
vde_switch: send_sockaddr port 3: No buffer space available
vde_switch: send_sockaddr port 3: No buffer space available
vde_switch: send_sockaddr port 3: No buffer space available
vde_switch: send_sockaddr port 3: No buffer space available