{"id":"3c8ea8b5-5f7b-499f-8020-f96b9358f8d0","arxiv_id":"2412.05228","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"Memory bandwidth contention in shared DRAM can carry covert signals between CPU and GPU on mobile SoCs without privileges, at rates up to 6.4 kbps.","lead":"Researchers built a covert channel on mobile chips where two unprivileged programs communicate by making the shared DRAM slower. The attack moves data between a CPU and a GPU on NVIDIA Orin boards at up to 6.4 thousand bits per second without needing a shared cache or administrator rights.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The abstract's headline '6.4 kbps with <1% error' is contradicted by Fig. 9a: that rate is measured at 94.9% accuracy (≈5.1% error), so the strongest claim as stated is internally inconsistent.","rationale":"The reader's verdict was CONDITIONAL with moderate confidence. Their weakest assumption focused on cache-bypass behavior of ldnp/stnp and memory-controller scheduling. That is a real empirical risk, but the paper's raw traces (Fig. 3) and parameter sweeps (Figs. 5 and 7) provide direct evidence that contention is observable, and testing that assumption would require new hardware-level experiments. In contrast, the rate/error contradiction is a correctness defect internal to the paper: the claimed 'up to 6.4 kbps with less than 1% error' cannot be true if the same configuration yields 6.4 kbps at 94.9% accuracy. This is the most load-bearing issue because it attacks the exact headline number in the abstract rather than a background assumption. It is also easily fixed by rewording to present the capacity/accuracy tradeoff, so it supports CONDITIONAL rather than REJECT. I partially agree with the reader: they noticed the inconsistency in their rationale but did not make it the weakest assumption. The concrete test above would either verify the contradiction, as the paper's text already suggests, or reveal a different interpretation, for example if 'accuracy' is computed over longer messages or after error correction; if so, the paper should state that clearly. The omitted GPU-transmitter negative result and lack of error bars are additional limitations but are secondary to the headline contradiction.","tokens_in":17855,"tokens_out":5445,"duration_ms":48697,"concrete_test":"Reproduce the Fig. 9a maximum-capacity data point (1 MB transmitter buffer, 1 MB receiver buffer, maximum copy iterations) with the released code on an Orin AGX: compute the achieved channel capacity and bit error rate over 10 repeated 100 Kb transmissions. If the capacity is ~6.4 kbps and the bit error rate is ~5% (matching the reported 94.9% accuracy), the abstract's '<1% error' claim is false for that configuration; a separate 2 MB/1.3 kbps run should then be used to verify where the <1% point actually lies.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim in the abstract and Section I — 'up to 6.4 kbps with less than 1% error rate' — is not supported by the paper's own evaluation. Section VI-D and Fig. 9a report that a 1 MB transmitter buffer with the maximum per-interval copy count reaches a channel capacity of ~6.4 kbps and an accuracy of 94.9%, i.e. a 5.1% error rate, an order of magnitude above the claimed <1%. The '<1% error' point appears at the other end of the tradeoff: a 2 MB transmitter buffer at ~1.3 kbps reaches 99.99% accuracy, and at ~3.5 kbps accuracy is 99.1%. Thus the headline conflates the two endpoints of an either/or tradeoff that the paper itself states: 'MC3 achieves either up to 6.4 Kbps channel capacity or up to 99.99% transmission accuracy.' The underlying channel may still exist, but as stated the strongest claim is internally inconsistent. A related gap is that the channel is only characterized in a quiet memory system; the claim that it works in 'single-user and multi-application environments' (Section I) is supported only by a sentence about heuristic history-based denoising in Section V-A, with no experiment under concurrent third-party memory traffic. However, the rate/accuracy contradiction is the more direct load-bearing defect because it is falsified by data already in the paper.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript introduces MC3, a software-only covert channel that encodes bits by modulating DRAM contention between a transmitter and a receiver on NVIDIA Orin SoCs. The transmitter uses non-temporal Arm64 load/store instructions to generate memory pressure that is observable as a bandwidth drop at the receiver, with no shared LLC, no elevated privileges, and no physical access. The paper evaluates CPU-to-GPU and CPU-to-CPU configurations on Orin AGX, NX, and Nano, and reports a trade-off between channel capacity and transmission accuracy. The headline claim is that MC3 achieves up to 6.4 kbps with less than 1% error rate.","tokens_in":18120,"tokens_out":3053,"duration_ms":31982,"significance":"If the reported measurements are reliable, MC3 demonstrates a new practical attack surface on shared-memory mobile SoCs: unprivileged, software-only, high-throughput communication through DRAM contention, without relying on an LLC. The paper's strengths include the use of raw traces, systematic parameter sweeps over transmitter and receiver buffer sizes, evaluation on three real platforms, and a publicly available implementation. The main technical risk is not circularity, since the channel is measured empirically, but rather an internal inconsistency in the headline rate/error claim and a lack of validation under concurrent third-party memory traffic.","major_comments":[{"comment":"The abstract and Section I state that MC3 achieves 'up to 6.4 kbps with less than 1% error rate.' This is contradicted by Section VI-D and Fig. 9a, which report that at the maximum per-interval copy count with a 1 MB transmitter buffer the channel capacity is approximately 6.4 kbps with 94.9% accuracy, i.e., a 5.1% error rate. The 99.99% accuracy point occurs at 1.3 kbps, and 99.1% accuracy at 3.5 kbps. The contributions bullet in Section I already states the trade-off correctly ('up to 6.4 Kbps with 95% accuracy' and '99.99% when the capacity is capped at 1.3 Kbps'). The abstract and introduction should be revised to present this either/or trade-off; as written, the strongest claim is internally inconsistent with the paper's own evaluation.","section":"Abstract, Section I, Section VI-D, Fig. 9a"},{"comment":"The paper claims in Section I that the attack works in 'single-user and multi-application environments.' The only support is one sentence in Section V-A stating that other applications' memory usage can be handled with 'heuristic history-based signal processing approaches.' No experiment introduces concurrent third-party memory traffic, so the multi-application claim is not supported by the presented evidence. The authors should either add an experiment with a background memory load or qualify the claim to quiet, single-application environments.","section":"Section I, Section V-A"}],"minor_comments":[{"comment":"The claim that ldnp/stnp non-temporal instructions bypass all cache levels is essential to the mechanism but is supported only by a citation to the Arm architecture manual. A short microbenchmark on the target Orin platforms comparing achieved DRAM bandwidth with and without non-temporal hints would make this assumption more convincing.","section":"Section V-C"},{"comment":"The paper switches between 'accuracy' and 'error rate' without consistently stating the conversion. Since the abstract promises 'less than 1% error rate,' please state explicitly that accuracy = 100% - error rate and use one convention throughout.","section":"Section VI-D, Fig. 9, Abstract"},{"comment":"The statement that GPU-based receivers achieve 2x-4x higher channel capacities on Orin Nano than CPU-based receivers is not supported by a displayed result; the accompanying figure (Fig. 7) shows only Orin AGX data. Please either include the Orin Nano data or mark this as an observed trend without a supporting figure.","section":"Section VI-B"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nRead MC3. Short version: the channel is probably real, but the headline number as written is wrong, and the authors need to fix that before anyone repeats \"6.4 kbps, <1% error\" in a citation.\n\nWhat is new: a software-only covert channel from CPU transmitter to GPU receiver over shared DRAM contention on mobile SoCs, without a shared LLC or elevated privileges. Prior CPU-GPU channels needed an LLC or privileged access; this one uses non-temporal ldnp/stnp to keep access streams out of caches and gets visible bandwidth modulation on Orin AGX, NX, and Nano. The raw traces in Figure 3 show the effect, and the design details for precise sleep and contention durations are careful. Code is promised. That is enough to take the existence of the channel seriously.\n\nThe soft spots are mostly correctable. The biggest is internal inconsistency: the abstract says 6.4 kbps with less than 1% error, but Figure 9a and Section VI-D report 94.9% accuracy (5.1% error) at 6.4 kbps; less than 1% error appears only at about 1.3 kbps. The authors themselves state that MC3 achieves either up to 6.4 Kbps or up to 99.99% accuracy. The conclusion blurs this again. Fix by reporting the tradeoff curve honestly as an either/or, not as simultaneous endpoints. Second, the GPU-transmitter negative result is mentioned and then omitted for space; that is an important datapoint and should be included, even briefly. Third, there is no comparison with Leaky Buddies, the closest CPU-GPU channel, and no measurement under concurrent third-party memory traffic; the \"single-user and multi-application environments\" claim is supported only by a sentence about heuristic history-based denoising. Fourth, the hysteresis threshold gamma and buffer sizes are tuned on the same hardware with no error bars or across-run variance; a few repeated runs would help.\n\nNone of this sinks the core phenomenon; the traces and sweeps are consistent with a real contention channel. But the stated rate/accuracy claim as written is not supported by the paper's own data. That has to be fixed in review.\n\nBottom line: worth sending to a serious security or architecture referee. I would not let the abstract claim through as is, but I would engage with the revised version. I would bring it to a reading group, and I would likely cite it for the existence of the CPU-to-GPU DRAM-contention channel once the numbers are reworded.","headline":"Real CPU-to-GPU DRAM-contention channel on mobile SoCs, but the headline '6.4 kbps at <1% error' contradicts the paper's own Figure 9 and needs an honest rewrite.","tokens_in":18740,"tokens_out":2385,"would_cite":true,"duration_ms":23959,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A software-only covert channel exploits shared DRAM on mobile SoCs, reaching 6.4 kbps without a shared cache or elevated privileges.","keywords":["covert channel","shared memory SoC","DRAM contention","non-temporal loads","Arm64 ldnp/stnp","CPU-GPU communication","memory controller","mobile SoC security"],"falsifier":"Run the MC3 transmitter-receiver pair on an Orin-class board while a third workload continuously streams DRAM at 30-50% of peak bandwidth; if the bit-error rate at 6.4 kbps rises well above 1% or the high/low bandwidth distributions overlap, the claim that the channel holds under multi-application conditions is refuted. Separately, a microbenchmark with hardware performance counters can check whether $ldnp$/$stnp$ actually miss all cache levels; if those loads hit L1 or L2 on the target CPU, the cache-bypass premise fails and the contention kernel is not actually DRAM-direct.","tokens_in":17619,"feed_emoji":"📡","tokens_out":6131,"duration_ms":56301,"temperature":0.7,"pith_summary":"This paper argues that on mobile system-on-chips where the CPU and GPU share DRAM but have no shared last-level cache, two unprivileged applications can still build a high-throughput covert channel. The transmitter creates memory pressure by repeatedly copying a buffer with non-temporal Arm64 instructions ($ldnp$/$stnp$) that bypass private caches and hit DRAM directly, while the receiver measures its own copy bandwidth and reads bits from the resulting dips. The authors report rates up to 6.4 kbps with under 1% error on three NVIDIA Orin boards, and near-perfect accuracy when the rate is lowered. A sympathetic reader should care because the result shows the shared DRAM itself, not a shared cache, can serve as a leakage medium on mobile and autonomous SoCs.","feed_headline":"Shared DRAM alone carries covert traffic at 6.4 kbps","feed_subtitle":"On NVIDIA Orin boards, unprivileged apps encode bits in memory dips and decode them from copy speed.","key_machinery":"The central mechanism is a DRAM-contention kernel built on non-temporal load/store pair ($ldnp$/$stnp$) Arm64 instructions, which are supposed to bypass the private cache hierarchy and generate direct memory-controller pressure. The transmitter modulates this pressure by toggling between contention and sleep over a fixed interval $T$; the receiver observes its own copy bandwidth and decodes with running-average normalization plus hysteresis thresholding. The capacity equation $1 / (Time_{T_x} \\times Slowdown_{R_x})$ captures the inverse trade-off between transmitter buffer size and channel rate, while the receiver-to-transmitter copy-epoch ratio ($R/T$) is the knob that trades throughput for noise resistance.","core_discovery":"MC3 is a software-only covert channel that encodes bits in memory-contention on the shared physical DRAM of mobile SoCs. To send '0' the transmitter sleeps for a fixed interval; to send '1' it runs a buffer-copy contention kernel. The receiver continuously copies its own buffer, normalizes its measured bandwidth against a running global average, and applies a hysteresis threshold to decode '0' and '1'. Because the contention kernel uses non-temporal $ldnp$/$stnp$ load/store pair instructions, the accesses are meant to bypass the private cache hierarchy and reach the memory controller, making the slowdown observable even when the transmitter is on the CPU and the receiver on the GPU. On NVIDIA Orin AGX, Orin NX, and Orin Nano, the paper reports up to 6.4 kbps channel capacity with error below 1%, and 99.99% accuracy when the capacity is capped at about 1.3 kbps.","pith_inferences":["If the same arbitration behavior appears on other shared-memory SoCs (Apple M-series, Qualcomm Snapdragon), the attack likely transfers, but the reported bit rates are only measured on Orin hardware and should not be assumed elsewhere.","A concrete countermeasure would be to randomize or spread memory-controller scheduling so that transmitter-induced pressure no longer yields a stable bandwidth dip; the paper does not evaluate such defenses.","The channel's robustness under concurrent third-party memory traffic is asserted with a heuristic but not measured, so the error-rate figures are probably optimistic for busy real-world devices.","Future Arm implementations that prefetch or partially cache non-temporal loads would directly weaken the cache-bypass assumption, making the channel's reliability a moving target across silicon revisions."],"forward_implications":["Unprivileged applications on shared-DRAM mobile SoCs can exfiltrate data across CPU-GPU boundaries without any shared cache or special permissions.","The R/T epoch ratio gives an operator a direct dial between speed and reliability, so the same channel can be tuned for fast bulk transfer or near-error-free short messages.","Memory-controller scheduling policies on SoCs without a shared LLC become a security-relevant decision, since a predictable arbitration creates the observable bandwidth dips.","The technique works on at least three Orin-family devices with different memory bandwidths, suggesting the mechanism generalizes across that hardware generation.","Because the transmitter only sleeps or copies memory, the attack avoids performance counters, privileged APIs, and physical access, making remote deployment plausible."],"supporting_citations":[{"why":"Defines the ldnp/stnp non-temporal hint semantics that underpin the cache-bypass premise.","marker":"[1]"},{"why":"Supplies the running-average normalization and threshold decoding method the receiver algorithm adapts.","marker":"[39]"},{"why":"Provides the CUDA bandwidthTest-style cudaMemcpy kernel used as the GPU receiver's copy operation.","marker":"[26]"},{"why":"Establishes that CPU workloads in SoCs often cannot saturate memory bandwidth, motivating the GPU-based receiver design.","marker":"[37]"},{"why":"Documents shared-memory-contention slowdown among heterogeneous PUs, the vulnerability MC3 exploits.","marker":"[6]"},{"why":"Provides the precise sleep-and-spin timing mechanism that keeps transmitter and receiver epochs aligned.","marker":"[3]"},{"why":"Shows prior cross-component CPU-GPU covert channels on integrated systems, the closest baseline MC3 distinguishes itself from.","marker":"[9]"}],"fun_headline_variants":["MC3: covert channel on shared DRAM hits 6.4 kbps","Memory contention leaks secrets on mobile SoCs at 6.4 kbps","Covert bits ride DRAM contention on Orin SoCs","No LLC? No problem: MC3 uses shared DRAM for covert chat","Shared memory contention becomes a 6.4 kbps covert pipe"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The channel stands on two premises: non-temporal $ldnp$/$stnp$ loads truly bypass the private cache hierarchy on the target CPUs, and the memory controller's arbitration turns the transmitter's copy traffic into a repeatable, microsecond-observable bandwidth dip at the receiver even when other applications are using DRAM; the paper validates the first on Orin hardware but only asserts, without measurement, that third-party memory traffic is handled by a history-based heuristic.","fun_headline_variants_meta":{"raw":{"variants":["MC3: covert channel on shared DRAM hits 6.4 kbps","Memory contention leaks secrets on mobile SoCs at 6.4 kbps","Covert bits ride DRAM contention on Orin SoCs","No LLC? No problem: MC3 uses shared DRAM for covert chat","Shared memory contention becomes a 6.4 kbps covert pipe"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000635,"raw_usage":{"total_tokens":2963,"prompt_tokens":1013,"completion_tokens":1950,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":629,"completion_tokens_details":{"reasoning_tokens":1853}},"tokens_in":629,"tokens_out":1950,"duration_ms":12392,"temperature":1.0,"reasoning_tokens":1853,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T20:49:31.560608+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the MC3 transmitter-receiver pair on an Orin-class board while a third workload continuously streams DRAM at 30-50% of peak bandwidth; if the bit-error rate at 6.4 kbps rises well above 1% or the high/low bandwidth distributions overlap, the claim that the channel holds under multi-application conditions is refuted. Separately, a microbenchmark with hardware performance counters can check whether $ldnp$/$stnp$ actually miss all cache levels; if those loads hit L1 or L2 on the target CPU, the cache-bypass premise fails and the contention kernel is not actually DRAM-direct.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the ldnp/stnp non-temporal hint semantics that underpin the cache-bypass premise."},{"cited_title":"Whispers in the hyper-space: high-speed covert channel attacks in the cloud","cited_arxiv_id":null,"evidence_quote":"Supplies the running-average normalization and threshold decoding method the receiver algorithm adapts."},{"cited_title":"Cuda samples","cited_arxiv_id":null,"evidence_quote":"Provides the CUDA bandwidthTest-style cudaMemcpy kernel used as the GPU receiver's copy operation."},{"cited_title":"Pccs: Processor-centric contention-aware slowdown model for heteroge- neous system-on-chips","cited_arxiv_id":null,"evidence_quote":"Establishes that CPU workloads in SoCs often cannot saturate memory bandwidth, motivating the GPU-based receiver design."},{"cited_title":"Shared memory-contention-aware concurrent dnn execution for diversely heterogeneous system-on-chips","cited_arxiv_id":null,"evidence_quote":"Documents shared-memory-contention slowdown among heterogeneous PUs, the vulnerability MC3 exploits."},{"cited_title":"The perfect Sleep() function","cited_arxiv_id":null,"evidence_quote":"Provides the precise sleep-and-spin timing mechanism that keeps transmitter and receiver epochs aligned."},{"cited_title":"Leaky buddies: Cross-component covert channels on integrated cpu-gpu systems","cited_arxiv_id":null,"evidence_quote":"Shows prior cross-component CPU-GPU covert channels on integrated systems, the closest baseline MC3 distinguishes itself from."}],"review_version":1}