{"id":"3eb89ff7-279c-44f6-bcb2-0a24bb98343d","arxiv_id":"2608.09075","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A CPU-side attacker can use Prime+Probe timing on the Apple M1 system-level cache to recover GPU workload secrets, including GNN graph structure and LLM input/output tokens.","lead":"This paper shows that on Apple M1 chips, an unprivileged CPU program can spy on what the GPU is doing by watching a shared system-level cache, and uses this to steal data from AI workloads. It is the first fine-grained CPU-to-GPU cache attack on Apple Silicon, and it recovers graph edges and LLM prompts/responses with high accuracy.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"CPrime's 'no GPU access' threat model conflicts with the only described SLC_ES construction, which requires GPU-side filling; the CPU-only attack's deployment path is unsupported.","rationale":"The reader's weakest_assumption identifies the same load-bearing concern: the CPrime 'no GPU access' claim is contradicted by the only described SLC_ES construction, which requires GPU-side filling. I agree with this assessment. This is the single most load-bearing issue because the paper's central value proposition is a set-level CPU-to-GPU side-channel usable by an unprivileged CPU process; if the eviction set cannot be built without GPU access, that proposition collapses for the flagship variant. The concern is internal to the paper's own description, not a disagreement with consensus. I considered other candidate concerns: the end-to-end attacks rely on multi-run averaging and calibrated thresholds (T, eta), which are empirically fitted and lack error bars; however, these affect quantitative accuracy claims but not the fundamental feasibility argument. The LLM response recovery uses a local copy of the same model, which is an unusual but not contradictory assumption given the 'shared library' threat model. The GNN profiling phase is somewhat underspecified, but the text allows a chosen-query setting and the exact profiling protocol may be a detail rather than a fatal gap. The eviction-set construction issue is more fundamental: it undermines the stated threat model of Sections 4.1 and 5, and directly affects the default configuration used in all end-to-end experiments. The reader's conditional verdict is appropriate: the paper should either provide a GPU-free SLC_ES construction or revise the threat model, and the GPrime results plus reverse-engineering contributions remain valuable. I therefore recommend no change to the verdict.","tokens_in":24749,"tokens_out":3799,"duration_ms":206782,"concrete_test":"On an Apple M1, attempt to construct SLC_ES using only CPU-side operations: allocate a candidate pool, use CPrime's two-stage L2-to-SLC eviction to populate SLC sets, and recover set congruence purely from CPU probe timing, replacing collision-profile clustering with a CPU-driven eviction-testing procedure. If no CPU-only method yields 4,096 usable eviction sets, then CPrime cannot be deployed by a GPU-less adversary and Section 4.1's claim must be revised. Alternatively, demonstrate a precomputation path: build SLC_ES once with GPU access, then verify it remains valid across process restarts and memory re-layouts; if it does not, the CPU-only variant is not reproducible as described.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's flagship contribution is CPrime+CProbe, claimed in Section 4.1 to 'not require the adversary to have GPU access' and in Section 5 to run 'entirely from an unprivileged CPU process, without GPU access.' However, the only SLC_ES construction method given, collision-profile clustering in Section 3.2, explicitly 'fill[s] the SLC from the GPU side' and accesses test lines 'from the GPU via another buffer'; Section 4.2 states that SLC_ES is built with exactly this method. No GPU-free mechanism is described, such as CPU-only eviction via L2 pressure, precomputed sets that remain valid across process restarts, or direct use of the recovered hash on physical addresses (which macOS does not expose to user space). Since CPrime's entire priming phase depends on SLC_ES, an adversary without GPU access cannot deploy the attack as specified. The end-to-end evaluations in Section 5 also use CPrime+CProbe as the default, so the headline GNN and LLM results inherit this deployment gap. This is an internal inconsistency in the capability model, not a matter of outside consensus. GPrime+CProbe, which explicitly requires GPU access, is not affected, so the reverse-engineering and side-channel findings remain credible.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"SLAC targets the Apple M1 system-level cache (SLC) and claims the first fine-grained, access-driven CPU-to-GPU Prime+Probe side-channel on Apple Silicon. The paper reverse-engineers the SLC's 12-bit set-indexing hash functions and its LRU replacement policy, then builds two variants: CPrime+CProbe, which primes and probes entirely from the CPU and is claimed to require no GPU access, and GPrime+CProbe, which primes from the GPU for speed. Covert channels achieve 62.5 Kbps and 400 Kbps respectively. The authors then demonstrate two end-to-end attacks: GNN edge recovery with over 90% recall across five datasets, and LLM privacy attacks recovering input keywords (up to 81.2% with CPrime, 94.8% with GPrime) and output tokens (up to 85.3% with CPrime, 88.9% with GPrime) on TinyLlama and GPT-2 Medium. Supporting techniques include differential tracing, multi-run averaging, cache-set superset aggregation, and a local-model-based disambiguation for autoregressive token recovery. An artifact package is released.","tokens_in":24930,"tokens_out":7554,"duration_ms":82220,"significance":"If the results hold, this is a substantial step forward: it is the first demonstration that GPU memory accesses leave set-level footprints observable to an unprivileged CPU process on Apple Silicon, and it provides a reusable reverse-engineering methodology for the SLC set-indexing functions. The empirical work is detailed and internally cross-validated through covert channels and two distinct end-to-end attacks, and the artifact release should enable independent verification. The 6.4x priming speedup for GPrime and the differential-tracing noise-reduction strategy are useful contributions in their own right. The main weaknesses are the unsupported CPU-only deployment claim for CPrime and the reliance on per-dataset calibrated thresholds and fitted noise coefficients, which currently makes the headline accuracy numbers point estimates rather than robust claims.","major_comments":[{"comment":"The CPU-only threat model is not supported by the described setup. Section 4.1 states that CPrime 'does not require the adversary to have GPU access,' and Section 5 states that the primary attacks 'run entirely from an unprivileged CPU process, without GPU access.' However, the only SLC_ES construction method given, collision-profile clustering in Section 3.2, explicitly 'fill[s] the SLC from the GPU side' and accesses test lines 'from the GPU via another buffer,' and Section 4.2 confirms that SLC_ES is built with exactly this method. Additionally, the differential-tracing baseline in Section 5.1 requires the attacker to 'run an idle kernel' that invokes the victim's library function with an empty input set, which also requires the ability to launch GPU work. The paper provides no GPU-free eviction-set construction, no demonstration that a one-time GPU-enabled setup yields an SLC_ES that remains valid across process restarts and kernel invocations, and no discussion of how the macOS page-remapping fragility noted in Section 4.2 is handled over the 1,000–4,000 runs used for averaging. Because the end-to-end evaluations in Section 5 use CPrime+CProbe as the default, the headline claims inherit this deployment gap. The authors should either provide a workable CPU-only SLC_ES construction (e.g., through L2-pressure evictions) and a GPU-free baseline, or revise the threat-model claim to reflect that CPrime requires a one-time GPU-enabled setup phase.","section":"§4.1–§4.2 and §3.2"},{"comment":"The reported GNN accuracy numbers are point estimates resting on per-dataset calibration and fitted noise parameters, with no error bars or trial counts. Appendix D introduces a noise coefficient eta (0.6% for CPrime, 0.4% for GPrime) 'estimated from our experimental measurements' and derives the dataset-specific trustworthiness threshold T from Eq. (9), which uses a 95% normal-quantile argument without any empirical validation of that confidence claim. The Table 2 precision/recall entries are single values with no indication of the number of repeated attack runs or their variance, so the abstract's claim of '90% edge accuracy across five datasets' is not yet established as a robust statement. Further, the pruning algorithm returns \\hat{C} unchanged whenever m_hat >= T or the size-m_hat enumeration exceeds the cap K_max=10^5, which the dense-graph results (Computers, Photo) suggest is the operative regime there; the paper should report how often each fallback path triggers per dataset and provide a sensitivity analysis of the reported precision/recall to eta and T.","section":"§5.2, Appendix D, Table 2"},{"comment":"The response-recovery attack depends on assumptions that are not stated in the threat model. The disambiguation step requires the attacker to possess and run a local copy of the exact same LLM ('the attacker uses a local copy of the same LLM as a language model'), and the scoring in Eqs. (1)–(2) implicitly assumes greedy decoding. If the victim's inference uses sampling (temperature or top-p) or beam search, the local-model probabilities are mismatched, and the reported 70–85% (CPrime) and 75–89% (GPrime) token accuracies would not transfer. The paper should state the victim's decoding strategy, justify the assumption that the open-weight model used by the victim matches the attacker's local copy, and report accuracy as a function of decoding parameters. The statement that 'for a response of r output tokens, the attacker therefore collects r-1 traces' is also imprecise, since each generated token plus the final prompt token induces a lookup; this should be clarified.","section":"§5.3.2, Eqs. (1)–(2)"}],"minor_comments":[{"comment":"The abstract's '90% edge accuracy across five datasets' is stronger than what Table 2 supports: under CPrime, full-graph precision on Computers is 86.6% and recall on Citeseer is 90.5%. The claim should be qualified as 'over 90% recall' or report the precision/recall ranges explicitly.","section":"Abstract and §5.2, Table 2"},{"comment":"The throughput arithmetic is not transparent: with a 8 ms prime slot and 6 ms probe slot, a 14 ms CPrime+CProbe cycle carrying 1,024 bits gives about 73 Kbps, above the reported 62.5 Kbps, and the GPrime cycle (2 ms + 6 ms, 4,096 bits) gives about 512 Kbps, above the reported 400 Kbps. Please state the overheads (synchronization, slot padding, decoding) that account for the difference.","section":"§4.5"},{"comment":"The statement that the receiver 'probes only the last five primed addresses' deserves a justification; it is not obvious why five, rather than one or all sixteen, is the right trade-off, and the sensitivity of the 99% decoding accuracy to this parameter is not reported.","section":"§4.5"},{"comment":"The recovered set-indexing functions are validated only through the eviction-set construction pipeline. A direct held-out validation (predicted set index vs. measured cluster label for physical addresses not used in clustering) would substantially strengthen confidence in the 12 recovered bit functions.","section":"§3.3 and Figure 4"},{"comment":"The undercount/overcount and FNR/FPR rates are presented without trial counts or confidence intervals; given that these rates are used to justify the 4,000-run vs. 1,000-run averaging choice, reporting the spread across repeated runs would be helpful.","section":"Table 1"},{"comment":"The differential-tracing procedure subtracts an idle-kernel baseline from the target trace, but the paper does not discuss how the attacker obtains the idle-kernel baseline when the victim process is the only one allowed to launch kernels; this is related to the CPU-only threat-model gap but deserves an explicit paragraph even if the setup-phase assumption is retained.","section":"§5.1 and Figure 7"}],"recommendation":"major_revision","confidential_remarks":"The paper's core technical result—set-level CPU observability of GPU SLC activity on Apple M1, with the reverse-engineered index functions and both attack variants—is credible and well cross-validated internally, and the artifact release is a strong plus. The decisive issue for acceptance is the CPrime deployment gap: the CPU-only variant is the flagship contribution and the default for the end-to-end attacks, yet its only described eviction-set construction and baseline procedure require GPU-side operations. This is a fixable gap if the authors can demonstrate a GPU-free SLC_ES construction or reposition CPrime as requiring a one-time GPU-enabled setup, but it must be resolved rather than restated. The fitted noise coefficient eta and the derived thresholds should also be tabled with trial counts and sensitivity analysis, since referees in this area will likely probe the no-error-bar accuracy claims."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core result holds up: this is the first set-level, access-driven CPU-to-GPU Prime+Probe on Apple Silicon, and the reverse-engineering of the M1 SLC set-indexing hashes is a genuine contribution. The covert channels and the two end-to-end attacks are cross-validated in enough detail to be credible, and the artifact package makes the work reproducible. The authors did the hard part: they figured out how GPU traffic lands in the SLC and how a CPU spy can see it at set granularity. That is a solid step beyond the prior occupancy attacks on the same platform.\n\nThe soft spot is the one the reader flagged, and it is real. Section 4.1 says CPrime does not require GPU access, but the only described way to build SLC_ES is collision-profile clustering, which explicitly fills the SLC from the GPU side and accesses test lines from the GPU. Section 4.2 then says SLC_ES is built that way. So the flagship CPU-only attack, and by extension the GNN and LLM results that default to CPrime+CProbe, is not deployable by an adversary who truly has no GPU access at any point. The paper needs either a GPU-free eviction-set construction, a precomputation story, or a revised threat model that acknowledges a one-time GPU-assisted setup. This is fixable, but it is a load-bearing gap, not a nitpick.\n\nThe statistical reporting is thinner than I would like: the per-dataset thresholds T and the fitted noise coefficients (eta=0.6%/0.4%) come without error bars or trial counts. That is a minor-to-moderate issue; the differential tracing and the 99%+ superset accuracies suggest the signal is real, but the headline percentages should be read with that calibration in mind.\n\nGPrime+CProbe is not affected by the CPrime gap, and the reverse-engineering and side-channel methodology remain credible. So the paper deserves a serious referee, and I would send it to review with a request for a major revision that resolves the threat-model inconsistency and adds basic statistical reporting. Whoever reads it will learn something real about Apple Silicon and cross-domain cache attacks; just don't let the CPU-only claim slide through as written.","headline":"The set-level CPU-to-GPU SLC side-channel and the reverse-engineered M1 hash functions are real results worth refereeing; the CPrime threat model has a deployment gap that needs an explicit fix.","tokens_in":25549,"tokens_out":1430,"would_cite":true,"duration_ms":17378,"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":"By observing set-level footprints in Apple's shared system-level cache, an unprivileged CPU process can reconstruct GNN graph edges (over 90% accuracy) and LLM input/output tokens (up to 94.8% input, 88.9% output) from GPU-accelerated…","keywords":["Apple M1","cache side-channel","system-level cache","Prime+Probe","CPU-to-GPU attack","heterogeneous SoC","GNN privacy","LLM privacy"],"falsifier":"On an Apple M1, launch the CPrime+CProbe attack from a CPU-only process in a sandbox that blocks Metal and GPU kernel launches, then attempt to construct SLC_ES using the paper's collision-profile clustering method; if the eviction set cannot be built without GPU-side filler kernels, or the covert channel and downstream attacks fail entirely, the 'no GPU access' threat model is disproven.","tokens_in":24490,"feed_emoji":"🕵️","tokens_out":7729,"duration_ms":63907,"temperature":0.7,"pith_summary":"The paper claims that on Apple M-series SoCs, GPU memory accesses leave set-level footprints in the shared System-Level Cache (SLC) that an unprivileged CPU process can observe, enabling the first access-driven Prime+Probe CPU-to-GPU side-channel. It reverse-engineers the Apple M1's SLC set-indexing hash functions and builds two attack variants: CPrime+CProbe, which needs no GPU access from the adversary, and GPrime+CProbe, which uses GPU parallelism for faster priming, reaching covert-channel throughputs of 62.5 Kbps and 400 Kbps respectively. Using these channels, the authors demonstrate end-to-end privacy attacks on GPU workloads: a GNN edge-reconstruction attack recovering over 90% of edges across five datasets, and an LLM attack recovering input keywords with up to 94.8% accuracy and output tokens with up to 88.9% accuracy on TinyLlama and GPT-2 Medium. If correct, a co-resident unprivileged CPU process could exfiltrate private data from GPU-accelerated AI inference on Apple hardware, which would motivate secure system-cache designs for heterogeneous SoCs.","feed_headline":"CPU attackers read GPU AI secrets on Apple M1 via system cache","feed_subtitle":"Covert channel hits 400 Kbps; over 90% of graph edges and up to 94.8% of input tokens leak to an unprivileged CPU process.","key_machinery":"The central object is the Apple M1 System-Level Cache (SLC), an 8 MB, 4,096-set, 16-way last-level cache shared by the CPU clusters and the GPU. The load-bearing mechanism is the asymmetry of its residency policies: exclusive with respect to CPU private caches (so CPU data enters the SLC only through L2 capacity evictions) and non-inclusive non-exclusive with respect to GPU caches (so GPU reads populate the SLC directly and can evict primed lines). On top of this sit three components: the recovered 12-bit set-indexing hash (XOR functions over physical address bits 7–32) that lets the attacker target specific SLC sets; the collision-profile clustering method that builds set-congruent eviction sets despite the fully hashed index; and the CPrime/CProbe protocol where SLC_ES (65,536 lines) plus an L2_ES evictor push attacker lines into the SLC, and a later CPU-side probe counts how many of the 16 ways per set were evicted, yielding an integer per-set trace of GPU activity.","core_discovery":"The central claim is that on Apple M1, GPU memory accesses populate the shared System-Level Cache (SLC) at cache-set granularity, and a CPU-side spy can detect which sets the GPU touched by priming the SLC with attacker-controlled lines and then timing their re-accesses. This works because the SLC is exclusive with respect to the CPU private caches, so CPU lines only spill into the SLC through capacity evictions, while the SLC holds a non-inclusive non-exclusive (NINE) relationship with the GPU caches, so GPU reads go directly into the SLC and later evict primed lines. The paper recovers a 12-bit XOR-hash set-indexing function for the M1 SLC, constructs eviction sets via a new collision-profile clustering method that tolerates the fully hashed index, and introduces a two-stage CPU-only priming procedure (CPrime) plus a faster GPU-primed variant (GPrime). It then shows concrete privacy leaks: a GNN edge recovery attack that reconstructs over 90% of graph edges across five datasets, and an LLM attack that recovers input keywords and output tokens from the embedding-layer lookups of TinyLlama and GPT-2 Medium.","pith_inferences":["A testable follow-up is whether the recovered 12-bit SLC set-indexing hash functions remain stable across M1 Pro/Max and M2; if so, the same CPrime+CProbe pipeline should transfer with recalibration only, as the authors suggest.","The collision-profile clustering method for eviction sets under fully hashed indexing may generalize to other fully hashed shared caches (e.g., certain AMD or Intel designs), opening the possibility of similar CPU-to-GPU side-channels beyond Apple Silicon.","Because the LLM response-recovery attack relies on a local copy of the same model to disambiguate candidate tokens, its practicality on proprietary models is untested; a smaller or differently trained language model might or might not preserve the reported accuracy.","The attack's dependence on a fixed SLC set-indexing function implies that per-boot randomization of the set-index hash would break eviction-set construction; whether such randomization is feasible without performance loss remains an open hardware countermeasure."],"forward_implications":["A co-resident unprivileged CPU process can infer fine-grained secrets from GPU-accelerated AI workloads on Apple M1 through the shared system cache alone.","GPU-accelerated workloads on Apple Silicon must treat the SLC as a hostile observation surface, motivating secure system-cache designs for heterogeneous SoCs.","The recovered SLC set-indexing function makes Apple M1's shared cache targetable at set granularity, providing a reusable foundation for future fine-grained attacks on this platform.","Because the GPU-primed variant multiplies covert-channel throughput by 6.4x, sandboxing or restricting GPU access from the adversary would not by itself neutralize the threat.","The lossless differential-tracing and superset-aggregation techniques extend the attack's accuracy to noisy, real-world kernels, showing that set-level CPU-to-GPU leakage is practical even under system background activity."],"supporting_citations":[{"why":"Prior characterization of Apple M1 SLC residency (exclusive vs. CPU, NINE vs. GPU) and occupancy-only attacks; the paper builds its set-level side-channel on this foundation.","marker":"[32]"},{"why":"Leaky Buddies: the prior CPU-GPU side-channel on Intel platforms that defines the cross-component threat model and the comparison baseline for CPU-to-GPU feasibility.","marker":"[6]"},{"why":"Provides L2 set-index details on Apple M1 used to construct the L2_ES eviction set for CPrime.","marker":"[35]"},{"why":"Supplies the iterative-pruning method for eviction-set construction that the paper uses for the L2 cache.","marker":"[28]"},{"why":"The graph convolutional network implementation used for the GNN edge-recovery attack.","marker":"[4]"},{"why":"GPT-2 Medium; its embedding table layout and model are used in the LLM input/output recovery attack.","marker":"[20]"},{"why":"TinyLlama; its embedding table layout and model are used in the LLM input/output recovery attack.","marker":"[36]"},{"why":"GNN benchmark datasets (Computers, Photo) used in the edge-recovery evaluation.","marker":"[22]"},{"why":"GNN benchmark datasets (Cora, Citeseer, Pubmed) used in the edge-recovery evaluation.","marker":"[34]"}],"fun_headline_variants":["Apple M1 CPU spy reads GPU cache sets to steal AI data","CPU adversary extracts GPU secrets on Apple Silicon via SLC","Apple M1 cache cross-domain attack: CPU leaks GPU GNN and LLM data","GPU AI workloads exposed on Apple M1 via CPU cache probes","System-level cache leak on Apple M1 lets CPU spy on GPU"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The claim that the CPU-only attack needs no GPU access rests on the unproven assumption that an adversary without any GPU capability can still build the SLC eviction set, since the paper's only described construction method fills and tests cache lines from the GPU side.","fun_headline_variants_meta":{"raw":{"variants":["Apple M1 CPU spy reads GPU cache sets to steal AI data","CPU adversary extracts GPU secrets on Apple Silicon via SLC","Apple M1 cache cross-domain attack: CPU leaks GPU GNN and LLM data","GPU AI workloads exposed on Apple M1 via CPU cache probes","System-level cache leak on Apple M1 lets CPU spy on GPU"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000553,"raw_usage":{"total_tokens":2730,"prompt_tokens":1137,"completion_tokens":1593,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":753,"completion_tokens_details":{"reasoning_tokens":1501}},"tokens_in":753,"tokens_out":1593,"duration_ms":10572,"temperature":1.0,"reasoning_tokens":1501,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T00:01:02.341019+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On an Apple M1, launch the CPrime+CProbe attack from a CPU-only process in a sandbox that blocks Metal and GPU kernel launches, then attempt to construct SLC_ES using the paper's collision-profile clustering method; if the eviction set cannot be built without GPU-side filler kernels, or the covert channel and downstream attacks fail entirely, the 'no GPU access' threat model is disproven.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Leaky Buddies: the prior CPU-GPU side-channel on Intel platforms that defines the cross-component threat model and the comparison baseline for CPU-to-GPU feasibility."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides L2 set-index details on Apple M1 used to construct the L2_ES eviction set for CPrime."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"GPT-2 Medium; its embedding table layout and model are used in the LLM input/output recovery attack."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"GNN benchmark datasets (Cora, Citeseer, Pubmed) used in the edge-recovery evaluation."}],"review_version":1}