vmbus_serial_guest: add tx only option

[tjones60]

Add an option to the VMBUS serial relay that runs in OpenHCL to drop all rx traffic from the host and only allow tx traffic from the guest. This could be attested to in the future and offer a more secure way to debug a VM using the serial console, since only allowing one-way serial traffic would greatly reduce the possible attack surface. This is useful primarily for CVMs that don't have a framebuffer and are usually configured with serial disabled completely.

[github-actions]

⚠️ Unsafe Code Detected

This PR modifies files containing unsafe Rust code. Extra scrutiny is required during review.

For more on why we check whole files, instead of just diffs, check out the Rustonomicon

[Copilot]

Pull Request Overview

This PR adds a tx_only option to the VMBUS serial relay running in OpenHCL that drops all RX traffic from the host while allowing TX traffic from the guest. This enables unidirectional (guest-to-host only) serial communication.

• Added tx_only boolean field throughout the configuration chain from CLI to the VMBUS serial driver
• Modified VmbusSerialDriver::poll_read() to clear the RX buffer and return Poll::Pending when tx_only is enabled
• Added test coverage for the tx_only behavior

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
vm/devices/serial/vmbus_serial_guest/src/lib.rs	Core implementation: adds tx_only field to config/driver, modifies AsyncRead to drop RX data, adds test
vm/devices/get/guest_emulation_transport/src/lib.rs	Updates test fixtures to include tx_only field
vm/devices/get/guest_emulation_transport/src/client.rs	Parses tx_only from JSON config for both COM ports
vm/devices/get/guest_emulation_transport/src/api.rs	Adds tx_only fields to platform settings API
vm/devices/get/guest_emulation_device/src/test_utilities.rs	Updates test utilities with serial_tx_only field
vm/devices/get/guest_emulation_device/src/resolver.rs	Threads serial_tx_only through resource resolution
vm/devices/get/guest_emulation_device/src/lib.rs	Adds serial_tx_only to GuestConfig and propagates to HclUartSettings
vm/devices/get/get_resources/src/lib.rs	Adds serial_tx_only field to GED resource definition
vm/devices/get/get_protocol/src/dps_json.rs	Adds tx_only field to HclUartSettings protocol struct
petri/src/vm/openvmm/construct.rs	Initializes serial_tx_only to false in test VM config
openvmm/openvmm_entry/src/lib.rs	Maps CLI serial_tx_only option to guest config
openvmm/openvmm_entry/src/cli_args.rs	Adds --serial-tx-only CLI argument
openhcl/underhill_core/src/worker.rs	Opens VMBUS serial devices with tx_only setting from DPS config

[Copilot]

When tx_only is true, this implementation still requests RX data from the host (via poll_outer -> poll_inner which checks rx_waker.is_some() at line 283), only to discard it here. This wastes CPU cycles and bandwidth. Consider checking tx_only before the loop (line 396) and returning Poll::Pending immediately without setting rx_waker, or checking tx_only in poll_inner (line 282) to avoid requesting RX data in the first place.

[github-actions]

At least one Petri test failed.

[smalis-msft]

Why?

[tjones60]

Why?

This is intended to be an option for CVMs that could be attested to, so you could enable serial output for debugging purposes without allowing interactive login to reduce risk.

[smalis-msft]

Put that in the pr description?

[mebersol]

    console_enabled: dps.general.com1_enabled

an additional runtime claim is needed here.

I think we agreed on something like "console-mode:serial|serialbootdiagnosticsonly"

---

Refers to: openhcl/underhill_core/src/worker.rs:1782 in 3d6d329. [](commit_id = 3d6d329, deletion_comment = False)