host UDS recvmsg returns EOF or corrupt data

[russellromney]

A Quark container can connect to a host Unix domain socket exposed through a bind mount, but reads from that socket return EOF or invalid data instead of the host reply.

This is a bug in the existing host UDS passthrough path, not a missing feature. Quark already detects a bind-mounted host socket inode, calls HostUnixConnect, and stores HostUnixSocketOperations for later send and receive calls.

The bug is in qvisor's host UDS recvmsg wrapper:

1. It passes the Quark hostfd to libc::recvmsg without translating it to the real OS fd.
2. It returns 0 for a successful recvmsg, so the guest sees EOF.
3. It converts EAGAIN into a positive byte count, so the guest can copy zero bytes as if they were data.

The fix is to translate the fd, return the real byte count, and keep errno values negative when passing them back to the guest.

Repro result before the fix:

host process -> OK
runc         -> OK
runsc        -> connect-failed errno=111
quark rw     -> EOF before reply
quark ro     -> EOF before reply

Result after the fix:

host process -> OK
runc         -> OK
runsc        -> connect-failed errno=111
quark rw     -> OK
quark ro     -> OK

A stricter static C client also passes under Quark for both rw and ro bind mounts. It fails if the first read returns EOF or if the reply starts with zero bytes.