{"id":"b38e2bf8-7bd6-46f2-9926-ee6bcfe7d38d","arxiv_id":"2507.06112","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Disabling a small set of optimization passes in GCC and LLVM removes the constant-time violations those compilers introduce, at modest average performance cost.","lead":"The authors analyzed which GCC and LLVM compiler optimizations reintroduce secret-dependent branches and memory accesses in constant-time cryptographic code, and showed that disabling a few selected passes removes these leaks. The work offers developers a practical flag-based defense against compiler-introduced timing side channels without changing source code or using a custom compiler.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 'removes all' claim is not established: the same dynamic tool with 16 random secrets is used before and after mitigation, and its known false negatives leave undetected compiler-introduced violations possible in the mitigated binaries.","rationale":"The reader's conditional verdict is appropriate. The paper's practical contribution—identifying specific passes and flag-based mitigation—is useful and supported by coherent experiments, with a public artifact and explicit benchmark scoping in Section VI-E. However, the headline 'removes all compiler-introduced vulnerabilities' hinges on the completeness of Microwalk's detection, which the paper itself acknowledges to be incomplete. Disabling the flagged passes is guaranteed to fix the observed leaks, but whether it removes all actual leaks in the benchmark is unknown because the same detector with the same 16 secrets is used for the post-mitigation check. The proposed test using Binsec/Rel (sound at binary level) and a much larger secret set would directly settle this. If hidden leaks are found, the paper's claim should be weakened to 'removes all observed violations' and the practical guidance should be tempered accordingly. If no hidden leaks are found, the concern is resolved and the conditional acceptance can move toward acceptance. The performance overhead reporting, while hiding large per-benchmark regressions, is a secondary issue compared to the security claim. Overall, the reader's CONDITIONAL verdict stands.","tokens_in":15912,"tokens_out":7741,"duration_ms":81153,"concrete_test":"Compile the toy benchmarks (jump threading, loop unswitching, path splitting, poly_frommsg) and the RSA-bearssl and ECDSA-bearssl CT functions with Clang 18 and GCC 13 at O3 plus the proposed mitigation flags, then run Binsec/Rel, a sound binary-level constant-time analyzer, on each binary. Independently, rerun Microwalk with 1,000 random secret inputs per binary instead of 16. If either analysis finds a secret-dependent branch or memory access in any mitigated binary, the 'removes all' claim is falsified; if both find none, the claim is supported for these cases.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim (Section V-A, Conclusion) is that disabling the identified passes removes all compiler-introduced constant-time violations in the CT benchmark. This is validated solely by rerunning Microwalk with the same 16 random secrets used in the initial detection (Section III-C). The authors themselves note in Section III-B that Microwalk 'can miss leakages not covered by the traces' and that some vulnerabilities can obscure others, leading to false negatives. Therefore, the absence of reported violations after mitigation does not imply the absence of actual violations; the 'all' claim is bounded by Microwalk's trace coverage. The manual confirmation in Section III-C was performed only on the initially detected leaks, not on the mitigated binaries' freedom from additional hidden leaks. A sound static analysis or substantially expanded dynamic testing is required to support the 'all' claim. This concern is independent of, and compounds, the in-sample overfitting issue: even if the pass set fixes the observed leaks, unobserved ones may remain.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies how compiler optimizations in GCC and LLVM introduce constant-time (CT) violations into cryptographic code. It constructs a dataset of compiler-introduced violations by compiling CT benchmarks with older and newer compiler versions and comparing vulnerable source lines reported by the dynamic analysis tool Microwalk. Using Compiler Explorer toggling and manual inspection, the authors attribute the observed violations to a small set of passes: loop unswitching, loop vectorization, and cmov conversion in LLVM; and jump threading, path splitting, and loop unswitching in GCC. They propose disabling these passes via compiler flags and evaluate the mitigation on the same benchmark, reporting that all compiler-introduced violations are removed with low average performance overhead. The paper also discusses related work, recommendations, and limitations.","tokens_in":16083,"tokens_out":5181,"duration_ms":58636,"significance":"If the pass-level attribution is correct, the paper offers immediately actionable guidance for hardening real cryptographic builds without source changes or compiler forks. The analysis of pass interactions, especially the LLVM pipeline interactions and the GCC if-conversion miss, is a valuable refinement over version-level comparisons. The artifact is provided, and the evaluation covers two major compilers. However, the central claims—that the proposed flag set removes 'all' compiler-introduced violations and that the performance cost is 'negligible'—are currently under-supported because the validation is in-sample and rests on a dynamic detector with known false negatives. The paper would be a solid contribution if these claims were scoped to the observed benchmark or backed by out-of-sample validation.","major_comments":[{"comment":"The central claim that disabling the identified passes 'removes all compiler-introduced vulnerabilities in known constant-time implementations' is validated only by re-running Microwalk on the same benchmark that was used to identify the pass set. Because the flag set is derived from the vulnerabilities observed in this benchmark (Section IV), the before/after comparison largely restates the selection criterion. Section VI-E already concedes that 'there may exist other passes or interactions that introduce vulnerabilities but were not observed in our current benchmarks,' so the 'all' formulation should be scoped to observed violations, or the authors should add an out-of-sample validation (e.g., a held-out CT benchmark or a sound static analysis of the mitigated binaries). Without that, the headline conclusion overstates the evidence.","section":"Section V-A, Table III; Section VII Conclusion"},{"comment":"The evaluation relies entirely on Microwalk with 16 random secret inputs, a dynamic detector whose false negatives the authors explicitly acknowledge: 'Microwalk can miss leakages not covered by the traces' and some vulnerabilities can 'obscure' others. The absence of reported violations in the mitigated binaries therefore does not establish the absence of actual compiler-introduced violations. This concern is independent of the in-sample selection issue and compounds it: the same limited detector is used both to find the leaks and to certify their removal. To support an 'all violations removed' claim, the authors should either use a substantially larger secret-input corpus, adopt a complementary sound static analysis on the mitigated binaries, or explicitly rephrase the claim as 'no violations detected by our setup.'","section":"Section III-B, III-C, and V-A"},{"comment":"The conclusion that performance overhead is 'negligible' is not supported by the full-mitigation numbers. For LLVM without vectorization, Table IV reports per-benchmark degradations of -16.52% for ChaCha20 (ct), -11.97% for ECDSA, and -9.77% for GHASH, with a BearSSL mean of -3.30% and SD=8.22. A mean close to zero with large variance is not a negligible impact for cryptographic primitives where every percent matters. The paper should report and discuss these outliers, and the abstract and conclusion should be qualified accordingly (e.g., 'low average overhead' with the caveat of important per-benchmark exceptions).","section":"Section V-B, Table IV"}],"minor_comments":[{"comment":"The text 'GGC does not internally represent conditional moves so easily' contains a typo: 'GGC' should be 'GCC.'","section":"Section IV-B"},{"comment":"The sentence reporting MbedTLS results reads 'with and with vectorization respectively'; this should be 'with and without vectorization respectively.'","section":"Section V-B"},{"comment":"The phrase 'answering the first part of of RQ3' contains a doubled 'of' and should be corrected.","section":"Section V-A"},{"comment":"The novelty statement 'we are also the first to characterize how the interactions between these passes contribute to leakage' should be tempered or more precisely dated, given the concurrent work cited as [27] and [51]; at minimum, specify exactly which interaction-level results are new.","section":"Abstract and Section I"},{"comment":"The diagram in Figure 2 would be much easier to interpret with a caption explaining the two pathways and the meaning of the labels 'IR select,' 'GIMPLE if,' 'cmov,' and 'jmp'; currently the figure is cryptic without the surrounding text.","section":"Figure 2"},{"comment":"The sentence 'The anonymized artifact can be found at here:' needs a grammatical fix, e.g., 'can be found here:'.","section":"Section III-B"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope for a security venue and the artifact is a useful addition. The main risk is overclaiming: the 'all violations removed' statement in the abstract and conclusion needs to be scoped to the benchmark and the detection setup, or supported by out-of-sample and/or static validation. The performance conclusion also needs to acknowledge the large per-benchmark slowdowns when vectorization is disabled. The authors should also carefully position their novelty claim against concurrent works (e.g., [27], [51]) to avoid an unnecessary priority dispute."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth a read. This is the first paper I've seen that names specific LLVM and GCC passes responsible for compiler-introduced constant-time violations and shows how combinations of passes interact to reintroduce branches. The case studies are careful: they trace a BearSSL RSA snippet through InstCombine turning bit-mask arithmetic into select, then loop unswitching hoisting the select out of the inner loop, then vectorization lowering selects to branches in the vectorized body, and finally the x86 cmov converter turning the remaining select into a secret-dependent jump. The Compiler Explorer toggling experiments back these attributions. That is real work and it goes beyond Schneider et al.'s prevalence numbers.\n\nThe mitigation—disable cmov conversion, loop unswitching, and vectorization for LLVM; jump threading, path splitting, and loop unswitching for GCC—is practical and tested on BearSSL/MbedTLS. The mean overhead is small, and the paper is honest that completeness is not guaranteed.\n\nThe problem is the 'removes all' claim. The pass set was derived from the leaks observed in this benchmark, and then validated by rerunning the same detector on the same benchmark. That is close to in-sample. Showing that disabling the passes that caused the observed leaks removes those leaks is a restatement of the analysis, not a prediction test. The paper needs a held-out set of CT code or at least a leave-one-pass-out analysis to claim general coverage. Second, Microwalk with 16 secret inputs has known false negatives; the paper says so. So the correct claim is 'removes all violations detected by Microwalk under our test inputs,' not 'removes all compiler-introduced violations.' That distinction should be in the abstract and conclusion. Third, the performance summary hides large per-benchmark regressions: ChaCha20 at -16.5% and ECDSA at -12% in BearSSL are not 'negligible' for a deployable defense, even if the mean stays near zero. Report medians and worst-case too. Minor: the LLVM mitigation relies on undocumented -mllvm flags that could change between releases; that's fine as an interim measure, but worth stating as a maintenance cost.\n\nWho is it for? Developers who want a quick hardening today, and compiler maintainers who now have a concrete list of passes to look at. It doesn't prove the flag set is complete, but it doesn't need to if the claims are qualified.\n\nI'd send it to peer review. The core analysis is solid and reproducible in spirit, and the overclaiming is fixable with a careful revision. I'd cite it, with the caveat that the 'all' should be read as 'all detected.'","headline":"A pass-level map of where LLVM/GCC break constant-time code that is genuinely useful and mostly convincing, but the 'removes all violations' claim outruns a validation that is in-sample and rests on a detector with known blind spots.","tokens_in":16601,"tokens_out":3149,"would_cite":true,"duration_ms":32248,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Disabling a small set of compiler optimization passes removes all observed compiler-introduced constant-time violations in known constant-time implementations, at negligible performance cost.","keywords":["constant-time programming","timing side channels","compiler optimizations","LLVM","GCC","loop unswitching","vectorization","conditional moves"],"falsifier":"Compile a larger, independent set of constant-time cryptographic implementations with the proposed flag sets and analyze the resulting binaries with a sound static constant-time checker or with exhaustive dynamic tracing; any secret-dependent branch or memory access that appears in the binary but not in the source would show that the flag set does not remove all compiler-introduced violations.","tokens_in":15701,"feed_emoji":"🛡️","tokens_out":7055,"duration_ms":68125,"temperature":0.7,"pith_summary":"The paper tries to show that constant-time guarantees written into source code by cryptographic developers are being silently undone by a small, identifiable set of compiler optimization passes, and that this can be prevented without rewriting code or switching compilers. It builds a dataset of compiler-introduced constant-time violations by compiling the same benchmarks with older and newer versions of LLVM and GCC, then using a dynamic analysis tool to attribute newly appearing leaks to source lines. It isolates the responsible passes—loop unswitching, loop vectorization, and cmov conversion in LLVM; jump threading, path splitting, and loop unswitching in GCC—and shows that disabling these passes via compiler flags removes every observed compiler-introduced violation in known constant-time implementations. The payoff is practical: developers can harden existing cryptographic builds with a handful of flags and pay a negligible average performance penalty.","feed_headline":"Three compiler flags end constant-time leaks","feed_subtitle":"Disabling vectorization, loop unswitching, and cmov conversion in LLVM removes every test leak at under 1% average cost.","key_machinery":"The central object is the optimization pipeline that turns constant-time source patterns into secret-dependent control flow. In LLVM the chain runs: bit-mask arithmetic is collapsed by the InstCombine pass into a select IR instruction; loop unswitching treats the select as a loop-invariant condition and hoists it into a branch; loop vectorization duplicates the loop into vectorized and scalar epilogue versions, and the back-end lowers select to a conditional jump because x86 lacks a vector conditional-move; and the cmov conversion pass in the x86 back-end rewrites even scalar conditional moves back into branches when it predicts the branch well. In GCC, constant-time ternary operators are represented as conditional branches in GIMPLE, and jump threading, path splitting, and loop unswitching can reshape those branches so the if-conversion pass can no longer linearize them into conditional moves. The mechanism that carries the argument is pass-by-pass attribution: each leak is traced to a specific pass or interaction, then the pass is disabled via a flag and the leak disappears.","core_discovery":"The central claim is that a small set of compiler optimization passes, and the interactions between them, are at the root of nearly all compiler-introduced constant-time violations, and that disabling these specific passes with available or undocumented compiler flags eliminates the violations. In LLVM, constant-time bit-mask arithmetic is simplified into select instructions, which then become secret-dependent branches through a combination of loop unswitching, loop vectorization (which lacks a vector conditional-move instruction and lowers select to branches), and the x86 back-end's cmov conversion pass. In GCC, constant-time ternary expressions are represented as conditional branches by default, and jump threading, path splitting, and loop unswitching can reshape those branches so the if-conversion pass can no longer turn them into conditional moves. The paper demonstrates on its benchmark suite—including BearSSL, MbedTLS, and known toy examples such as the Kyber poly_frommsg leak—that disabling these passes removes all compiler-introduced constant-time violations while keeping average performance overhead near zero.","pith_inferences":["The same pass-disabling recipe could be adapted to other compilers and back-ends by identifying the equivalent passes (for example, in MSVC or in LLVM-based front-ends), but the mapping would need its own empirical validation.","The paper's finding that pass interactions can both break and restore constant-time behavior implies that future compiler updates might fix some leaks while creating others; a pass-by-pass detection tool run after each compiler release would be a natural follow-up.","If the flag set is adopted widely, it may reduce the incentive for compiler maintainers to add constant-time preservation features, since developers could simply disable the offending passes; the trade-off between performance and security would then be decided by flag policy rather than compiler design.","The benchmark-scoped nature of the claim suggests that high-assurance settings should combine the flag set with a sound static analysis of the final binary before deployment, rather than trusting the flag set alone."],"forward_implications":["Cryptographic libraries compiled with the proposed flag sets will no longer have the specific compiler-introduced leaks found in this study, without any source changes.","The same flag-based approach can be folded into build systems and distribution packaging for both GCC and LLVM, making it immediately deployable.","Keeping loop vectorization enabled in LLVM is insufficient for full protection (the RSA-bearssl benchmark remains vulnerable), so the full flag set is required for the claimed guarantee.","The negligible measured performance impact suggests the mitigation is viable for production use, not just for research artifacts.","Because the claim is benchmark-scoped, the flag set should be revalidated when compilers add new passes or change existing ones."],"supporting_citations":[{"why":"Supplies the dynamic analysis tool used to detect constant-time violations in binaries, the core detection mechanism of the study.","marker":"[48]"},{"why":"Provides the benchmark suite with verified constant-time status, used as ground truth for the CT benchmarks.","marker":"[26]"},{"why":"Prior quantitative study showing newer LLVM versions break constant-time more often; motivates the version-comparison methodology and provides a baseline.","marker":"[42]"},{"why":"Documents known compiler-introduced constant-time violations in ct_select functions and supplies toy examples used in the benchmark.","marker":"[44]"},{"why":"Reports the LLVM timing leak in Kyber's poly_frommsg, one of the toy examples recompiled and analyzed in the paper.","marker":"[41]"},{"why":"GCC bug report on path splitting causing if-conversion misses; used as a toy example for GCC-specific violations.","marker":"[12]"},{"why":"GCC bug report on branches in branchless binary search; used as another toy example for compiler-introduced branches.","marker":"[11]"}],"fun_headline_variants":["Three compiler flags plug constant-time leaks","Stop constant-time leaks with three flags","Disable three passes to fix constant-time","Three flags block side-channel leaks","Compiler leaks? Three flags fix it"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The analysis assumes that the set of leaks found by running the dynamic analysis tool with 16 random secret inputs and mapping reported vulnerable instructions to source lines via DWARF debug information accurately captures every compiler-introduced constant-time violation; if any leak is missed or misattributed, the identified pass set and the all-violations-removed claim are incomplete.","fun_headline_variants_meta":{"raw":{"variants":["Three compiler flags plug constant-time leaks","Stop constant-time leaks with three flags","Disable three passes to fix constant-time","Three flags block side-channel leaks","Compiler leaks? Three flags fix it"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000899,"raw_usage":{"total_tokens":3870,"prompt_tokens":939,"completion_tokens":2931,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":555,"completion_tokens_details":{"reasoning_tokens":2870}},"tokens_in":555,"tokens_out":2931,"duration_ms":24112,"temperature":1.0,"reasoning_tokens":2870,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T19:11:01.660536+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compile a larger, independent set of constant-time cryptographic implementations with the proposed flag sets and analyze the resulting binaries with a sound static constant-time checker or with exhaustive dynamic tracing; any secret-dependent branch or memory access that appears in the binary but not in the source would show that the flag set does not remove all compiler-introduced violations.","supporting_citations":[{"cited_title":"Microwalk: A framework for finding side channels in binaries","cited_arxiv_id":null,"evidence_quote":"Supplies the dynamic analysis tool used to detect constant-time violations in binaries, the core detection mechanism of the study."},{"cited_title":"A systematic evaluation of automated tools for side-channel vulnerabilities detection in cryptographic libraries","cited_arxiv_id":null,"evidence_quote":"Provides the benchmark suite with verified constant-time status, used as ground truth for the CT benchmarks."},{"cited_title":"Breaking Bad: How Compilers Break Constant-Time Implementations","cited_arxiv_id":"2410.13489","evidence_quote":"Prior quantitative study showing newer LLVM versions break constant-time more often; motivates the version-comparison methodology and provides a baseline."},{"cited_title":"Anderson","cited_arxiv_id":null,"evidence_quote":"Documents known compiler-introduced constant-time violations in ct_select functions and supplies toy examples used in the benchmark."},{"cited_title":"Compiler-introduced timing leak in Kyber reference implementation","cited_arxiv_id":null,"evidence_quote":"Reports the LLVM timing leak in Kyber's poly_frommsg, one of the toy examples recompiled and analyzed in the paper."},{"cited_title":"Bug 68541 - [6 regression] path splitting causes if- conversion miss","cited_arxiv_id":null,"evidence_quote":"GCC bug report on path splitting causing if-conversion misses; used as a toy example for GCC-specific violations."},{"cited_title":"Bug 113682 - branches in branchless binary search rather than cmov/csel/csinc","cited_arxiv_id":null,"evidence_quote":"GCC bug report on branches in branchless binary search; used as another toy example for compiler-introduced branches."}],"review_version":1}