# Multi-Line Prefetch Covert Channel with Huge Pages
## 4 The Design of a Multi-Line Prefetch Covert Channel with Huge Pages
### The Workflow for Multi-Line Encoding and Decoding  
The Sender Workflow:  
Wait for the receiver: The sender waits for receiver_done_flag to ensure that the receiver has processed the previous iteration. The sender encodes a value by accessing _value_ cache lines for \(0\leq value\leq n-1\). For example, to transmit the value 3, the sender accesses three cache lines. In order to amplify the signal further, for \(value=m\) cache accesses, we access \(m\) buckets of cache lines instead, where each bucket consists of \(b\) cache lines. Hence, the total number of cache lines accessed to encode a value \(m\) is then \(m*b\). This also places another constraint that \(m*b\leq n-1\), which in our case is 512 lines. We experimented with bucket sizes \(1\leq b\leq 50\), which yielded \(b=50\) as the best choice for the accuracy. Time operation: The sender uses rdtscp() for precise timing. Signal completion: The sender updates receiver_done_flag to notify the receiver to start decoding. The Receiver Workflow:  
Wait for the sender: The receiver waits for receiver_done_flag which indicates that the sender has completed its encoding. Decode the message: The receiver measures the timing of its PREFETCHW operations across all 512 L1 cache lines and decodes the message by comparing the measured timings against the calibrated thresholds (\(T1\) to \(Tn\)). The timing differences are influenced by the cache coherence protocol and the state transitions of the cache lines. When the PREFETCHW instruction is executed, it modifies the state of the cache line to M (modified). The latency observed during this operation depends on whether the state of the cache line is M or S (shared):  
If the sender has not accessed the cache line, it remains in the M state when the receiver prefetches again. In this scenario, the PREFETCHW operation does not cause any state change and completes quickly. If the sender accessed the cache line, the state transitions to S. When the receiver prefetches the same cache line, the PREFETCHW operation needs to inform the LLC to invalidate the copy in the sender's private cache and transition the state back to M. This additional step increases the latency. For example, in one experiment, the receiver observed that the PREFETCHW operation took approximately 130 cycles when the state transitioned from S to M, as the LLC had to invalidate the sender's copy of the cache line. In contrast, when the cache line remained in the M state, the PREFETCHW operation completed in around 70 cycles since no state change was required. These timing differences are exploited by the receiver to infer whether the sender accessed the cache line, enabling it to infer the number of sender-accessed cache lines, which, divided by the bucket size \(b\), decodes the message accurately. Store the decoded message: The receiver stores the decoded message for further processing or logging. Signal readiness: The receiver sets receiver_done_flag to notify the sender to start the next iteration. The protocol is shown in Figure 1 and Algorithm 2. The sequence of interactions (Labeled Edges) is 1. The receiver sets receiver_done_flag = 1 after the initial prefetch measurement. 2. The sender detects that receiver_done_flag = 1 and resets it to 0. 3. The sender accesses memory lines (encoded with secret data) during config.interval. 4. The receiver prefetches memory lines and measures the timing (affected by the sender's cache state). 5. The receiver sets receiver_done_flag = 1 to signal readiness for the next message.