Virtualization.framework: getting Guest's CID from host side

Question

pcfist OP

Created 1w

Replies 2

Boosts 0

Participants 2

Hi everyone!

I'm developing a system where an application running in a VM communicates with the host operating system's components using vsock sockets (VZVirtioSocketDevice in Virtualization.framework). Both systems are running macOS. There may be multiple guests, and the existing implementation for other OSes relies on VM's CID to differentiate them.

In macOS, getting the CID from inside the guest VM is straightforward—it is returned by IOCTL_VM_SOCKETS_GET_LOCAL_CID.

However, in macOS the regular vsock API is not available on the host side, replaced by Virtualization.framework. I could not find anything in the Virtualization.framework's documentation that could be used to query (or set?) the CID for the specific virtual machine instance (which is certainly possible on other platforms utilizing Virtio drivers, e.g. Linux/QEMU). Am I overlooking something?

Boost

Answer 1

Engineer OP

Apple

1w

There is not API to query the guest CID from the host.

With the user space implementation of vsock, every guest has a CID of 3 and they are all independent. The host have CID of 2.

What are you trying to achieve?

1

Answer 2

pcfist OP

1w

Hello and thank you so much for quick response!

The service application running on the host must be able to tell which client has connected to it via vsock. I have working code that runs on Linux (based on a "classic" vsock implementation), and it has to use different port numbers for each client, otherwise it would be impossible for multiple guests to connect to a single host.

I tried to reuse the same approach in macOS, but it seems to be impossible. However, I understand it is not even required in macOS, since VM instances run by the Virtualization.framework are already isolated from each other. When the host app receives an incoming connection, it will be able to tell which client has connected just by using different VZVirtioSocketListenerDelegate.

I haven't tested it yet, but I feel like this approach should work. Thanks again for clarification!

0