Skip to content

socket: the vsock descriptor is duplicated before Go takes it - #16

Open
closer-claudio wants to merge 1 commit into
mainfrom
fluffy/20261022-vsock-dup
Open

closer-claudio wants to merge 1 commit into
mainfrom
fluffy/20261022-vsock-dup

Conversation

@closer-claudio

Copy link
Copy Markdown
Contributor

What changes

convertVZVirtioSocketConnection2Flat hands Go a dup() of the VZVirtioSocketConnection's file descriptor instead of the descriptor itself, or -1 with errno, which newVirtioSocketConnection turns into an error. Go's close is now of its own copy; the framework's is of its own. FORK.md records the change.

Why

VZVirtioSocketConnection owns its file descriptor and closes it when the object is destroyed (VZVirtioSocketConnection.h in the 27.0 SDK: "The file descriptor is owned by the VZVirtioSocketConnection. It is automatically closed when the object is destroyed"). The conversion handed Go that very descriptor; Go made its net.FileConn copy and closed the original, so the number was freed and reused, and the framework's later close hit whatever had it. In zerogravity that was the guest agent's HTTP connection: a request cut tens of seconds after the vsock dial, seen twice, each time on a command the guest ran under the request context (restarting sshd: context canceled, scutil --set HostName: context canceled). Upstream fixed the same defect after this fork's point (SocketConnectionDuplicatedFileDescriptor on Code-Hex/vz main). A descriptor of -1, which the header defines as a closed connection, now surfaces as an error (dup(-1) fails with EBADF) instead of an os.File on a bad number.

Both entry points, the dial completion and the listener's accept, go through the one conversion.

Evidence

just lint and just test green. The running-guest evidence is zerogravity's next install on the bumped pin.

Created by @apostasie personal assistant

VZVirtioSocketConnection owns its file descriptor and closes it when the
object is destroyed (VZVirtioSocketConnection.h). The flat conversion
handed Go that very descriptor; Go made its net.FileConn copy and closed
the original, and the framework's later close hit whatever number the
kernel had reused in between. In zerogravity that was the guest agent's
HTTP connection: a request cut tens of seconds after the vsock dial, seen
twice ("restarting sshd: context canceled", "scutil --set HostName:
context canceled"), each time on a command the guest ran under the
request context. The conversion now hands Go dup() of the descriptor, or
-1 with errno, which Go turns into an error; Go's close is of its own
copy and the framework's is of its own. Upstream fixed the same defect
after our fork point (SocketConnectionDuplicatedFileDescriptor).

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Signed-off-by: closer-claudio <[email protected]>
@closer-claudio

Copy link
Copy Markdown
Contributor Author

Reviewed at 43d5bad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant