{"id":"e9490855-da21-474f-980c-a36acf2aea97","arxiv_id":"2504.13385","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"An attacker can use the exclusive System-Level Cache on Apple M-series chips to monitor GPU and other CPU activity, enabling website fingerprinting, pixel stealing, and screen snooping.","lead":"This paper demonstrates a new side-channel attack on Apple M-series Macs that measures how full the chip's shared System-Level Cache is. It could let a malicious webpage or app infer what the screen shows, including private text or barcodes, even when it runs on a different part of the processor.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The CPU-GPU and inter-cluster demonstrations may be measuring DRAM/memory-controller contention rather than SLC occupancy; the paper lacks a control separating the two.","rationale":"The reader's concern about GPU compression stability is real but application-level; even if that correlation is stable, the central channel could still be misattributed. My concern targets the foundational channel validation: whether the observed CPU-GPU and inter-cluster signals actually come from SLC occupancy. The paper has independent support, including reverse-engineered SLC set indexing, latency thresholds, replacement-policy experiments, cross-device fingerprinting, and pixel/screen demonstrations. It is not internally inconsistent; the missing control is a correctness risk that can be addressed by reanalyzing hit counts or by adding a DRAM-traffic control. Because the concern is concrete and testable, while the rest of the evidence is substantial, I keep the reader's CONDITIONAL verdict rather than moving to REJECT. If the hit-count reanalysis shows no occupancy signal, the verdict should move toward rejection or major revision; if it confirms occupancy, the paper's central claim stands. The GPU-compression stability issue should still be addressed by restricting the abstract's generality, but it is secondary to the channel-level question.","tokens_in":20940,"tokens_out":8627,"duration_ms":91380,"concrete_test":"Re-run the Section 3.5 experiment and, for each profiling phase, classify each access by the paper's 160/300-tick thresholds to compute the SLC-hit count separately from total time. Plot SLC-hit count vs victim buffer size for intra-cluster, inter-cluster, and CPU-GPU. If the CPU-GPU and inter-cluster hit-count curves are flat or much weaker while total time still scales, the channel is dominated by DRAM/memory-controller contention, not SLC occupancy. For a stronger isolation, use a GPU victim workload whose DRAM traffic is constant but whose SLC allocation varies (e.g., same buffer size with and without GPU cache allocation hints), and confirm that the hit-count signal follows SLC allocation only.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The load-bearing link between the reverse engineering and the application attacks is the claim that the new channel tracks SLC occupancy. The validation in Section 3.5 (Figure 5) plots the spy's total profiling time against victim buffer size, not the number of SLC hits. Total profiling time depends on DRAM latency as well as cache occupancy: both the inter-cluster victim (e-core loads) and the GPU victim generate DRAM traffic whose volume grows with buffer size, and the spy's strided buffer misses to DRAM. Memory-controller or DRAM bank contention would therefore produce the same monotone curves even if the victim never touched the SLC. The paper does not report a control in which DRAM traffic is varied while SLC allocation is held fixed, nor a control in which SLC allocation is varied while DRAM traffic is held fixed. Since the central claim is specifically an exclusive-SLC occupancy channel, a bandwidth-dominated signal would reduce the contribution to a memory-contention side channel and would weaken the \"first SLC occupancy attack\" claim. The pixel and screen attacks would still be interesting, but they would no longer validate the SLC mechanism.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reverse-engineers the System-Level Cache (SLC) of Apple M-series SoCs and proposes an SLC-specific cache occupancy side channel. On an M1, the authors measure SLC hit latency, infer that the SLC is exclusive with respect to CPU caches and inclusive with respect to the GPU cache, map the set-index bits (excluding the low 13 bits), and observe pseudo-random replacement. To fill the SLC while bypassing the L2, they introduce an alternated-order access pattern and an 8-KB strided buffer. They evaluate the resulting channel against L2 and total-occupancy channels in intra-cluster, inter-cluster, and CPU-GPU scenarios. They then build three attacks: a closed-world website fingerprinting attack over 100 Alexa sites (87-92% accuracy in cross-cluster scenarios, compared with 33-38% for the prior L2 channel), a cross-origin pixel-stealing attack that distinguishes black and white pixels via GPU memory usage (92-94% on Chrome, 84-85% on Safari), and a screen-snooping attack that resolves 28 vertical screen bands (57 rows each) and applies them to ITF barcodes and printed digits. Finally, they propose cache-masking countermeasures with reported performance overheads below 10% in multi-core benchmarks.","tokens_in":21119,"tokens_out":10933,"duration_ms":102115,"significance":"If the central mechanism is correct, this is a significant contribution: it is the first occupancy side channel that specifically targets the exclusive SLC of Apple Silicon, and it extends occupancy attacks to inter-cluster and CPU-GPU scenarios that prior L2-based channels cannot reach. The paper has real strengths: attacks are evaluated on three SoCs and multiple browsers; the website fingerprinting uses a 100-site closed-world dataset with clean-environment controls; the pixel and screen attacks are demonstrated end-to-end; and the methodology is described in enough detail to reproduce the reverse engineering. The paper also appropriately compares against the previous L2 channel. However, the headline claims rest on two points that need strengthening: the SLC-occupancy interpretation of the measured signal is not separated from DRAM/memory-controller contention, and the screen-capturing attack is substantially more constrained than the abstract's \"retrieve any screen display\" language. With additional control experiments and more careful claims, the result would be a valuable advance for the cache-occupancy and heterogeneous-SoC security literature.","major_comments":[{"comment":"The validation of the SLC occupancy channel does not separate SLC occupancy from DRAM/memory-controller contention. The dependent variable is the spy's total profiling time while the victim buffer size grows; both the inter-cluster victim (e-core loads) and the GPU victim generate DRAM traffic that grows with buffer size, and the spy's strided buffer also misses to DRAM. A memory-bandwidth or memory-controller contention channel would yield the same monotone profiles even if the victim never allocated lines in the SLC. The paper needs controls, for example a victim workload that keeps DRAM traffic constant while varying SLC allocation, and a workload that varies DRAM traffic while holding SLC allocation fixed. Without these, the central claim of an exclusive-SLC occupancy channel (abstract and Section 3.5) is not yet established.","section":"Section 3.5, Figure 5"},{"comment":"The pixel-stealing and screen-capturing attacks depend on the empirical premise that GPU memory usage falls as zero-valued pixels increase, attributed without public documentation to GPU compression. The paper itself acknowledges in Section 6.1 that it is challenging to pinpoint the exact reason for this correlation. If the correlation is instead a consequence of DRAM traffic volume (for example, compressed data transfers fewer bytes), the attacks would still be interesting but would not validate the claimed SLC occupancy mechanism. A concrete test would be to render frames with identical GPU memory footprints but different data compressibility, and to check whether the SLC-hit-based metric, rather than total access time, tracks the difference.","section":"Section 6.1, Figure 9"},{"comment":"The abstract and introduction overstate the screen-capturing attack. The abstract says the adversary can \"retrieve any screen display,\" but Section 6.2 reports that the technique works only when more than 90% of the screen consists of large solid-color blocks (each exceeding 256 by 256 pixels), requires a completely still screen, and takes about five minutes per measurement. Section 6.3.2 and Table 5 further show Top-1 accuracy of 52.9% for two digits and 21.4% for three digits, with no ability to determine digit order. These constraints should be stated in the abstract and introduction, and the \"any screen display\" claim should be qualified to solid-color-dominated static screens under restrictive conditions.","section":"Abstract, Sections 6.2-6.3"}],"minor_comments":[{"comment":"The reported buffer sizes of 120,000 L2 lines, 300,000 SLC-saturation lines, and 80,000 SLC-buffer lines are not reconciled with the stated 8 MB SLC and 12 MB L2 capacities; with 128-byte lines these correspond to 15.36 MB, 38.4 MB, and 10.24 MB, respectively. Please clarify whether these are nominal capacities or include the effects of random replacement and prefetching.","section":"Section 3.5"},{"comment":"The 160-tick and 300-tick thresholds are calibrated on one M1 device; the paper does not report whether these thresholds were recalibrated on the M1 Pro and M3 Pro before applying the channel in Sections 4 and 5, so please state the calibration procedure per device.","section":"Section 3.2"},{"comment":"The website fingerprinting accuracies are reported as single numbers without confidence intervals or error bars; given the 90-10 cross-validation split, please report the variance across folds or repeated runs.","section":"Table 2"},{"comment":"For the pixel recognition accuracies, please state the number of pixels tested and whether accuracy is per-pixel across a single page or across repeated trials, since this affects the statistical strength of the 92-94% claims.","section":"Table 3"},{"comment":"The text describes pink as RGB (0,255,255), which is cyan; please correct the color naming in the figure caption or the text.","section":"Section 6.1, Figure 9d"},{"comment":"The single-frame trace with 28 epochs is presented without variability information; please include repeated-frame statistics or a representative confidence band to support the claimed stability of the flash-point pattern.","section":"Section 6.2, Figure 11"},{"comment":"Please clarify whether the 12 MB SLC masking scheme uses a single buffer or the new-buffer-per-iteration enhancement, since Figure 16a explicitly distinguishes the two cases for the L2 masking scheme.","section":"Section 7.1, Figure 16"}],"recommendation":"major_revision","confidential_remarks":"The main technical risk is the SLC-versus-DRAM confound in the channel validation; the proposed controls should be feasible within the scope of the paper and would substantially increase confidence in the mechanism. The authors should also temper the screen-capturing claims in the abstract, as the paper's own limitations in Sections 6.2 and 6.3.2 are more restrictive than the stated headline contribution. Finally, the novelty claim of being the first SLC occupancy attack should be checked carefully against the Cronin et al. discussion and any other Apple M-series SLC side-channel work in the recent literature."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe headline: this is a serious empirical paper that opens a new attack surface on Apple M-series SoCs, but the central mechanism claim is not as clean as the abstract suggests. The SLC occupancy channel may be partly, or even mostly, DRAM/memory-controller contention.\n\nWhat's genuinely new: reverse engineering of the M1 SLC—exclusive with respect to CPU caches, inclusive with respect to the GPU, set indexing that excludes the lowest 13 bits, pseudo-random replacement. The alternated-order access pattern to fix self-eviction is clever, and the stride-8192 buffer to fill the SLC while bypassing L2 is a nice trick. The cross-cluster and CPU-GPU demonstrations are the first of their kind for cache occupancy attacks, and the three applications—website fingerprinting, pixel stealing, screen snooping—are all substantial. The multi-device, multi-browser evaluation is a plus.\n\nNow the soft spots, in proportion. The big one: the validation in Figure 5 does not separate SLC occupancy from DRAM contention. Both the victim's buffer loads and the spy's strided buffer generate DRAM traffic, and the measured profiling time is sensitive to memory-controller contention. The paper needs a control where DRAM traffic is varied while SLC allocation is held fixed, or vice versa. Without that, the claims \"first SLC occupancy attack\" and \"monitors SLC occupancy\" are not fully supported. Some of the reverse engineering is indirect too—inferred from timing experiments without ground truth. The pixel attack's threshold is selected post hoc, and the screen attack excludes the first epoch with a hand-waved justification. No code or artifacts are released, which makes independent verification harder. The abstract overstates generality: the screen attack works only on still, mostly solid-color displays, takes about five minutes, and degrades fast with multi-digit content.\n\nThese are fixable. The attacks themselves are plausible and the results are internally consistent. Even if the channel turns out to be memory contention rather than SLC occupancy, the cross-component monitoring capability is a real finding. I'd want a serious referee to push for the control experiments and a rewritten abstract. Worth a reading group slot.","headline":"Solid empirical first cut at an exclusive-SLC occupancy channel on Apple M-series, but the validation doesn't fully rule out DRAM contention as the real carrier.","tokens_in":21653,"tokens_out":3110,"would_cite":true,"duration_ms":28381,"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":"The paper claims that Apple's exclusive System-Level Cache can be coerced into an occupancy side-channel that lets an attacker on one CPU cluster observe GPU and remote-cluster activity, enabling website fingerprinting, cross-origin pixel…","keywords":["cache occupancy attack","System-Level Cache","Apple M-series SoCs","GPU side channel","website fingerprinting","pixel stealing","screen capturing","exclusive cache"],"falsifier":"Run the paper's slide experiment—alternating solid black and solid white full-screen frames while measuring evicted SLC lines during rendering—on the same M1 machine before and after a macOS or GPU-driver update; if GPU memory usage no longer tracks the zero-pixel count, the screen-capturing and pixel-stealing attacks fail on that platform.","tokens_in":20725,"feed_emoji":"👁️","tokens_out":6161,"duration_ms":54935,"temperature":0.7,"pith_summary":"The paper tries to establish that Apple's System-Level Cache, despite being exclusive to CPU caches, can be turned into a usable occupancy side-channel: an attacker's JavaScript or native process on one CPU cluster can infer what the GPU and other CPU clusters are doing by timing evictions from the shared SLC. The authors reverse-engineer the M1 SLC (128-byte lines, hybrid inclusive/exclusive policy, set-index bits above bit 13, pseudo-random replacement) and design an access pattern that fills the SLC while bypassing L2. If the channel works as claimed, a background web page can identify which website the user visits, steal individual pixels from a cross-origin iframe, and even recover on-screen digits or barcodes at 57-row granularity. This matters because it expands cache-occupancy attacks out of the same-core, same-cluster setting into cross-cluster and CPU-GPU settings on Apple's heterogeneous chips.","feed_headline":"Web scripts can read your screen through Apple's shared system cache","feed_subtitle":"A cache-occupancy side channel lets web scripts identify sites, steal pixels, and read 57-row strips of the display.","key_machinery":"The central object is the SLC occupancy channel, a prime-reload-style profiling loop in which the spy repeatedly steps through a buffer that fills the SLC but bypasses the L2. It is made to work by two mechanisms: the alternated-order access pattern (each profiling round runs the buffer in the opposite direction, stopping LRU self-eviction) and the stride-8192 data structure (contiguous virtual addresses with fixed low 13 bits, so the L2 sees only a small set of its index bits while the SLC, which indexes from bit 14 upward, sees the whole buffer). For the screen attack, a dual-set prime-and-reload with two staggered primes produces a short observation window; differences in evicted-line counts between the two reloads isolate GPU memory activity within a roughly 0.4 ms slice of a 16.7 ms frame.","core_discovery":"On Apple M-series chips the System-Level Cache is not a smaller mirror of the CPU caches: it is exclusive with respect to the CPU's L1/L2 and inclusive with respect to the GPU's cache. That exclusiveness means an ordinary occupancy buffer never fills the SLC, because warm data stays in L2. The paper's discovery is a way around this: by exploiting the different set-indexing of L2 and SLC, a buffer accessed with 8 KB stride occupies the SLC while using only about 1/64 of L2, and by alternating the traversal direction between profiling rounds the spy avoids self-eviction artifacts. The resulting SLC occupancy channel tracks victim memory traffic linearly, in intra-cluster, inter-cluster, and CPU-GPU settings, and it is sensitive enough to detect GPU memory-usage differences tied to the number of zero-valued pixels in a rendered frame. From that sensitivity the paper builds website fingerprinting, pixel stealing, and screen-capturing attacks, plus a stride-based SLC masking countermeasure.","pith_inferences":["I infer (beyond the paper): the same stride-based SLC-filling trick should transfer to other heterogeneous SoCs whose last-level cache is exclusive and whose set-indexing can be discovered, so the threat is not unique to Apple.","I infer: the zero-pixel-to-GPU-memory correlation is strong evidence of hardware frame-buffer compression; the paper leaves the exact mechanism undocumented, but if compression is what drives the signal, the channel might also distinguish large solid-color regions by color channel rather than only by zero count.","I infer: the paper's SLC masking and L2 masking are complementary rather than alternatives; an OS-level defense would likely need both, and their performance costs would combine.","I infer: the screen-capturing attack's practical reach is bounded by its own stated conditions—still displays, mostly solid-color content, and roughly five-minute capture—so the realistic near-term targets are codes, passwords, and verification digits, not general pixel-level screen content."],"forward_implications":["Website fingerprinting: an attacker can identify which of 100 top websites a user visits with roughly 87–92% accuracy even when spy and victim browsers are assigned to different CPU clusters, where the prior L2 occupancy channel drops to about 33–38%.","Pixel stealing: an attacker can distinguish black from white pixels in a cross-origin iframe with 84–94% accuracy at about 2 seconds per pixel in Chrome, and the attack works despite constant-time SVG filter implementations and the CVE-2023-38599 fix.","Screen capturing: the channel can recover ITF barcode digits with about 90% accuracy when narrow bars are at least 20 pixels tall, and single Arabic digits with about 91% accuracy, using 57-row vertical granularity on a 1600-row screen.","The countermeasure: a stride-based SLC masking buffer of at least 12 MB suppresses the SLC occupancy channel, with under 5% single-core and under 10% multi-core performance overhead in the paper's Geekbench measurements.","The SLC channel works in intra-cluster, inter-cluster, and CPU-GPU scenarios, whereas the prior L2 occupancy channel only works in the intra-cluster setting."],"supporting_citations":[{"why":"Supplies the cache-occupancy attack baseline and data structure that the paper adapts and fixes for the exclusive SLC.","marker":"[21]"},{"why":"Provides the prior L2 cache occupancy attack on Apple M1 that serves as the main comparison and fails in inter-cluster scenarios.","marker":"[20]"},{"why":"Establishes prior exploration of ARM System-Level Cache and GPU side channels that the paper extends by reverse-engineering the SLC structure and policies.","marker":"[6]"},{"why":"Introduces the GPU compression side-channel baseline for pixel stealing that the paper replaces with an SLC occupancy measurement on Apple hardware.","marker":"[25]"},{"why":"Documents the CVE-2023-38599 mitigation that the pixel-stealing attack is shown to remain effective against.","marker":"[15]"},{"why":"Supplies the discovery of Apple M1 L2 cache set-indexing that motivates the stride-8192 buffer design for bypassing L2 and filling the SLC.","marker":"[29]"},{"why":"Provides the eviction-set technique used to quantify SLC hit latency and distinguish SLC hits from misses.","marker":"[24]"}],"fun_headline_variants":["Apple M-series cache leak exposes screen to web scripts","New cache attack reads pixels via Apple's System-Level Cache","GPU cache side channel steals screen data on Apple M1","Exclusive SLC cache turned into pixel-stealing side channel","Web pages can capture your Apple screen via cache occupancy"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The screen and pixel attacks rest on the undocumented empirical link between how many zero-valued pixels a frame has and how much GPU memory it uses; if a macOS update, GPU driver, or newer M-series chip changes or removes that link, those attacks lose their signal.","fun_headline_variants_meta":{"raw":{"variants":["Apple M-series cache leak exposes screen to web scripts","New cache attack reads pixels via Apple's System-Level Cache","GPU cache side channel steals screen data on Apple M1","Exclusive SLC cache turned into pixel-stealing side channel","Web pages can capture your Apple screen via cache occupancy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000222,"raw_usage":{"total_tokens":1515,"prompt_tokens":1068,"completion_tokens":447,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":684,"completion_tokens_details":{"reasoning_tokens":367}},"tokens_in":684,"tokens_out":447,"duration_ms":3793,"temperature":1.0,"reasoning_tokens":367,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T12:09:28.833673+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's slide experiment—alternating solid black and solid white full-screen frames while measuring evicted SLC lines during rendering—on the same M1 machine before and after a macOS or GPU-driver update; if GPU memory usage no longer tracks the zero-pixel count, the screen-capturing and pixel-stealing attacks fail on that platform.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the cache-occupancy attack baseline and data structure that the paper adapts and fixes for the exclusive SLC."},{"cited_title":"2021.{Prime+ Probe} 1,{JavaScript} 0: Overcoming Browser- based{Side-Channel} Defenses","cited_arxiv_id":null,"evidence_quote":"Provides the prior L2 cache occupancy attack on Apple M1 that serves as the main comparison and fails in inter-cluster scenarios."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes prior exploration of ARM System-Level Cache and GPU side channels that the paper extends by reverse-engineering the SLC structure and policies."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the GPU compression side-channel baseline for pixel stealing that the paper replaces with an SLC occupancy measurement on Apple hardware."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the CVE-2023-38599 mitigation that the pixel-stealing attack is shown to remain effective against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the discovery of Apple M1 L2 cache set-indexing that motivates the stride-8192 buffer design for bypassing L2 and filling the SLC."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the eviction-set technique used to quantify SLC hit latency and distinguish SLC hits from misses."}],"review_version":1}