SLAC: Access-Driven CPU-to-GPU Side-channel Attacks via System-Level Cache on Apple Silicon

Aidong Adam Ding; Ruyi Ding; Saion K. Roy; Tianhong Xu; Yunsi Fei

SLAC: Access-Driven CPU-to-GPU Side-channel Attacks via System-Level Cache on Apple Silicon

T0 review · 3 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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…

desk verdict 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. read the letter →

arxiv 2608.09075 v2 pith:35LMEJ55 submitted 2026-08-10 cs.CR cs.AR

Tianhong Xu , Saion K. Roy , Ruyi Ding , Aidong Adam Ding , Yunsi Fei This is my paper · ORCID

classification cs.CRcs.AR

keywords AppleM1cacheside-channelsystem-levelPrime+ProbeCPU-to-GPUattackheterogeneousSoCGNNprivacyLLM

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

The 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.

GPrime+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.

Referee Report

3 major / 6 minor

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.

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 (3)

[§4.1–§4.2 and §3.2] 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.
[§5.2, Appendix D, Table 2] 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.
[§5.3.2, Eqs. (1)–(2)] 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.

minor comments (6)

[Abstract and §5.2, Table 2] 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.
[§4.5] 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.
[§4.5] 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.
[§3.3 and Figure 4] 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.
[Table 1] 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.
[§5.1 and Figure 7] 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.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity; the only same-author citation [32] is re-verified by in-paper experiments, and the attack workflow is a standard profile-then-match empirical evaluation.

full rationale

The paper's derivation chain is: (i) reverse-engineer the M1 SLC indexing from observed collisions (Section 3), (ii) build CPrime/CProbe and GPrime/CProbe from the recovered eviction sets (Section 4), (iii) measure covert-channel throughput (Section 4.5), and (iv) apply the channels to GNN and LLM workloads with a profile-then-match workflow (Section 5). Each stage is checked against fixed hardware measurements or ground-truth labels, not against the target result. The only same-author input is the prior EXAM paper [32], cited for 'the SLC is exclusive of the CPU caches and holds a NINE relationship with the GPU caches.' This citation is not load-bearing because Section 3.1 and Appendix C independently re-establish the residency behavior with first-party CPU-latency experiments, and the set-indexing hash is recovered from scratch in Section 3.3. The GNN and LLM results are not fitted inputs: the Access Mapping Matrix is attacker profiling knowledge, secret recovery is a set-cover or containment match against the observed vector, and accuracy is reported against ground truth. The dataset-average f_bar and threshold T are hyperparameters, not renamed predictions. The LLM response recovery uses a public local copy of the LLM for disambiguation, independent of the side channel. One non-circular caveat: Section 4.1 claims CPrime 'does not require the adversary to have GPU access,' but the only SLC_ES construction described (Section 3.2) explicitly fills the SLC from the GPU side; this is an internal threat-model inconsistency and missing support, not a circular derivation, so it leaves the CPU-only deployment path under-supported but does not make the derivation circular. Score 2 reflects the presence of a same-author citation for a central architectural premise, while the central claims retain independent empirical content.

Assumptions & free parameters 3 free parameters · 6 assumptions · 0 invented entities

The central claims rest on empirical reverse engineering of a proprietary cache and on several measured architectural properties (exclusive/NINE residency, LRU, no-write-allocate). These are not derived from first principles and are validated only on the authors' test hardware. The GNN attack's accuracy depends on per-dataset fitted thresholds.

free parameters (3)

noise coefficient eta = 0.6% for CPrime+CProbe, 0.4% for GPrime+CProbe
Fitted from experimental measurements in Appendix D and used to compute the trustworthiness threshold T for neighbor-count estimation in the GNN edge recovery attack.
trustworthiness threshold T per dataset = e.g., Cora 60 (CPrime) and 95 (GPrime); see Table 2
Calibrated separately for each dataset and priming strategy to decide when the pruning step in single-node edge recovery is applied; directly influences reported precision/recall.
average cache lines per node f_bar = Cora 46.78, Citeseer 117.72, Pubmed 17.63, Computers 25.97, Photo 25.29
Dataset statistic used in the neighbor-count estimator m_hat = sum(v)/f_bar (Eq. 4); derived from the same node profiles used in the attack.

