PSD v5.0: High-resolution video and independent display emulation

Issue
PSD v5.0 should provide clear requirements for high-resolution video implementations, including 4K, 5K, and 8K, within the existing Video/Display PP-Module.

The security question is not resolution alone. It is how the PSD handles display capabilities, link negotiation, status, control transactions, and retained state without creating a communication path between protected computers through a shared display.

This proposal does not assume that earlier PSD requirements prohibit all high-resolution video. It requests explicit coverage of the security-relevant mechanisms used by supported implementations.

Proposed change
Require each protected computer to interact with an independently isolated, TOE-controlled display-emulation function for capability, control, and return-channel transactions.

The TOE shall:

• Terminate the physical display’s capability/control interface separately from each host-facing interface.
• Generate host-facing responses through the corresponding isolated emulator, rather than transparently forwarding physical-display transactions.
• Prevent one computer from modifying capability data, registers, configuration, or retained state subsequently observable by another computer.
• Permit only the declared video functions and control transactions required by the evaluated configuration.
• Preserve the required electrical and functional isolation during link negotiation, selection changes, reset, reconnection, and failure.

This includes applicable mechanisms such as HDMI DDC/SCDC and DisplayPort AUX transactions, including display identification and capability information. Unsupported transactions and functions shall not provide a bypass around the required isolation.

Display emulation must cover the supported control exchanges; filtering EDID alone shall not be treated as sufficient evidence that all return channels are controlled.

Supported implementation features
The Security Target shall identify supported interfaces, resolutions, refresh rates, link modes, and any compression or multi-stream functionality.

Higher-bandwidth switching components, retimers, converters, or frame buffers may be used where their security-relevant paths and state are included in the evaluation. Their presence shall not exempt an implementation from isolation requirements.

Support for a particular resolution shall not imply blanket authorization of every optional feature of the underlying interface standard.

Evaluation considerations
The CCTL should:

1. Review the architecture: Identify every host-facing emulator, display-side interface, control path, and shared-state boundary.
2. Exercise return channels: Use a programmable display or protocol exerciser to vary capability data, status, and control responses. Verify that hosts receive only TOE-authorized emulated behavior.
3. Attempt cross-host signaling: Have one host write distinguishable markers or alter link/control state, then verify that another host cannot retrieve or observe those changes through the PSD.
4. Exercise supported modes: Cover each distinct security-relevant protocol path, including compression or multi-stream processing where implemented, rather than testing only one resolution.
5. Test transitions and failures: Verify isolation during switching, hot-plug events, link retraining, reset, and power recovery, including residual-image and buffer handling where applicable.

Logical representative testing and physical-leakage testing shall follow their separately justified coverage rules.

Requested change and scope
Update the existing Video/Display PP-Module’s requirements, application notes, and Evaluation Activities, incorporating applicable Technical Decisions and resolving any conflicting wording.

Start by locating the existing Video/Display PP-Module, its requirements, application notes, and Evaluation Activities, then review applicable Technical Decisions and conflicting wording. Map host-facing emulators, display-side interfaces, control paths, and shared-state boundaries described in the issue. Done means the module explicitly covers supported interfaces, modes, isolation, return channels, transitions, failures, and corresponding evaluation activities.