{"id":"0bac249f-1fc6-4cdd-b77a-62f122194825","arxiv_id":"2509.00300","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"ShadowScope detects GPU kernel attacks by segmenting kernel execution with marker functions and comparing PMU traces against pre-collected golden references, achieving up to 100% detection in its experiments.","lead":"ShadowScope monitors GPU kernels by comparing performance-counter traces against a composable golden model built from trusted execution. It reports high detection rates for four representative GPU attacks, with a simulated hardware version adding 4.6% average overhead.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Evasion class not analyzed: a control-flow attacker can shape or spoof the PMU/marker trace, and the 0.8/four-rejection rule is validated only against non-adaptive attacks.","rationale":"The reader's weakest_assumption—that an attacker can preserve the PMU signature—is the right locus for the central concern. I add two concrete mechanisms from the paper's own design that make this evasion class concrete and arguably more serious: the four-consecutive-rejection rule in §3.6 permits short-window deviations, and the global_atom_cas composable marker (Listing 1, §3.3) is attacker-influenceable because atomic operations are within the attacker's capability under §3.1. The paper provides no adversarial evaluation, no sensitivity analysis for the 0.8 threshold, and no discussion of an attacker who shapes the trace rather than simply executing a different program. This does not invalidate the software demonstrations for the four non-adaptive attacks, but it does mean the strong 'practical defense' conclusion is conditional. Since the reader already issued CONDITIONAL, no verdict adjustment is needed; the concrete test would determine whether the concern lands and whether the condition can be lifted.","tokens_in":20058,"tokens_out":9493,"duration_ms":126074,"concrete_test":"On the V100/CUPTI setup, implement an adaptive variant of the mind-control/buffer-overflow attack: after hijacking the kernel, run the malicious payload, then pad the remaining execution with dummy global loads/stores/ALU instructions so that each per-window count of the four §4.3.1 events stays within the golden correlation envelope, and insert an extra global atomicCAS near the expected layer boundary to re-align segmentation. Run the existing ShadowScope validator over 100 attack and 100 benign traces and measure TPR/FPR. If TPR falls materially below the reported ~95% average (or FPR rises sharply), the evasion concern is confirmed; if TPR remains near 100%, the defense is more robust than the paper's evaluation shows.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.6's decision rule—cross-correlation >0.8 plus four consecutive rejections—is evaluated only against four attacks with large, sustained PMU footprints (skipped layers, redirected control flow, DRAM hammering, RFM slowdown). The central 'practical defense' claim requires that any kernel integrity violation produce the same type of signature, but an attacker with the §3.1 capability (arbitrary kernel control flow) can shape the per-window counts of the selected events (inst_executed, global_load/store, global_atom_cas in §4.3.1) by padding with dummy instructions or memory operations, or can confine malicious activity to fewer than four contiguous sampling windows so the rejection rule never trips. Additionally, the composable markers themselves are global_atom_cas events (Listing 1, §3.3), so an in-kernel attacker can emit fake atomic CAS operations to manipulate segment boundaries before validation. None of these evasions is analyzed or tested, so the claim that side-channel observability is a practical integrity defense is not yet established against an adversary who optimizes for the detector.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes ShadowScope, a GPU kernel-integrity validation framework that repurposes side-channel signals (PMU event counts) into a composable golden model. The key idea is to instrument trusted kernels with lightweight marker functions at kernel boundaries so that traces can be segmented and validated independently, reducing noise and alignment problems. The software implementation is evaluated on NVIDIA Tesla V100 and RTX 4060 against four attacks: buffer overflow, mind-control, Rowhammer, and DoS/RFM slowdown, reporting high TPR and low FPR. A hardware extension, ShadowScope+, adds per-SM PMUs and an on-chip validator, evaluated in GPGPU-Sim on a 15-SM Fermi-like configuration, with a claimed 4.6% overhead and small area/power cost. The central claim is that side-channel observability can be systematically repurposed into a practical defense for GPU kernel integrity.","tokens_in":20368,"tokens_out":4976,"duration_ms":65577,"significance":"If the claims are established, the composable-golden-model approach would be a useful step toward practical GPU kernel validation: it addresses real problems of trace misalignment and workload variability, and the hardware design is plausibly lightweight. The paper's strengths include real-NVIDIA experiments against four representative attacks, a concrete segmentation mechanism, and a hardware proposal with area/power estimates. However, the current evidence does not yet support the 'practical defense' framing, because the decision rules are hand-tuned and evaluated in-sample, the adversarial model does not include an attacker who adapts to the detector, and the hardware evaluation reports similarity scores rather than detection accuracy. The paper is a reasonable systems/security contribution, but the load-bearing claims need additional validation.","major_comments":[{"comment":"The detection thresholds are hand-tuned constants and all accuracy numbers are in-sample. The 0.8 cross-correlation threshold and the four-consecutive-rejection rule are stated without derivation, cross-validation, or confidence intervals. The golden and 'normal' datasets are collected from the same benign distribution (100 traces each), so the reported TPR/FPR are calibration-set measurements, not out-of-sample estimates. This matters because the central 'practical defense' claim depends on the decision rule's generality across workloads and conditions.","section":"§3.6 and §4.3"},{"comment":"The threat model grants the attacker arbitrary kernel control flow, but the evaluation considers only non-adaptive attacks with large, sustained PMU footprints. An attacker with this capability can pad malicious code with the same instruction mix as the expected kernel to keep cross-correlation above 0.8, confine malicious activity to fewer than four contiguous sampling windows, or emit fake global_atom_cas operations (the marker event in Listing 1) to forge segment boundaries. None of these evasions is analyzed. Since the abstract claims a practical defense, the absence of an adaptive-adversary analysis is load-bearing.","section":"§3.1, §3.3, §3.6"},{"comment":"The ShadowScope+ 'high validation accuracy' is not actually measured. Table 4 reports normalized DTW similarity scores between benign and attack traces for four benchmarks, but there is no benign-vs-benign baseline, no pre-specified decision threshold, no TPR/FPR, and no number of traces; the statement that a score 'typically below 0.1 suggests low similarity' is an observation, not an evaluation rule. The simulator is also a 15-SM Fermi-like configuration (Table 3), so the hardware results do not yet support claims about modern GPUs.","section":"§5.4.1 and Table 4"},{"comment":"The noise-robustness experiment reports normalized DTW similarity only, not TPR/FPR under interference. Figure 10 shows similarity dropping to 0.8970 under VecAdd noise, but the paper does not map this value to the 0.8 cross-correlation threshold or to the four-rejection rule. It is therefore unclear whether the system's false-positive rate remains low under the stated interference, and the claim that the method is 'robust to noise' is not supported by detection metrics.","section":"§4.4"}],"minor_comments":[{"comment":"The claim of the 'first defense framework that leverages GPU side-channel signals to validate execution' is too strong given prior attestation work using side channels (e.g., EMMA [62], EDDIE [44]) and GPU attestation (SAGE [20]). The novelty should be framed around composability and GPU-specific challenges rather than firstness.","section":"§1 and Abstract"},{"comment":"The abstract says 'low false positive rates' but Attack 1 averages 9% FPR, with sortingNetworks at 25%. The conditions under which FPR becomes high (low PMU sampling rate) should be stated in the abstract or conclusions to avoid overgeneralization.","section":"§4.3.1"},{"comment":"The 'correlation coefficient' is not formally defined. State whether it is Pearson correlation, normalized cross-correlation, or another metric, and give the formula used for traces of unequal length.","section":"§3.6"},{"comment":"The composable function's atomicCAS pattern is not a correct atomic increment under concurrency ('old_val = atomicCounter; new_val = old_val+1; atomicCAS(...)'). If the intent is just a marker, clarify the semantics or use atomicAdd; otherwise the marker itself may behave nondeterministically.","section":"Listing 1, §3.3"},{"comment":"For vecAdd the standard deviation is reported as 0 because it 'contains only a single executed kernel.' This does not explain why the score is constant across repeated traces; clarify how many runs were used and what the standard deviation is computed over.","section":"Table 4"},{"comment":"No artifact or detailed simulation scripts are provided, and the simulator implementation of the hardware PMU/validator and of the two attacks is not described. Providing code or pseudocode would significantly improve reproducibility.","section":"§5.4.1 and §5.4.3"}],"recommendation":"major_revision","confidential_remarks":"The paper has a solid experimental core for detecting non-adaptive attacks in software, and the composable-golden-model idea is promising. However, the framing as a practical defense against an attacker with arbitrary kernel control flow is not supported without an evasion analysis and a proper validation of the hand-tuned thresholds. The hardware contribution, while plausible, currently lacks a measured detection-accuracy result. I would encourage the editor to request a revision that adds adaptive-attacker experiments, out-of-sample threshold selection, and a decision rule for ShadowScope+."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The genuinely new piece is the segmentation idea: instrument kernels with atomic-CAS markers to carve execution into segments and validate each segment against a per-segment golden model built from PMU event counts. That is a sensible answer to the noise and alignment problems that make monolithic golden models on GPUs fragile. The software evaluation on real V100 and RTX 4060 hardware shows the approach detects four concrete attacks (buffer overflow, mind control, rowhammer, RFM slowdown) with mostly high TPR and low FPR. That is real evidence, not a toy.\n\nThe soft spots are real, though. The detector uses two hand-set constants—cross-correlation above 0.8 and four consecutive rejections—and the evaluation is entirely against non-adaptive attacks that produce large, sustained PMU footprints. The stress-test concern lands: an attacker who controls kernel control flow (which the paper assumes) can pad with dummy instruction mixes, confine malicious activity to fewer than four sampling windows, or emit fake atomic-CAS markers to manipulate segment boundaries. None of that is analyzed or tested, so the \"practical defense\" claim is stronger than the evidence. The reader's point about calibration is also fair: the 0.8 and four-rejection thresholds are tuned constants, not derived or cross-validated, and the reported TPR/FPR are in-sample. There are no confidence intervals, only 100 traces per dataset, and no baseline comparison to earlier golden-model work. The hardware evaluation is a simulator on a 15-SM Fermi-like configuration; fine for proof-of-concept, but the 4.6% overhead figure is a simulation number.\n\nTo give credit where it is due: the paper is honest about several limitations, especially Section 4.5 on existing PMU weaknesses, and the related-work coverage is fair. The central idea is credible and the real-GPU data is worth taking seriously. What the paper needs is an explicit treatment of adaptive evasions, variance reporting, out-of-sample threshold selection, and ideally code/data release.\n\nThis deserves a serious referee. I would send it to peer review with a revise-and-resubmit leaning: the core contribution is novel enough and the empirical grounding is solid enough that the effort is justified, but the threat model and evaluation methodology need real work before it can be accepted. I'd bring it to a reading group if you want a good discussion about what \"practical\" means for side-channel defenses.","headline":"A credible composable-golden-model idea on real GPUs, but the threat model stops short of an adaptive attacker; worth refereeing with major revisions.","tokens_in":20858,"tokens_out":1540,"would_cite":true,"duration_ms":19192,"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 GPU kernel integrity can be defended by turning side-channel signals—normally a leakage risk—into a composable golden-model validation system.","keywords":["GPU security","kernel integrity","side-channel signals","golden model validation","performance counters","hardware monitoring","rowhammer detection","DNN attacks"],"falsifier":"Build an attack that skips a DNN layer or redirects control flow while padding the payload to execute the same mix of instructions, global loads and stores, and atomic markers as the benign kernel, then run ShadowScope's validation; if the padded trace stays above the 0.8 correlation threshold across four consecutive windows, the central claim is refuted.","tokens_in":19992,"feed_emoji":"🛡️","tokens_out":6987,"duration_ms":73630,"temperature":0.7,"pith_summary":"The paper argues that the same side-channel signals that leak GPU secrets can be turned into a defense: a GPU kernel's runtime behavior leaves traces in performance-counter events, and those traces can be compared against a trusted reference to catch tampering. Because a single monolithic reference is too brittle for noisy, parallel GPU execution, the paper proposes a composable golden model that splits execution into modular segments, each validated independently against its own reference. The authors show, on commercial GPUs, that this scheme detects buffer-overflow control-flow hijacking, DNN layer-skipping 'mind control' attacks, rowhammer, and DRAM slowdown/DoS attacks with up to 100% true positive rates and low false positives. They then design a small hardware extension that moves monitoring on-chip and report an average runtime overhead of 4.6%, arguing this makes side-channel-based validation practical enough to deploy.","feed_headline":"Side-channel leaks become a GPU tamper alarm","feed_subtitle":"Composable golden models catch layer-skip, rowhammer, and hijacked control flow at up to 100% true positives.","key_machinery":"The composable golden reference model. Rather than compare one long, noisy trace against a single reference, execution is segmented by composable functions inserted at kernel boundaries—small atomic compare-and-swap kernels that emit detectable spikes in the global_atom_cas counter and can carry kernel and input metadata. The verifier uses these markers to align each segment with the right reference trace and validates segments independently; a match requires cross-correlation above 0.8 and tolerates up to three consecutive mismatches before flagging. ShadowScope+ replaces software sampling with per-SM event counters and an on-chip validator that aggregates samples by timestamp and compares","core_discovery":"The central claim is that side-channel observability can be systematically repurposed into a practical defense for GPU kernel integrity. Instead of building one monolithic golden model of a whole application, ShadowScope decomposes trusted execution into modular, repeatable segments demarcated by lightweight atomic-marker functions; each segment is validated independently against reference traces, and a kernel is flagged only when several consecutive segments fail correlation. In software form on commercial GPUs, this catches four representative attack classes with up to 100% true positive rates. The companion hardware design, ShadowScope+, moves validation into the GPU by adding per-SM even","pith_inferences":["The marker mechanism itself could become an attack surface: if an attacker can forge, suppress, or mimic the atomic-marker functions, the verifier's segmentation and golden-model selection are compromised—an issue the paper's trusted-PMU assumption leaves open.","An evasion class the paper does not analyze is a payload that preserves the benign event signature by running the same instruction mix, memory operations, and atomics as the skipped or redirected code; a natural next test is whether such padded payloads stay above the 0.8 correlation threshold across four consecutive windows.","Because validation uses fixed thresholds (0.8 correlation, four consecutive rejections), detection latency and false-alarm tolerance are tunable parameters; future work could derive these thresholds automatically from distributions of benign and attack traces rather than hand-tuning them.","The same composable-marker idea could transfer to other accelerators with periodic, kernel-like execution units, where per-unit performance-counter signals are available, extending the defense beyond GPU-specific attacks."],"forward_implications":["Validation becomes localizable: because each kernel or layer segment is checked against its own reference, a detected attack can be pinned to the specific compromised segment rather than just flagged at the application level.","Segmentation plus marker-based alignment absorbs scheduling noise and concurrent-workload interference, so golden models can be reused across input sizes and configurations instead of being rebuilt per run.","Moving validation on-chip removes the sampling-rate, event-grouping, and profiling-overhead bottlenecks of software profiling, which is why fast kernels that produce few samples become detectable in the hardware instantiation.","The measured 4.6% average overhead and sub-percent area and power costs position hardware-assisted side-channel validation as a practical, low-cost defense layer for GPU acceleration."],"supporting_citations":[{"why":"Supplies the cross-correlation validation method ShadowScope adapts and the side-channel attestation precedent.","marker":"[62]"},{"why":"Defines the GPU buffer-overflow and code-injection attack class that Attack 1 must detect.","marker":"[15]"},{"why":"Demonstrates CUDA buffer-overflow vulnerabilities, grounding the control-flow hijacking scenario.","marker":"[36]"},{"why":"Defines the mind-control DNN layer-skipping attack evaluated as Attack 2.","marker":"[55]"},{"why":"Shows rowhammer-induced bit flips degrade DNN weights, motivating Attack 3's target.","marker":"[69]"},{"why":"Documents the CUPTI profiling interface used for side-channel data collection in the software instantiation.","marker":"[47]"},{"why":"Defines the PMU events, including global_atom_cas, used for markers and golden traces.","marker":"[50]"},{"why":"Provides the cycle-accurate GPU simulator used to evaluate ShadowScope+.","marker":"[24]"},{"why":"Shows GPU performance counters leak information, the threat that motivates hardware-assisted monitoring.","marker":"[40]"}],"fun_headline_variants":["ShadowScope: composable side-channel checks catch GPU attacks","GPU tamper detection via modular golden models","Hardware-assisted GPU validation at just 4.6% overhead","Side-channel observability repurposed as a GPU defense","ShadowScope catches GPU attacks with up to 100% true positives"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The defense assumes any real attack changes the selected performance-counter traces enough to push cross-correlation below 0.8 for at least four consecutive validation windows, and that an attacker cannot craft a payload that preserves the benign event signature.","fun_headline_variants_meta":{"raw":{"variants":["ShadowScope: composable side-channel checks catch GPU attacks","GPU tamper detection via modular golden models","Hardware-assisted GPU validation at just 4.6% overhead","Side-channel observability repurposed as a GPU defense","ShadowScope catches GPU attacks with up to 100% true positives"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000611,"raw_usage":{"total_tokens":2688,"prompt_tokens":761,"completion_tokens":1927,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":505,"completion_tokens_details":{"reasoning_tokens":1859}},"tokens_in":505,"tokens_out":1927,"duration_ms":20935,"temperature":1.0,"reasoning_tokens":1859,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T13:44:20.084753+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Build an attack that skips a DNN layer or redirects control flow while padding the payload to execute the same mix of instructions, global loads and stores, and atomic markers as the benign kernel, then run ShadowScope's validation; if the padded trace stays above the 0.8 correlation threshold across four consecutive windows, the central claim is refuted.","supporting_citations":[{"cited_title":"Emma: Hardware/software attestation framework for embedded systems using electromagnetic signals","cited_arxiv_id":null,"evidence_quote":"Supplies the cross-correlation validation method ShadowScope adapts and the side-channel attestation precedent."},{"cited_title":"GPU Memory Exploitation for Fun and Profit","cited_arxiv_id":null,"evidence_quote":"Defines the GPU buffer-overflow and code-injection attack class that Attack 1 must detect."},{"cited_title":"Buffer overflow vulnerabilities in cuda: a preliminary analysis","cited_arxiv_id":null,"evidence_quote":"Demonstrates CUDA buffer-overflow vulnerabilities, grounding the control-flow hijacking scenario."},{"cited_title":"In 29th USENIX Security Symposium (USENIX Security 20) , pages 1463–1480, 2020","cited_arxiv_id":null,"evidence_quote":"Shows rowhammer-induced bit flips degrade DNN weights, motivating Attack 3's target."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the CUPTI profiling interface used for side-channel data collection in the software instantiation."},{"cited_title":"CUPTI: User Guide","cited_arxiv_id":null,"evidence_quote":"Defines the PMU events, including global_atom_cas, used for markers and golden traces."},{"cited_title":"Accel-sim: An extensible simulation framework for validated gpu modeling","cited_arxiv_id":null,"evidence_quote":"Provides the cycle-accurate GPU simulator used to evaluate ShadowScope+."},{"cited_title":"Rendered insecure: Gpu side channel attacks are practical","cited_arxiv_id":null,"evidence_quote":"Shows GPU performance counters leak information, the threat that motivates hardware-assisted monitoring."}],"review_version":1}