assumptions (6)

domain assumption Apple M1 SLC is exclusive with respect to CPU private caches and NINE with respect to GPU caches
Stated in Section 2.2.1 and attributed to the authors' prior work [32]; the paper's own experiments in Section 3.1 are consistent with it, but it is an assumed architectural property that underpins both priming designs.
domain assumption The SLC replacement policy is LRU
Characterized empirically in Section 3.3; the covert-channel decoding rule 'probe only the last five primed addresses' relies on LRU eviction order.
domain assumption GPU writes do not allocate in the SLC
Empirically observed in Section 4.3 and motivates the two-kernel GPrime (write then read); no independent source is cited.
domain assumption GPU lacks reliable fine-grained timing, so probing must be done on the CPU
Cited to [11, 37] in Section 4.1; this fixes the asymmetric role assignment of the attack.
domain assumption Collision-profile clustering recovers true SLC set congruence
The reverse-engineering method in Section 3.2 assumes that test lines mapping to the same SLC set evict the same filler lines and that clustering these profiles yields correct eviction sets; validated only by internal consistency of the subsequent attack results.
domain assumption LLM token embeddings are page-aligned with power-of-two byte dimensions
Section 5.3 relies on this to derive the superset mapping (embedding of size 2^m maps to 2^(m-7) contiguous SLC sets); if PyTorch/Metal alignment differs, the 128/256 superset reduction does not hold.

how reviews work

0 comments

Cite this review

Pith. "Pith review of SLAC: Access-Driven CPU-to-GPU Side-channel Attacks via System-Level Cache on Apple Silicon." pith.science (2026). https://pith.science/paper/35LMEJ55

@misc{pith2026260809075,
  author       = {Pith},
  title        = {Pith review of: SLAC: Access-Driven CPU-to-GPU Side-channel Attacks via System-Level Cache on Apple Silicon},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/35LMEJ55}},
  note         = {Machine review of arXiv:2608.09075}
}

read the original abstract

Modern heterogeneous System-on-Chip designs integrate CPU cores and a GPU that share a last-level cache (LLC) or system-level cache (SLC). This sharing exposes a new cross-domain attack surface, and existing attacks on integrated platforms either exploit coarse-grained cache-occupancy contention or require the adversary to co-reside on the GPU with the victim to obtain accurate timing measurements. In this work, we target Apple Silicon heterogeneous SoCs and discover that GPU memory accesses leave set-level footprints in the shared SLC, observable to an unprivileged CPU process. This keen observation enables the first fine-grained, access-driven, Prime+Probe-style CPU-to-GPU cache side-channel attacks against GPU workloads. We first reverse-engineer the Apple M1 SLC set-indexing functions and the interactions between local private caches and the SLC. Building on these findings, we construct the CPrime+CProbe SLC side-channel technique, which monitors GPU victim activity from the CPU at cache-set granularity. We then introduce an accelerated variant, GPrime+CProbe, in which an adversary leverages the GPU for faster SLC priming, yielding a 6.4x increase in the covert-channel throughput. Lastly, we demonstrate two end-to-end privacy attacks using the new side-channels: a graph-edge reconstruction attack on Graph Neural Networks (GNNs) that achieves 90% edge accuracy across five datasets, and an LLM privacy attack that recovers input keywords with up to 94.8% accuracy and model responses with up to 88.9% accuracy across TinyLlama and GPT-2 Medium models. Our results reveal a new class of microarchitectural vulnerabilities in Apple Silicon and call for secure system cache designs for heterogeneous SoCs.