Skip to content

refactor vmcall-raw send/receive, reject invalid VMM responses#867

Open
haitaohuang wants to merge 3 commits into
intel:mainfrom
haitaohuang:upstream/pr1-trivial-fixes
Open

refactor vmcall-raw send/receive, reject invalid VMM responses#867
haitaohuang wants to merge 3 commits into
intel:mainfrom
haitaohuang:upstream/pr1-trivial-fixes

Conversation

@haitaohuang
Copy link
Copy Markdown
Contributor

No description provided.

haitaohuang and others added 3 commits May 29, 2026 16:45
Extract the duplicated poll logic from vmcall_service_migtd_send
and vmcall_service_migtd_receive into poll_vmcall_completion().

The shared function handles: interrupt flag check, data_status
parsing, flag consumption after final status, and success/error
determination. Each caller only adds its operation-specific logic
(send returns data_length, receive copies payload to private Vec).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>
A hostile VMM can complete a tdvmcall_migtd_receive with
status=VMM_SUCCESS but data_length=0. The previous implementation let
this propagate as Ok(0) through VmcallRaw::recv, which would stall the
caller's read loop indefinitely (no forward progress, no error).

Reject zero-length success inside the receive poll_fn closure with
VmcallRawError::Malformed, which surfaces to upstream callers as a
network error instead of an infinite spin.

Also stop relying on the post-completion data_length on the send path
(per spec, data_length is owned by MigTD when status=0 and is not a
meaningful VMM-reported value after completion). The previously
returned value was already discarded by VmcallRaw::send, so this is a
no-op in behavior but makes the spec contract explicit. Document this
in the poll_vmcall_completion doc comment.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>
When the migration context has been destroyed (no entry in
VMCALL_MIG_CONTEXT_FLAGS for the request id), any interrupt injection
from the VMM should be rejected. Previously the else branch discarded
the error with `let _ = ...`, allowing execution to fall through and
treat DMA buffer contents as a valid VMM response.

Return an error immediately so the caller rejects the stale injection.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>
@haitaohuang haitaohuang requested review from jyao1 and sgrams as code owners May 29, 2026 16:49
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