A Checkpoint: What the Shared Switch Can Reveal

Open vSwitch (OVS) is now best understood as a shared, stateful forwarding component rather than a transparent pipe. This checkpoint connects the cache states, timing observations, and attacker-controlled traffic already established, then uses them to classify three different outcomes: covert communication, selected packet-header leakage, and approximate packet-rate leakage. The practical judgment is conditional: a side channel is defined not only by the existence of a timing difference, but also by which state changes, what the observer can reach, what they know, and what the evidence actually recovers.

One causal chain, three kinds of signal

The common chain starts with ordinary traffic. A VM, a service, or an external client sends packets through an OVS instance. OVS records enough forwarding state to make later packets cheaper to process. Activity from one flow can therefore alter a shared cache entry or a megaflow subtable's position. A later request takes a different amount of work, and the remote observer measures that difference as round-trip time.

The important word is shared. The observer does not need access to the victim VM's memory, the host's cache structures, or a privileged OVS console. They need a path that reaches the same forwarding component and a way to send repeatable traffic through it. The information crosses the boundary indirectly: the victim changes state, OVS turns state into processing cost, and the observer estimates the change from a response.

That causal chain has three branches:

  1. Timing state. A microflow hit, a megaflow hit after a microflow miss, and a slow-path lookup have different costs in the evaluated system. Repeated measurements can turn those costs into an estimate of cache state.
  2. Collision state. The microflow cache uses packet-header fields to select candidate locations. A new flow can displace an existing entry when the locations are occupied. Observing the displacement reveals a collision relationship between flows.
  3. Ordering state. The megaflow cache checks wildcarded subtables in sequence and reorders them by hit count. Relative traffic activity can therefore affect subtable position and the latency of a later lookup.

The branches are related, but they are not interchangeable. Timing is the sensor shared by all three. Collision state supplies information about how headers map to exact entries. Ordering state supplies information about relative use of broader rules. The output depends on which branch the attacker can make stable enough to measure.

flowchart LR T["VM and service traffic"] --> S["Shared OVS cache state"] S --> L["Processing latency"] L --> M["Remote repeated measurement"] M --> C["Cache-state inference"] S --> X["Microflow collision"] X --> H["Selected header metadata"] S --> O["Megaflow subtable order"] O --> R["Approximate packet-rate metadata"] M --> B["Covert communication"]

The diagram should not be read as saying that every branch reveals a secret automatically. It shows the mediator—the shared OVS state—and the observations that can be derived from it. A covert channel uses the state as a signal between parties. Header recovery uses collision relationships to narrow unknown fields. Rate monitoring uses ordering as a reference scale. The same shared switch can support all three in a DPDK configuration with both cache levels, but a change in datapath can remove one branch or make another noisier.

The same boundary, different outputs

The three attacks can be compared by asking five questions: who shares the OVS state, what can the attacker reach, what state do they perturb or observe, what comes out, and what stops the inference from being universal?