# Multi-Line Prefetch Covert Channel with Huge Pages
## 7 AMD SEV Covert Channel Evaluation  
To further evaluate our covert channel implementation in a real-world TEE scenario, we conducted experiments on AMD SEV VMs deployed on Google Cloud Confidential Compute instances. We focused on testing the multi-line encoding performance under varying sender access patterns (write or read) and memory configurations (with and without huge pages). Each test used 10 rounds per configuration. Initially, we experimented with using the rdtscp() instruction to measure the latency, consistent with our approach on the local Intel machine. However, we observed that prefetching 512 cache lines on the AMD SEV VM took only \(\sim\)4700 cycles, compared to \(\sim\)49,000 cycles on a local Intel i5 processor--more than a \(10\times\) discrepancy. This large gap is not due to architectural performance differences but stems from virtualization: rdtscp() is emulated or virtualized in cloud environments like SEV VMs, yielding an inflated timing precision or inaccurate cycle counts. As a result, we adopted clock_gettime(CLOCK_MONOTONIC) to ensure consistent and stable wall-clock timing. This syscall-based method returns the elapsed time since boot, measured in nanoseconds, and is unaffected by CPU frequency scaling or virtualized performance counters. Although this wall-clock-based method has a lower granularity than that of hardware cycle counters, it avoids the artifacts introduced by virtualized timestamp counters (TSCs). Interestingly, this approach reported even faster timing (e.g., \(\sim\)920 ns for 512 cache lines prefetching), roughly \(20\times\) faster than Intel's rdtscp-based measurements. We considered alternate software-based timing techniques, such as loop-based counters or instruction delays, but these proved less reliable due to noisy scheduling, interrupts, and a lack of deterministic scaling under different system loads. Therefore, for our SEV evaluation, we selected clock_gettime() as the most consistent and portable option for cross-core timing measurements. Latency measurements using clock_gettime() were converted into CPU cycles based on a 2.45 GHz base frequency. Table 4 summarizes the average receiver-side prefetch latency when the sender reads or writes 50 lines in each configuration. When huge pages are enabled, the memory page size is 2 MB; otherwise, the system defaults to the standard 4 KB page size. As shown in the table, the latency measurements on the AMD SEV VM (e.g., 920.9-1063.9 ns or \(\sim\)2256.2-2606.5 cycles) were much lower than those on our local Intel testbed (\(\sim\)50,000 cycles). This discrepancy can be attributed to time counter virtualization in cloud VMs. While less precise in absolute terms, this timing still preserved the relative trends: increasing the number of lines accessed increased the receiver latency, and huge page usage consistently reduced the timing overhead. \begin{table}
\begin{tabular}{l c c c} \hline \hline
**Configuration** & **Avg Time (ns)** & **Avg Time (cycles)** & **Accuracy (\%)** \\ \hline With Hugepage Write & 920.9 ns & 2256.2 cycles & 88.03\% \\ Without Hugepage Write & 1004.1 ns & 2460.1 cycles & 84.25\% \\ With Hugepage Read & 1035.3 ns & 2536.5 cycles & - \\ Without Hugepage Read & 1063.9 ns & 2606.5 cycles & - \\ \hline \hline \end{tabular}
\end{table} 
Table 4: AMD SEV receiver latency. We observed that write-access encoding yields significantly clearer timing distinctions in AMD's MOESI coherence model due to the state transitions to the modified (M) state. Conversely, sender reads do not result in detectable cache state transitions on AMD--since prefetching transitions to the owned (O) state, not modified (M)--leading to no observable timing difference. We studied the decoding accuracy further, as we did before for the Intel local machine, using bucket sizes of 5, 10, 25, 30, and 40 lines with sender write access on an AMD SEV VM. Figure 3 shows that the decoding accuracy improves with an increasing bucket size, up to 88.03% for a size of 40 lines.