trivial fixes, hardening and refactor#841
Closed
haitaohuang wants to merge 5 commits into
Closed
Conversation
Contributor
|
Could you please split and describe each specific issue in a standalone PR? It is hard for me to review all different topics together. |
haitaohuang
force-pushed
the
upstream/pr1-trivial-fixes
branch
from
5671ff0 to
131387c
Compare
Contributor
Author
|
@jyao1 this group are all changes in vmcall-raw area now. pushing other ones separately |
The VMM signals migration session cancellation by writing data_status byte[0]=0x02, byte[1]=0x03 (0x302) to the shared buffer. Previously, 0x302 was treated as a generic TdVmcallErr, reported as SecureSessionError (6), change to propagate and report it as VmmCanceled (10) in ReportStatus. In the SPDM path, MigtdTransport's send/receive implement the SpdmDeviceIo trait which cannot represent this error in its return types (SpdmResult and Result<usize, usize>). Log a warning when ConnectionAborted is detected so the VMM cancellation is visible in logs, even though the typed error cannot propagate through the SPDM library's trait boundary. Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>
…path The receive path used a unneeded two-step indirection: the first vmcall_raw_transport_dequeue issued a VMCALL, copied data from shared memory into CONNECTION_PKT_QUEUES via recv_packet(), and returned a placeholder vec. The second dequeue then popped the real data from the queue. This was probably copied design from another implementation with 'packet' based stream which is not applicable to vmcall-raw send/receive. Simplify by having vmcall_service_migtd_receive return the actual data directly — it already copies from SharedMemory (untrusted, host-accessible) into a private Vec via .to_vec(), preserving the security boundary. Remove dead code: push_stream_queues, pop_stream_queues, recv_packet, CONNECTION_PKT_QUEUES, add_stream_to_connection_map, remove_stream_from_connection_map, and related imports. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>
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
force-pushed
the
upstream/pr1-trivial-fixes
branch
from
131387c to
bca4774
Compare
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.