{"id":"32300a15-132e-4f0b-a1ba-bd3cbcd00344","arxiv_id":"2412.07135","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Oreo translates virtual addresses into a masked address space before they reach caches, TLBs, and branch predictors, preventing microarchitectural side channels from revealing the ASLR secret offset.","lead":"ASLR hides where programs are in memory, but tiny hardware leaks have let attackers find the secret addresses anyway. This paper proposes Oreo, a software-hardware design that strips the secret bits out of addresses before the processor's caches and other internal structures ever see them, blocking several known leak paths.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Oreo's user-space scheme uses non-canonical address bits as ASLR offset bits; on real x86-64 such addresses trigger #GP before memory access, so the user-space design is unlikely to work outside gem5, undermining the transparency claim.","rationale":"I read the paper as a serious attempt to block address-side channels at the source, and the core masked-address interface is a plausible and well-motivated design. The kernel-space configuration uses canonical bits, so the formal non-interference theorem remains coherent for that setting. The load-bearing weakness I identify is the user-space choice of non-canonical bits as microarchitecture oblivious bits: on real x86-64, any nonzero value in bits 48-52 makes the address non-canonical and triggers a #GP before the memory system is reached. The paper's own limitation section notes reduced non-canonical bits in other configurations but does not acknowledge that even 4-level paging leaves zero usable non-canonical bits for canonical user-space addresses. Since the Virt2Mask conversion is an internal pipeline modification, the paper would need to also disable or move the architectural canonicality check; no such change is described or evaluated. The gem5 prototype evidently lacks this check, so the user-space experiments do not validate hardware behavior. The reader's chosen weakest_assumption about the formal model's Obs tuple (BP, LSQ, Cache, TLB) is a legitimate abstraction concern, but it is more generic and cannot be settled as directly as the non-canonical address issue. My concrete test, whether by simulator instrumentation or static trace analysis, would definitively show whether the user-space scheme is viable. Since the kernel-side protection and the overall concept remain promising, the appropriate verdict is unchanged from the reader's CONDITIONAL: the paper must address the user-space non-canonical flaw (e.g., by using canonical bits with an acceptable subregion size or by explicitly redefining the canonicality check) before its user-space transparency claims can be accepted.","tokens_in":38403,"tokens_out":17850,"duration_ms":183302,"concrete_test":"Patch gem5's x86 implementation to enforce the architectural canonicality check on every user-space virtual address before the Virt2Mask module (i.e., flag addresses with bits 63:48 not equal to bit 47 as #GP), then run experiments E1 (hello/hello_invalid) and a SPEC2017 workload. If valid user-space programs fault or the hello_invalid behavior changes, the user-space design is broken on real hardware. Alternatively, inspect the ArchPC and load/store virtual addresses in the provided gem5 traces: any user-space address with bits 48-52 non-zero is non-canonical and would fault on real x86.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The user-space variant of Oreo (Sections V-C and VI-A) selects bits 48-52 as the microarchitecture oblivious bits. On x86-64 with 4-level paging, a canonical address requires bits 63:48 to equal the sign extension of bit 47. User-space addresses have bit 47 = 0, so setting any of bits 48-52 to a nonzero random value (the ASLR offset) makes the address non-canonical. Real x86 processors raise #GP for non-canonical addresses before the TLB or cache is accessed, so the speculative side effects Oreo relies on would not occur. The Virt2Mask conversion is inserted in the pipeline, but the paper does not explain how the canonicality check is bypassed or moved; unmodified hardware would fault before conversion. The gem5 prototype apparently does not enforce canonicality, so the experiments do not expose this. As a result, the claim that Oreo is transparent for user programs and protects user-space ASLR is not substantiated on real hardware. This is a concrete implementation-level flaw, distinct from the formal model's abstraction choices.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper analyzes microarchitectural ASLR bypasses and classifies them into three leakage paths: virtual-memory-layout probing, use of secret-embedded pointers as branch/load-store addresses, and Spectre-style pointer exfiltration. To block the first two paths, it proposes Oreo, a software/hardware co-design that converts randomized virtual addresses to masked addresses before they reach address-indexed microarchitectural structures and page tables, and moves virtual-address validity checks to instruction commit time. The manuscript describes bit-selection strategies, a Linux 6.6 and gem5 prototype for kernel text, kernel modules, and user-space programs, a performance evaluation reporting 0.11% average CPI overhead on SPEC2017 and -0.28% on LEBench, security experiments against a prefetch attack and a BlindSide-style speculative probing attack, and a formal non-interference proof in Appendix C.","tokens_in":38610,"tokens_out":14308,"duration_ms":162046,"significance":"If the design is sound, Oreo would be an important step toward source-level defense against a broad class of ASLR bypasses: the masked-address-space abstraction is simple and directly addresses both layout probing and pointer-use leakage, and the paper provides a systematic taxonomy of prior attacks. The authors ship an open-source artifact with scripts to reproduce the main experiments, which strengthens confidence. That said, the formal proof is a hand-written operational-semantics argument, not machine-checked, and it is narrower than the implementation; the user-space configuration relies on non-canonical addresses whose behavior is not validated on real hardware. The performance claim is not based on synthesis or detailed timing of the added hardware. These points require revision but do not, in my assessment, invalidate the core idea for kernel-space mappings.","major_comments":[{"comment":"The user-space configuration uses bits 48-52 as microarchitecture-oblivious bits. On x86-64 with 4-level paging these bits are in the non-canonical range, and any address with them set raises #GP before address translation or cache access on real processors; Linux's user-address validation (access_ok/TASK_SIZE) would likewise reject such pointers in syscalls. The paper does not explain how the modified pipeline removes or relocates the canonicality check, nor how user-space ABI compatibility is preserved. Since gem5 does not model canonicality checking, the functional/security/performance evaluation does not exercise this behavior. This is load-bearing for the claims of transparency and user-space ASLR support; the user-space design needs to be reworked (e.g., with canonical protected bits and the stated subregion constraint) or those claims need to be scoped to kernel-space regions.","section":"V-C and VI-A"},{"comment":"Appendix C defines LOreo under the explicit assumption that the code length is equal to the subregion size. The implemented configuration for kernel text uses protected bits 31-38, giving lensubregion = 2^31 = 2GB while the kernel text is roughly 32MB; user programs are similarly smaller than their subregions. Thus Theorem 1 is proved only for a special case that does not match the instantiated system. Since the non-interference theorem is a central contribution, please extend Lemmas 1-2 and Theorem 1 to the case lensubregion >= code length, including partially unmapped subregions, or state exactly which evaluated configurations satisfy the proof's assumptions.","section":"Appendix C"},{"comment":"Section VI-C reaches the conclusion that the Virt2Mask module, offset extraction, and commit-stage checks introduce no extra cycles based on logical complexity alone, and the gem5 experiments do not account for added combinational delay or possible critical-path impact. The paper's headline result of negligible performance overhead therefore is not yet fully substantiated. I ask for at least a post-synthesis timing estimate for the added pipeline logic, or an explicit statement that the zero-cycle cost is an assumption rather than a measured result.","section":"VI-C and VII-B"},{"comment":"The abstract machine in Appendix C admits requests fetch, load, store, none, and check, but not prefetch. The first security evaluation is the prefetch attack (Section VII-C), and prefetch is listed in Table I as a relevant attack class. A prefetch instruction is not identical to load because it does not return data and does not commit, so the proof does not literally cover it; please include prefetch semantics (or argue that it is subsumed by the load rule) for Theorem 1 to cover the evaluated path-1 attack.","section":"Appendix C"}],"minor_comments":[{"comment":"The abstract states that Oreo prevents side channels from leaking ASLR secrets, but Section IV explicitly excludes power-induced timing side channels; please add a qualifier such as within the stated threat model.","section":"Abstract and IV"},{"comment":"The trace dumps in Figure 11 are extremely dense and the highlighted deviations are hard to identify; please provide enlarged excerpts or a tabular summary of where the traces differ.","section":"Figure 11"},{"comment":"The text uses medium latency where median latency is meant; please correct this throughout Section VII-B and the artifact appendix.","section":"VII-B"},{"comment":"The artifact appendix refers to Figure 7 for the LEBench results while the main text shows them in Figure 9; please synchronize the numbering.","section":"Appendix A"},{"comment":"Equation (1), the Virt2Mask definition, is only valid for addresses within the randomization region; please state this domain condition explicitly.","section":"V-B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is within scope for a systems/security venue. The most serious issue is the user-space non-canonical-address configuration, which is unlikely to work on real x86-64 as described; if the authors cannot fix it, the paper should be revised to focus on kernel-space ASLR and adjust the transparency claims. I do not see grounds for rejection because the kernel-space design and the proof skeleton are promising and the required changes are local to the bit-selection discussion, the formal appendix, and the performance-claim wording. The open-source artifact is a plus."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe masked-address idea is genuinely new and the kernel-side design is well argued; I'd send this to a serious referee. But don't let the user-space claims through without a real fix: the paper says it uses non-canonical bits 48-52 as ASLR offset bits for user programs, and on real x86-64 those addresses are non-canonical when bit 47 is 0. Hardware raises #GP before address translation or cache access, so the Virt2Mask conversion would never see them. gem5 doesn't enforce canonicality, so the experiments don't expose this. This is a concrete implementation flaw, not an abstraction gap, and it undermines the 'transparent to user programs' claim.\n\nWhat's good: the three-path taxonomy is clear and useful; the Virt2Mask/Mask2Valid design is a fresh way to redact secret address bits before they reach TLB, cache, and BTB; the formal non-interference proof in Appendix C is coherent under its assumptions; and the artifact is unusually complete (Linux 6.6 patch, gem5 changes, SPEC/LEBench scripts). The entropy analysis for bit selection is thoughtful, and the explicit limitations section is honest.\n\nThe softer spots: performance overhead is estimated by cycle counting, not synthesis; the 'no extra cycles' for Virt2Mask is plausible but not measured. The proof's observation function Obs = (BP, LSQ, Cache, TLB) excludes paging-structure caches, store-to-load forwarding state, and memory dependence predictors; the theorem only holds for what's modeled. The paper scopes out power channels, which is fine, but the 'blocks paths 1 and 2' statement should be read as 'blocks them in this model.'\n\nWho should read this: architecture and systems security folks working on ASLR hardening and speculative side channels. It deserves a serious referee, but the user-space part needs a rework—either use canonical bits with per-process subregions, or explain how the canonicality check is bypassed in hardware. The kernel text/module protection is the stronger half.\n\nRecommendation: send to peer review, require major revision.","headline":"Masked-address core is a real contribution, but the user-space variant as specified faults on real x86 before conversion; ship it to reviewers with a mandatory fix.","tokens_in":39145,"tokens_out":2385,"would_cite":true,"duration_ms":25789,"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":"Oreo strips the randomized bits from virtual addresses before caches, TLBs, and branch predictors see them, closing two of the three leakage paths used to defeat ASLR.","keywords":["ASLR","microarchitectural side channels","KASLR","address translation","non-interference","speculative execution","masked address space","hardware-software co-design"],"falsifier":"Instrument a simulator-based Oreo core with a paging-structure cache or a store-to-load forwarding predictor, then run functionally equivalent executions under two different ASLR offsets while measuring translation latency or forwarding behavior for mapped versus unmapped addresses; a reproducible difference in either structure would contradict the theorem's assumption that Obs captures every leaking structure.","tokens_in":38171,"feed_emoji":"🛡️","tokens_out":8047,"duration_ms":76025,"temperature":0.7,"pith_summary":"Oreo claims that the two most direct ways microarchitectural side channels defeat ASLR—probing which virtual addresses are mapped, and observing secret-dependent pointers as they are used by the victim—can be shut off at the source by a new memory interface. The paper introduces a masked address layer between virtual and physical memory: before an address is used to index caches, TLBs, branch predictors, or page tables, the randomized bits that carry the ASLR secret are redacted to form a masked address. Addresses that differ only in those bits therefore produce identical microarchitectural effects, and the mapped/unmapped distinction is deferred to an architectural check at instruction commit time. If correct, this turns the arms race of patching individual side channels into a single structural fix, while leaving user programs unchanged and adding negligible measured overhead. The paper backs the claim with a non-interference proof and with simulator-based security and performance evaluations.","feed_headline":"Masked addresses hide ASLR secrets before caches see them","feed_subtitle":"Redacting randomized address bits before TLBs and caches see them makes mapped and unmapped pages indistinguishable.","key_machinery":"The load-bearing mechanism is the masked address space, defined by two inverse-looking maps. $Virt2Mask(v) = ((v - start) \\bmod len_{subregion}) + start$ removes the microarchitecture oblivious bits, and $Mask2Valid(w) = offset_{oreo} + w$ reconstructs the valid virtual address using the per-region secret offset stored in page-table entries. All address-indexed microarchitecture structures—branch predictor, TLB, cache hierarchy, page-table walk, and LSQ-based optimizations—consume masked addresses, so their update inputs are independent of the secret bits. The mapped/unmapped security check is split in two: an MMU permission check on masked addresses during speculation, and a virtual-address validity check at instruction commit time. The proof in Appendix C shows that these two maps make functionally equivalent executions mask-equivalent and therefore observation-equivalent.","core_discovery":"The paper's central discovery is that ASLR's secret offset does not need to be kept secret from the microarchitecture; it needs to be removed from the microarchitecture's address inputs entirely. Oreo's memory interface maps each randomization subregion of virtual memory onto the same subregion of a masked address space via $Virt2Mask(v) = ((v - start) \\bmod len_{subregion}) + start$, so any two virtual addresses that differ only in the microarchitecture oblivious bits collapse to one masked address. Page tables, TLBs, caches, branch predictors, and load/store-queue logic are all re-pointed at masked addresses, and the correct ASLR offset is stored in page-table entries and retrieved only at commit time to validate the architectural PC and load/store addresses. The formal result (Theorem 1 in Appendix C) states that for any two Oreo layouts that are functionally equivalent, the adversary's observation trace $Obs_\\mu(S,t)$—branch predictor, load/store queue, cache, and TLB states—is identical. This is what it means to block leakage paths 1 and 2: probing mapped versus unmapped addresses is indistinguishable, and a victim's secret-embedded pointers leave no address-indexed footprint.","pith_inferences":["Editorial inference: a testable next step is to add paging-structure caches, store-to-load forwarding predictors, or memory-dependence predictors to the observation model and re-run the paper's speculative probing experiment; a measurable timing difference in any of those structures would fall outside the proved guarantee.","Editorial inference: the commit-time validity check on the architectural PC creates a possible new timing surface if exception priority, replay behavior, or speculative squashing interacts with the check result; a microbenchmark comparing valid and invalid PCs under replay-style attacks would quantify any residual leakage.","Editorial inference: Oreo's 'mask now, validate at commit' recipe generalizes beyond ASLR to any secret encoded in an address, such as pointer-authentication tags or capability bounds, suggesting a reusable hardware pattern for keeping address-encoded secrets out of speculative microarchitecture.","Editorial inference: with page-granularity ASLR, Oreo's per-page offsets stored in PTEs would give every page an independent protected offset; building the code relocator the paper identifies as the engineering blocker would make it possible to test whether per-page entropy materially raises the bar against code-reuse attacks."],"forward_implications":["Attacks in leakage path 1, such as prefetch-based and speculative code-region probing, stop working because valid and invalid addresses differing only in protected bits hit the same masked-address TLB and cache entries.","Attacks in leakage path 2, including AnC, Jump Over ASLR, and EntryBleed, lose their address-indexed footprint because branch predictors, TLBs, and page-table walks are keyed by masked addresses instead of secret-bearing virtual addresses.","Because the fix is at the memory interface rather than per side channel, any future address-indexed side channel that falls inside the modeled observation set is blocked by the same mechanism without a new mitigation.","Oreo is designed to compose with existing Spectre mitigations, which continue to cover leakage path 3; the paper reports that the two classes of defense are complementary.","The prototype reports negligible performance cost: an average 0.11% CPI overhead on SPEC2017 IntRate and a −0.28% average latency change on LEBench, with at least 99.46% of SPEC memory accesses passing through the mask."],"supporting_citations":[{"why":"Defines the prefetch side-channel attack used to bypass kernel ASLR; Oreo's first security experiment reproduces and blocks it.","marker":"[31]"},{"why":"Describes speculative code-region probing, the path-1 attack Oreo uses as its representative security evaluation.","marker":"[27]"},{"why":"Shows how page-table-walk cache contention leaks ASLR offsets (AnC), a path-2 attack that motivates masking the addresses seen by the walker.","marker":"[29]"},{"why":"Demonstrates branch-predictor-based ASLR leakage, establishing the BTB as a path-2 channel Oreo must close.","marker":"[21]"},{"why":"FLARE, the prior mitigation that closes only the address-translation-latency channel, which Oreo positions itself against.","marker":"[13]"},{"why":"KAISER/KPTI-style address-space isolation, an alternative approach that still leaves path-2 leakage and motivates a broader design.","marker":"[30]"},{"why":"EntryBleed, a universal KASLR bypass via TLB timing, used as a representative path-2 attack.","marker":"[53]"},{"why":"Adelie, used in the paper to discuss relaxing the kernel module constraint so modules can have independent offsets.","marker":"[60]"},{"why":"The kernel patch that relocates kernel text and modules into a 444 GB unused region, enabling the prototype's enhanced bit selection.","marker":"[33]"},{"why":"The hardware simulator used to prototype and evaluate Oreo's microarchitecture changes.","marker":"[9]"}],"fun_headline_variants":["Oreo blinds microarchitecture to ASLR secrets","Oreo: Strip ASLR bits before caches see them","Oreo masks addresses, hiding ASLR from side channels","Oreo makes mapped and unmapped pages indistinguishable"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The proof assumes the adversary's observation captures exactly the branch predictor, load/store queue, cache, and TLB, and that the commit-stage virtual-address check is invisible; if any other microarchitectural structure is updated with secret-dependent address bits, or if power-induced timing is in scope, the claim that Oreo blocks leakage paths 1 and 2 is not established by the theorem.","fun_headline_variants_meta":{"raw":{"variants":["Oreo blinds microarchitecture to ASLR secrets","Oreo: Strip ASLR bits before caches see them","Oreo masks addresses, hiding ASLR from side channels","Oreo makes mapped and unmapped pages indistinguishable"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00107,"raw_usage":{"total_tokens":4496,"prompt_tokens":974,"completion_tokens":3522,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":590,"completion_tokens_details":{"reasoning_tokens":3454}},"tokens_in":590,"tokens_out":3522,"duration_ms":22272,"temperature":1.0,"reasoning_tokens":3454,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T19:06:21.260228+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument a simulator-based Oreo core with a paging-structure cache or a store-to-load forwarding predictor, then run functionally equivalent executions under two different ASLR offsets while measuring translation latency or forwarding behavior for mapped versus unmapped addresses; a reproducible difference in either structure would contradict the theorem's assumption that Obs captures every leaking structure.","supporting_citations":[{"cited_title":"EntryBleed: A universal KASLR bypass against KPTI on Linux,","cited_arxiv_id":null,"evidence_quote":"EntryBleed, a universal KASLR bypass via TLB timing, used as a representative path-2 attack."},{"cited_title":"Prefetch side- channel attacks: Bypassing SMAP and kernel ASLR,","cited_arxiv_id":null,"evidence_quote":"Defines the prefetch side-channel attack used to bypass kernel ASLR; Oreo's first security experiment reproduces and blocks it."},{"cited_title":"Spec- ulative probing: Hacking blind in the spectre era,","cited_arxiv_id":null,"evidence_quote":"Describes speculative code-region probing, the path-1 attack Oreo uses as its representative security evaluation."},{"cited_title":"ASLR on the line: Practical cache attacks on the MMU","cited_arxiv_id":null,"evidence_quote":"Shows how page-table-walk cache contention leaks ASLR offsets (AnC), a path-2 attack that motivates masking the addresses seen by the walker."},{"cited_title":"Jump over ASLR: Attacking branch predictors to bypass ASLR,","cited_arxiv_id":null,"evidence_quote":"Demonstrates branch-predictor-based ASLR leakage, establishing the BTB as a path-2 channel Oreo must close."},{"cited_title":"KASLR is dead: Long live KASLR,","cited_arxiv_id":null,"evidence_quote":"KAISER/KPTI-style address-space isolation, an alternative approach that still leaves path-2 leakage and motivates a broader design."},{"cited_title":"Adelie: con- tinuous address space layout re-randomization for Linux drivers,","cited_arxiv_id":null,"evidence_quote":"Adelie, used in the paper to discuss relaxing the kernel module constraint so modules can have independent offsets."},{"cited_title":"x86/pie: Make kernel image’s virtual address flexible,","cited_arxiv_id":null,"evidence_quote":"The kernel patch that relocates kernel text and modules into a 444 GB unused region, enabling the prototype's enhanced bit selection."}],"review_version":1}