Pith. sign in

REVIEW 4 major objections 5 minor 97 references

Oreo: Protecting ASLR Against Microarchitectural Attacks (Extended Version)

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

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

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

arxiv 2412.07135 v1 pith:JGWMBCEM submitted 2024-12-10 cs.CR cs.AR

Shixin Song , Joseph Zhang , Mengjia Yan This is my paper · ORCID
classification cs.CRcs.AR
keywords ASLRmicroarchitecturalsidechannelsKASLRaddresstranslationnon-interferencespeculativeexecutionmaskedspacehardware-softwareco-design
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

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.

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 (4)
  1. [V-C and VI-A] 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.
  2. [Appendix C] 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.
  3. [VI-C and VII-B] 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.
  4. [Appendix C] 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.
minor comments (5)
  1. [Abstract and IV] 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.
  2. [Figure 11] 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.
  3. [VII-B] The text uses medium latency where median latency is meant; please correct this throughout Section VII-B and the artifact appendix.
  4. [Appendix A] The artifact appendix refers to Figure 7 for the LEBench results while the main text shows them in Figure 9; please synchronize the numbering.
  5. [V-B] Equation (1), the Virt2Mask definition, is only valid for addresses within the randomization region; please state this domain condition explicitly.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Oreo's central security claim is a design-plus-proof argument with explicit modeling assumptions, not a result that reduces by construction to its inputs.

full rationale

Oreo's derivation chain is self-contained in the relevant sense. The security claim is supported by (1) a hardware/OS design that converts virtual addresses to masked addresses before they reach BP, LSQ, cache, and TLB structures, and (2) a formal non-interference proof (Appendix C) whose key lemmas are proven from the defined Virt2Mask and Mask2Valid functions and the Oreo execution semantics. No fitted parameter is renamed as a prediction: the entropy analysis is normative, and the evaluations compare Oreo against an insecure baseline, with the claimed protection demonstrated by timing measurements and recorded microarchitectural traces. The proof's functional-equivalence premise is an explicit scoping assumption that excludes the third leakage path (secret-dependent values used as data); it is not a restatement of the conclusion, and the proof explicitly shows that functional equivalence would not prevent leakage on the baseline, so the theorem is non-trivial. The observation model Obs = (BP, LSQ, Cache, TLB) and the invisibility of the check(v) request are stated modeling assumptions; if they are too narrow, the guarantee is weakened, but that is a completeness/correctness concern, not circularity. The paper's self-citations, e.g., EntryBleed [53] and MicroScope [71] by Mengjia Yan, are used only as attack examples or defensive design motivation and are not load-bearing justifications of Oreo's core mechanism. The flagged user-space non-canonical-bit concern (Sections V-C and VI-A) is a real-hardware feasibility question rather than a circular-derivation issue: the paper's claim is not obtained by assuming the conclusion. Overall, the derivation does not reduce to its own inputs, so the circularity score is 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 1 invented entities

The central claim rests on design choices (subregion size, protected bits) and scoping assumptions rather than on fitted parameters; no numerical parameter is tuned to make the security or performance evaluation pass.

free parameters (2)
  • lensubregion (kernel text/modules) = 2^31 bytes (8 protected bits, bits 31-38)
    Chosen so the kernel text (up to about 32 MB) fits in one subregion; this is a design constraint, not fitted to an outcome.
  • User-space protected bits = bits 48-52 (5 bits)
    Chosen to match available leaf PTE bits and non-canonical address bits; not fitted to performance or security data.
assumptions (4)
  • domain assumption Functional equivalence: for two layouts, request traces have the same operation types and addresses that either are equal or map to the same physical address.
    Premise of Theorem 1 in Appendix C; it rules out leakage path 3 (Spectre-like pointer data flow), which Oreo explicitly does not target.
  • ad hoc to paper Code length equals subregion size len in the proof of Lemma 1.
    Stated in Appendix C (Oreo Memory Layouts) to simplify the proof; real kernel text is smaller than the 2 GB subregion, but the conclusion should still hold for layouts differing only in protected bits.
  • domain assumption Obs includes BP, LSQ, cache metadata, and TLB; no power or analog channels.
    Adversary model in Appendix C and Section IV; power side channels are explicitly out of scope.
  • domain assumption Virt2Mask is applied to all addresses used to update the modeled microarchitecture structures.
    This is the core design premise; the proof and the gem5 prototype model it, but unmodified hardware paths (e.g., IOMMU, SMM) are not covered.
invented entities (1)
  • Masked address space independent evidence
    purpose: New intermediate address space that removes microarchitecture-oblivious bits before translation, preventing secret bits from reaching caches, TLBs, and BTBs.
    Implemented in the shipped Linux 6.6 patch and gem5 simulator (Zenodo artifact); the prefetch attack and trace experiments in Section VII-C provide falsifiable checks.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Oreo: Protecting ASLR Against Microarchitectural Attacks (Extended Version)." pith.science (2026). https://pith.science/paper/JGWMBCEM

@misc{pith2026241207135,
  author       = {Pith},
  title        = {Pith review of: Oreo: Protecting ASLR Against Microarchitectural Attacks (Extended Version)},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JGWMBCEM}},
  note         = {Machine review of arXiv:2412.07135}
}
read the original abstract

Address Space Layout Randomization (ASLR) is one of the most prominently deployed mitigations against memory corruption attacks. ASLR randomly shuffles program virtual addresses to prevent attackers from knowing the location of program contents in memory. Microarchitectural side channels have been shown to defeat ASLR through various hardware mechanisms. We systematically analyze existing microarchitectural attacks and identify multiple leakage paths. Given the vast attack surface exposed by ASLR, it is challenging to effectively prevent leaking the ASLR secret against microarchitectural attacks. Motivated by this, we present Oreo, a software-hardware co-design mitigation that strengthens ASLR against these attacks. Oreo uses a new memory mapping interface to remove secret randomized bits in virtual addresses before translating them to their corresponding physical addresses. This extra step hides randomized virtual addresses from microarchitecture structures, preventing side channels from leaking ASLR secrets. Oreo is transparent to user programs and incurs low overhead. We prototyped and evaluated our design on Linux using the hardware simulator gem5.

Figures

Figures reproduced from arXiv: 2412.07135 by the authors.

Figure 1
Figure 1. Overview of Oreo’s new memory interface probing a mapped address versus an unmapped address re￾solves different microarchitectural side effects and thus distinct latency [12], [13], [27], [34], [38], [50], [67], [76], [78]. Additionally, these probe operations can be stealthy and do not cause system crashes, because they are either conducted under speculation or assisted with cache manipulation instructions such as … view at source ↗
Figure 2
Figure 2. Coarse-grained ASLR. (a) shows the whole virtual [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Three leakage paths that leak ASLR secret offset [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: Mapping between a virtual address v and a masked address w using Oreo’s memory interface. perform speculative execution attacks can execute a Spectre￾like gadget under speculation without knowing the secret offsetoreo. This is because accessing addresses only differing…
Figure 5
Figure 5. Figure 5: Protected bits selection strategies and their corresponding entropy. “Remaining entropy*” refers to “remaining entropy [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Compare Oreo’s randomized memory layout for coarse-grained ASLR (left) and page-granularity ASLR (right) We now analyze the Virt2Mask and Mask2Valid functions to highlight that minimal changes are needed to make Oreo support page-granularity ASLR. First, the coarse-gra…
Figure 7
Figure 7. Figure 7: Microarchitecture changes required by Oreo. on memory accesses are performed during the address trans￾lation within the MMU. When an instruction enters the com￾mit stage, the hardware checks whether it should trigger an exception (e.g., failing to pass a security check…
Figure 8
Figure 8. Figure 8: Performance evaluation results on SPEC2017 [PITH_FULL_IMAGE:figures/full_fig_p012_8.png]
Figure 10
Figure 10. Figure 10: Evaluating the prefetch attack on the insecure [PITH_FULL_IMAGE:figures/full_fig_p013_10.png]
Figure 9
Figure 9. Figure 9: Performance evaluation results on LEBench [PITH_FULL_IMAGE:figures/full_fig_p013_9.png]
Figure 11
Figure 11. Figure 11: Evaluating the speculative code gadget probing attack on the insecure baseline and [PITH_FULL_IMAGE:figures/full_fig_p014_11.png]
Figure 12
Figure 12. Figure 12: Artifact file structure 2) Build: In folder artifact, set up and enter the docker by running: $ cd linux $ docker-compose up -d $ docker-compose exec x86_fs /bin/bash In the docker’s shell, build Linux and gem5 by running: $ cd /root/linux $ python3 compile_scripts/co…
Figure 8
Figure 8. Figure 8: However, these benchmarks behave differently in [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

97 extracted references · 74 canonical work pages

  1. [1]

    Page table isolation (PTI),

    “Page table isolation (PTI),” https://www.kernel.org/doc/html/next/x86/ pti.html

  2. [2]

    2023 CWE top 25 most dangerous software weaknesses,

    “2023 CWE top 25 most dangerous software weaknesses,” https://cwe. mitre.org/top25/archive/2023/2023_top25_list.html, 2023

    2023

  3. [3]

    Memory management,

    “Memory management,” https://www.kernel.org/doc/html/v6.4/arch/x86/ x86_64/mm.html, 2024

    2024

  4. [4]

    Memory protection keys,

    “Memory protection keys,” https://docs.kernel.org/core-api/ protection-keys.html, 2024

    2024

  5. [5]

    GhostMinion: A strictness-ordered cache system for spectre mitigation,

    S. Ainsworth, “GhostMinion: A strictness-ordered cache system for spectre mitigation,” in MICRO-54: 54th Annual IEEE/ACM Interna- tional Symposium on Microarchitecture , 2021, pp. 592–606

    2021

  6. [6]

    MuonTrap: Preventing cross-domain spectre-like attacks by capturing speculative state,

    S. Ainsworth and T. M. Jones, “MuonTrap: Preventing cross-domain spectre-like attacks by capturing speculative state,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020, pp. 132–144

    2020

  7. [7]

    You can run but you can’t read: Preventing disclosure exploits in executable code,

    M. Backes, T. Holz, B. Kollenda, P. Koppe, S. Nürnberger, and J. Pewny, “You can run but you can’t read: Preventing disclosure exploits in executable code,” in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security , 2014, pp. 1342–1353

    2014

  8. [8]

    Spec- Shield: Shielding speculative data from microarchitectural covert chan- nels,

    K. Barber, A. Bacha, L. Zhou, Y . Zhang, and R. Teodorescu, “Spec- Shield: Shielding speculative data from microarchitectural covert chan- nels,” in 2019 28th International Conference on Parallel Architectures and Compilation Techniques (PACT). IEEE, 2019, pp. 151–164

    2019

Show all 97 references
  1. [9]

    The gem5 simulator,

    N. L. Binkert, B. M. Beckmann, G. Black, S. K. Reinhardt, A. G. Saidi, A. Basu, J. Hestness, D. Hower, T. Krishna, S. Sardashti, R. Sen, K. Sewell, M. S. B. Altaf, N. Vaish, M. D. Hill, and D. A. Wood, “The gem5 simulator,” SIGARCH Comput. Archit. News, vol. 39, no. 2, pp. 1– ...

    2011

  2. [10]

    Jump-oriented programming: a new class of code-reuse attack,

    T. Bletsch, X. Jiang, V . W. Freeh, and Z. Liang, “Jump-oriented programming: a new class of code-reuse attack,” in Proceedings of the 6th ACM symposium on information, computer and communications security, 2011, pp. 30–40

    2011

  3. [11]

    SPEC CPU2017: Next- generation compute benchmark,

    J. Bucek, K.-D. Lange, and J. v. Kistowski, “SPEC CPU2017: Next- generation compute benchmark,” in Companion of the 2018 ACM/SPEC International Conference on Performance Engineering, 2018, pp. 41–42

    2018

  4. [12]

    Fallout: Leaking data on Meltdown-resistant cpus,

    C. Canella, D. Genkin, L. Giner, D. Gruss, M. Lipp, M. Minkin, D. Moghimi, F. Piessens, M. Schwarz, B. Sunar et al., “Fallout: Leaking data on Meltdown-resistant cpus,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security , 2019, pp. 769–784

    2019

  5. [13]

    KASLR: Break it, fix it, repeat,

    C. Canella, M. Schwarz, M. Haubenwallner, M. Schwarzl, and D. Gruss, “KASLR: Break it, fix it, repeat,” in Proceedings of the 15th ACM Asia Conference on Computer and Communications Security , 2020, pp. 481– 493

    2020

  6. [14]

    CodeArmor: Virtualizing the code space to counter disclosure attacks,

    X. Chen, H. Bos, and C. Giuffrida, “CodeArmor: Virtualizing the code space to counter disclosure attacks,” in 2017 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE, 2017, pp. 514–529

    2017

  7. [15]

    Speculative pri- vacy tracking (SPT): Leaking information from speculative execution without compromising privacy,

    R. Choudhary, J. Yu, C. Fletcher, and A. Morrison, “Speculative pri- vacy tracking (SPT): Leaking information from speculative execution without compromising privacy,” in MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture , 2021, pp. 607–622

    2021

  8. [16]

    Leaking secrets through modern branch predictors in the speculative world,

    M. H. I. Chowdhuryy and F. Yao, “Leaking secrets through modern branch predictors in the speculative world,” IEEE Transactions on Computers, vol. 71, no. 9, pp. 2059–2072, 2021

    2021

  9. [17]

    Readactor: Practical code randomization resilient to memory disclosure,

    S. Crane, C. Liebchen, A. Homescu, L. Davi, P. Larsen, A.-R. Sadeghi, S. Brunthaler, and M. Franz, “Readactor: Practical code randomization resilient to memory disclosure,” in 2015 IEEE Symposium on Security and Privacy. IEEE, 2015, pp. 763–780

    2015

  10. [18]

    It’s a TRaP: Table randomization and protection against function-reuse attacks,

    S. J. Crane, S. V olckaert, F. Schuster, C. Liebchen, P. Larsen, L. Davi, A.-R. Sadeghi, T. Holz, B. De Sutter, and M. Franz, “It’s a TRaP: Table randomization and protection against function-reuse attacks,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Comm...

    2015

  11. [19]

    Don’t mesh around: Side-Channel attacks and mitigations on mesh interconnects,

    M. Dai, R. Paccagnella, M. Gomez-Garcia, J. McCalpin, and M. Yan, “Don’t mesh around: Side-Channel attacks and mitigations on mesh interconnects,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 2857–2874

    2022

  12. [20]

    ProSpeCT: Provably secure speculation for the Constant- Time policy,

    L.-A. Daniel, M. Bognar, J. Noorman, S. Bardin, T. Rezk, and F. Piessens, “ProSpeCT: Provably secure speculation for the Constant- Time policy,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 7161–7178

    2023

  13. [21]

    Jump over ASLR: Attacking branch predictors to bypass ASLR,

    D. Evtyushkin, D. Ponomarev, and N. Abu-Ghazaleh, “Jump over ASLR: Attacking branch predictors to bypass ASLR,” in 2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) . IEEE, 2016, pp. 1–13

    2016

  14. [22]

    BranchScope: A new side-channel attack on directional branch predic- tor,

    D. Evtyushkin, R. Riley, N. C. Abu-Ghazaleh, ECE, and D. Ponomarev, “BranchScope: A new side-channel attack on directional branch predic- tor,” ACM SIGPLAN Notices , vol. 53, no. 2, pp. 693–707, 2018

    2018

  15. [23]

    SpectreGuard: An efficient data- centric defense mechanism against Spectre attacks,

    J. Fustos, F. Farshchi, and H. Yun, “SpectreGuard: An efficient data- centric defense mechanism against Spectre attacks,” in Proceedings of the 56th Annual Design Automation Conference 2019 , 2019, pp. 1–6

    2019

  16. [24]

    Morpheus: A vulnerability-tolerant secure architecture based on ensembles of moving target defenses with churn,

    M. Gallagher, L. Biernacki, S. Chen, Z. B. Aweke, S. F. Yitbarek, M. T. Aga, A. Harris, Z. Xu, B. Kasikci, V . Bertacco et al. , “Morpheus: A vulnerability-tolerant secure architecture based on ensembles of moving target defenses with churn,” in Proceedings of the Twenty-Fourt...

    2019

  17. [25]

    Lazarus: Practical side-channel resilient kernel-space randomization,

    D. Gens, O. Arias, D. Sullivan, C. Liebchen, Y . Jin, and A.-R. Sadeghi, “Lazarus: Practical side-channel resilient kernel-space randomization,” in Research in Attacks, Intrusions, and Defenses: 20th International Symposium, RAID 2017, Atlanta, GA, USA, September 18–20, 2017, ...

    2017

  18. [26]

    Preventing kernel code-reuse attacks through disclosure resistant code diversification,

    J. Gionta, W. Enck, and P. Larsen, “Preventing kernel code-reuse attacks through disclosure resistant code diversification,” in 2016 IEEE Conference on Communications and Network Security (CNS) . IEEE, 2016, pp. 189–197. 15

    2016

  19. [27]

    Spec- ulative probing: Hacking blind in the spectre era,

    E. Göktas, K. Razavi, G. Portokalidis, H. Bos, and C. Giuffrida, “Spec- ulative probing: Hacking blind in the spectre era,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, 2020, pp. 1871–1885

    2020

  20. [28]

    Translation leak-aside buffer: Defeating cache side-channel protections with TLB attacks,

    B. Gras, K. Razavi, H. Bos, and C. Giuffrida, “Translation leak-aside buffer: Defeating cache side-channel protections with TLB attacks,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018, pp. 955–972

    2018

  21. [29]

    ASLR on the line: Practical cache attacks on the MMU

    B. Gras, K. Razavi, E. Bosman, H. Bos, and C. Giuffrida, “ASLR on the line: Practical cache attacks on the MMU.” in NDSS, vol. 17, 2017, p. 26

    2017

  22. [30]

    KASLR is dead: Long live KASLR,

    D. Gruss, M. Lipp, M. Schwarz, R. Fellner, C. Maurice, and S. Mangard, “KASLR is dead: Long live KASLR,” in Engineering Secure Software and Systems: 9th International Symposium, ESSoS 2017, Bonn, Ger- many, July 3-5, 2017, Proceedings 9 . Springer, 2017, pp. 161–176

    2017

  23. [31]

    Prefetch side- channel attacks: Bypassing SMAP and kernel ASLR,

    D. Gruss, C. Maurice, A. Fogh, M. Lipp, and S. Mangard, “Prefetch side- channel attacks: Bypassing SMAP and kernel ASLR,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 368–379

    2016

  24. [32]

    Hardware-software contracts for secure speculation,

    M. Guarnieri, B. Köpf, J. Reineke, and P. Vila, “Hardware-software contracts for secure speculation,” in 2021 IEEE Symposium on Security and Privacy (SP) . IEEE, 2021, pp. 1868–1883

    2021

  25. [33]

    x86/pie: Make kernel image’s virtual address flexible,

    W. Hou, T. Garnier, and B. Gerst, “x86/pie: Make kernel image’s virtual address flexible,” https://lore.kernel.org/lkml/cover.1682673542. git.houwenlong.hwl@antgroup.com/, 2023

    2023

  26. [34]

    Practical timing side channel attacks against kernel space ASLR,

    R. Hund, C. Willems, and T. Holz, “Practical timing side channel attacks against kernel space ASLR,” in 2013 IEEE Symposium on Security and Privacy. IEEE, 2013, pp. 191–205

    2013

  27. [35]

    Pointer authentication on ARMv8.3: Design and analysis of the new software security instructions,

    Inc. Qualcomm Technologies, “Pointer authentication on ARMv8.3: Design and analysis of the new software security instructions,” https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/ documents/pointer-auth-v7.pdf, 2017

    2017

  28. [36]

    Intel® 64 and IA-32 architectures software developer’s manual volume 3 (3a, 3b, 3c & 3d): System programming guide,

    C. Intel, “Intel® 64 and IA-32 architectures software developer’s manual volume 3 (3a, 3b, 3c & 3d): System programming guide,”Denver,[2006], 2022

    2006

  29. [37]

    Kernel address space layout randomization,

    Jake Edge, “Kernel address space layout randomization,” https://lwn.net/ Articles/569635/, 2013

    2013

  30. [38]

    Breaking kernel address space layout randomization with Intel TSX,

    Y . Jang, S. Lee, and T. Kim, “Breaking kernel address space layout randomization with Intel TSX,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , 2016, pp. 380–392

    2016

  31. [39]

    Exploiting CVE-2022-42703 - bringing back the stack attack,

    S. Jenkins, “Exploiting CVE-2022-42703 - bringing back the stack attack,” https://googleprojectzero.blogspot.com/2022/12/ exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html, 2022

    2022

  32. [40]

    SafeSpec: Banishing the Spectre of a Meltdown with leakage-free speculation,

    K. N. Khasawneh, E. M. Koruyeh, C. Song, D. Evtyushkin, D. Pono- marev, and N. Abu-Ghazaleh, “SafeSpec: Banishing the Spectre of a Meltdown with leakage-free speculation,” in 2019 56th ACM/IEEE Design Automation Conference (DAC) . IEEE, 2019, pp. 1–6

    2019

  33. [41]

    DAWG: A defense against cache timing attacks in speculative execution processors,

    V . Kiriansky, I. Lebedev, S. Amarasinghe, S. Devadas, and J. Emer, “DAWG: A defense against cache timing attacks in speculative execution processors,” in 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2018, pp. 974–987

    2018

  34. [42]

    Speculative buffer overflows: Attacks and defenses,

    V . Kiriansky and C. Waldspurger, “Speculative buffer overflows: Attacks and defenses,” arXiv preprint arXiv:1807.03757 , 2018

    2018 arXiv

  35. [43]

    Spectre attacks: Exploiting speculative execution,

    P. Kocher, J. Horn, A. Fogh, , D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y . Yarom, “Spectre attacks: Exploiting speculative execution,” in 40th IEEE Symposium on Security and Privacy (S&P’19) , 2019

    2019

  36. [44]

    Spectre returns! speculation attacks using the return stack buffer,

    E. M. Koruyeh, K. N. Khasawneh, C. Song, and N. Abu-Ghazaleh, “Spectre returns! speculation attacks using the return stack buffer,” in 12th USENIX Workshop on Offensive Technologies (WOOT 18) , 2018

    2018

  37. [45]

    SpecCFI: Mitigating Spectre attacks using CFI in- formed speculation,

    E. M. Koruyeh, S. H. A. Shirazi, K. N. Khasawneh, C. Song, and N. Abu-Ghazaleh, “SpecCFI: Mitigating Spectre attacks using CFI in- formed speculation,” in 2020 IEEE Symposium on Security and Privacy (SP). IEEE, 2020, pp. 39–53

    2020

  38. [46]

    TagBleed: Breaking KASLR on the isolated kernel address space using tagged TLBs,

    J. Koschel, C. Giuffrida, H. Bos, and K. Razavi, “TagBleed: Breaking KASLR on the isolated kernel address space using tagged TLBs,” in 2020 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE, 2020, pp. 309–321

    2020

  39. [47]

    Finer grained kernel address space random- ization,

    Kristen Carlson Accardi, “Finer grained kernel address space random- ization,” https://lwn.net/Articles/811685/, 2020

    2020

  40. [48]

    Inferring fine-grained control flow inside SGX enclaves with branch shadowing,

    S. Lee, M.-W. Shih, P. Gera, T. Kim, H. Kim, and M. Peinado, “Inferring fine-grained control flow inside SGX enclaves with branch shadowing,” in 26th USENIX Security Symposium (USENIX Security 17) , 2017, pp. 557–574

    2017

  41. [49]

    Conditional spec- ulation: An effective approach to safeguard out-of-order execution against Spectre attacks,

    P. Li, L. Zhao, R. Hou, L. Zhang, and D. Meng, “Conditional spec- ulation: An effective approach to safeguard out-of-order execution against Spectre attacks,” in 2019 IEEE international symposium on high performance computer architecture (HPCA). IEEE, 2019, pp. 264–276

    2019

  42. [50]

    AMD prefetch attacks through power and time,

    M. Lipp, D. Gruss, and M. Schwarz, “AMD prefetch attacks through power and time,” in31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 643–660

    2022

  43. [51]

    Take a way: Exploring the security implications of AMD’s cache way predictors,

    M. Lipp, V . Hadži ´c, M. Schwarz, A. Perais, C. Maurice, and D. Gruss, “Take a way: Exploring the security implications of AMD’s cache way predictors,” in Proceedings of the 15th ACM Asia Conference on Computer and Communications Security , 2020, pp. 813–825

    2020

  44. [52]

    Meltdown: Reading kernel memory from user space,

    M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y . Yarom, and M. Hamburg, “Meltdown: Reading kernel memory from user space,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018

    2018

  45. [53]

    EntryBleed: A universal KASLR bypass against KPTI on Linux,

    W. Liu, J. Ravichandran, and M. Yan, “EntryBleed: A universal KASLR bypass against KPTI on Linux,” in Proceedings of the 12th International Workshop on Hardware and Architectural Support for Security and Privacy, 2023, pp. 10–18

    2023

  46. [54]

    DOLMA: Securing speculation with the principle of transient Non-Observability,

    K. Loughlin, I. Neal, J. Ma, E. Tsai, O. Weisse, S. Narayanasamy, and B. Kasikci, “DOLMA: Securing speculation with the principle of transient Non-Observability,” in 30th USENIX Security Symposium (USENIX Security 21) , 2021, pp. 1397–1414

    2021

  47. [55]

    The gem5 simulator: Version 20.0+,

    J. Lowe-Power, A. M. Ahmad, A. Akram, M. Alian, R. Amslinger, M. Andreozzi, A. Armejach, N. Asmussen, S. Bharadwaj, G. Black, G. Bloom, B. R. Bruce, D. R. Carvalho, J. Castrill’on, L. Chen, N. Derumigny, S. Diestelhorst, W. Elsasser, M. Fariborz, A. F. Farahani, P. Fotouhi, R....

    2007 arXiv

  48. [56]

    ASLR-Guard: Stopping address space leakage for code reuse attacks,

    K. Lu, C. Song, B. Lee, S. P. Chung, T. Kim, and W. Lee, “ASLR-Guard: Stopping address space leakage for code reuse attacks,” in Proceedings of the 22nd ACM SIGSAC conference on computer and communications security, 2015, pp. 280–291

    2015

  49. [57]

    ret2spec: Speculative execution using return stack buffers,

    G. Maisuradze and C. Rossow, “ret2spec: Speculative execution using return stack buffers,” in Proceedings of the 2018 ACM SIGSAC Confer- ence on Computer and Communications Security , 2018, pp. 2109–2122

    2018

  50. [58]

    Mangard, E

    S. Mangard, E. Oswald, and T. Popp, Power Analysis Attacks: Revealing the Secrets of Smart Cards. Springer Science & Business Media, 2008, vol. 31

    2008

  51. [59]

    Serberus: Protecting cryptographic code from Spectres at compile-time,

    N. Mosier, H. Nemati, J. C. Mitchell, and C. Trippel, “Serberus: Protecting cryptographic code from Spectres at compile-time,” in 2024 IEEE Symposium on Security and Privacy (SP) . Los Alamitos, CA, USA: IEEE Computer Society, may 2024, pp. 51–51. [Online]. Available: https://...

    2024

  52. [60]

    Adelie: con- tinuous address space layout re-randomization for Linux drivers,

    R. Nikolaev, H. Nadeem, C. Stone, and B. Ravindran, “Adelie: con- tinuous address space layout re-randomization for Linux drivers,” in Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems , 2022, pp. 483–498

    2022

  53. [61]

    PaX address space layout randomization (ASLR)

    PaX Team, “PaX address space layout randomization (ASLR).” http: //pax.grsecurity.net/docs/aslr.txt, 2003

    2003

  54. [62]

    Lord of the io_urings,

    J. Ravichandran and M. Wang, “Lord of the io_urings,” https://css.csail. mit.edu/6.5660/2023/projects/jravi-mi27950.pdf, Tech. Rep., 2022

    2023

  55. [63]

    Return-oriented programming: Systems, languages, and applications,

    R. Roemer, E. Buchanan, H. Shacham, and S. Savage, “Return-oriented programming: Systems, languages, and applications,” ACM Transactions on Information and System Security (TISSEC) , vol. 15, no. 1, pp. 1–34, 2012

    2012

  56. [64]

    CleanupSpec: An

    G. Saileshwar and M. K. Qureshi, “CleanupSpec: An "undo" approach to safe speculation,” in Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture , 2019, pp. 73–86. 16

    2019

  57. [65]

    Ghost loads: What is the cost of invisible speculation?

    C. Sakalis, M. Alipour, A. Ros, A. Jimborean, S. Kaxiras, and M. Sjä- lander, “Ghost loads: What is the cost of invisible speculation?” in Proceedings of the 16th ACM International Conference on Computing Frontiers, 2019, pp. 153–163

    2019

  58. [66]

    Efficient invisible speculative execution through selective delay and value prediction,

    C. Sakalis, S. Kaxiras, A. Ros, A. Jimborean, and M. Själander, “Efficient invisible speculative execution through selective delay and value prediction,” in Proceedings of the 46th International Symposium on Computer Architecture, 2019, pp. 723–735

    2019

  59. [67]

    Store-to-Leak Forwarding: Leaking data on Meltdown-resistant cpus (updated and extended version),

    M. Schwarz, C. Canella, L. Giner, and D. Gruss, “Store-to-Leak Forwarding: Leaking data on Meltdown-resistant cpus (updated and extended version),” arXiv preprint arXiv:1905.05725 , 2019

    1905 arXiv

  60. [68]

    ConTExT: A generic approach for mitigating Spectre,

    M. Schwarz, M. Lipp, C. A. Canella, R. Schilling, F. Kargl, and D. Gruss, “ConTExT: A generic approach for mitigating Spectre,” in Network and Distributed System Security Symposium 2020 , 2020

    2020

  61. [69]

    Net- Spectre: Read arbitrary memory over network,

    M. Schwarz, M. Schwarzl, M. Lipp, J. Masters, and D. Gruss, “Net- Spectre: Read arbitrary memory over network,” in Computer Security– ESORICS 2019: 24th European Symposium on Research in Computer Security, Luxembourg, September 23–27, 2019, Proceedings, Part I 24 . Springer, 2...

    2019

  62. [70]

    IOHIDeous,

    Siguza, “IOHIDeous,” https://blog.siguza.net/IOHIDeous/, 2017

    2017

  63. [71]

    MicroScope: enabling microarchitectural replay attacks,

    D. Skarlatos, M. Yan, B. Gopireddy, R. Sprabery, J. Torrellas, and C. W. Fletcher, “MicroScope: enabling microarchitectural replay attacks,” in Proceedings of the 46th International Symposium on Computer Archi- tecture, 2019, pp. 318–331

    2019

  64. [72]

    SoK: Eternal war in memory,

    L. Szekeres, M. Payer, T. Wei, and D. Song, “SoK: Eternal war in memory,” in 2013 IEEE Symposium on Security and Privacy . IEEE, 2013, pp. 48–62

    2013

  65. [73]

    An info-leak resistant kernel ran- domization for virtualized systems,

    F. Vano-Garcia and H. Marco-Gisbert, “An info-leak resistant kernel ran- domization for virtualized systems,” IEEE Access, vol. 8, pp. 161 612– 161 629, 2020

    2020

  66. [74]

    KASLR-MT: Kernel address space layout randomization for multi-tenant cloud systems,

    ——, “KASLR-MT: Kernel address space layout randomization for multi-tenant cloud systems,” Journal of Parallel and Distributed Com- puting, vol. 137, pp. 77–90, 2020

    2020

  67. [75]

    Hertzbleed: Turning power Side-Channel attacks into remote timing attacks on x86,

    Y . Wang, R. Paccagnella, E. T. He, H. Shacham, C. W. Fletcher, and D. Kohlbrenner, “Hertzbleed: Turning power Side-Channel attacks into remote timing attacks on x86,” in 31st USENIX Security Symposium (USENIX Security 22) , 2022, pp. 679–697

    2022

  68. [76]

    Osiris: Automated discovery of microarchitectural side channels,

    D. Weber, A. Ibrahim, H. Nemati, M. Schwarz, and C. Rossow, “Osiris: Automated discovery of microarchitectural side channels,” in 30th USENIX Security Symposium (USENIX Security 21) , 2021, pp. 1415– 1432

    2021

  69. [77]

    NDA: Preventing speculative execution attacks at their source,

    O. Weisse, I. Neal, K. Loughlin, T. F. Wenisch, and B. Kasikci, “NDA: Preventing speculative execution attacks at their source,” in Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, 2019, pp. 572–586

    2019

  70. [78]

    Phantom: Exploiting decoder- detectable mispredictions,

    J. Wikner, D. Trujillo, and K. Razavi, “Phantom: Exploiting decoder- detectable mispredictions,” in MICRO Conference 2023, 2023

    2023

  71. [79]

    InvisiSpec: Making speculative execution invisible in the cache hierarchy,

    M. Yan, J. Choi, D. Skarlatos, A. Morrison, C. Fletcher, and J. Tor- rellas, “InvisiSpec: Making speculative execution invisible in the cache hierarchy,” in 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2018, pp. 428–441

    2018

  72. [80]

    Data oblivious ISA extensions for side channel-resistant and high performance computing,

    J. Yu, L. Hsiung, M. El Hajj, and C. W. Fletcher, “Data oblivious ISA extensions for side channel-resistant and high performance computing,” Cryptology ePrint Archive , 2018

    2018

  73. [81]

    Spec- ulative data-oblivious execution: Mobilizing safe prediction for safe and efficient speculative execution,

    J. Yu, N. Mantri, J. Torrellas, A. Morrison, and C. W. Fletcher, “Spec- ulative data-oblivious execution: Mobilizing safe prediction for safe and efficient speculative execution,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA) . IEEE, 2020...

    2020

  74. [82]

    Speculative taint tracking (STT): A comprehensive protection for speculatively accessed data,

    J. Yu, M. Yan, A. Khyzha, A. Morrison, J. Torrellas, and C. W. Fletcher, “Speculative taint tracking (STT): A comprehensive protection for speculatively accessed data,” in Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture , 2019, pp. 954–968

    2019

  75. [83]

    SonicBOOM: The 3rd generation Berkeley Out-of-Order Machine,

    J. Zhao, B. Korpan, A. Gonzalez, and K. Asanovic, “SonicBOOM: The 3rd generation Berkeley Out-of-Order Machine,” May 2020

    2020

  76. [84]

    Binoculars: Contention-Based Side-Channel attacks exploiting the page walker,

    Z. N. Zhao, A. Morrison, C. W. Fletcher, and J. Torrellas, “Binoculars: Contention-Based Side-Channel attacks exploiting the page walker,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 699– 716

    2022

  77. [85]

    LEBench-Sim: A Benchmark Suite for Large-Eddy Simu- lation,

    Zirui Zhao, “LEBench-Sim: A Benchmark Suite for Large-Eddy Simu- lation,” https://github.com/zzrcxb/LEBench-Sim, 2022. APPENDIX A ARTIFACT APPENDIX A. Description & Requirements

    2022

  78. [86]

    The source code of our implementation and experiments is available at https://github.com/CSAIL-Arch-Sec/Oreo

    How to access: The artifact for reproducing the results in the paper is at https://doi.org/10.5281/zenodo.14261065. The source code of our implementation and experiments is available at https://github.com/CSAIL-Arch-Sec/Oreo

    doi

  79. [87]

    Each gem5 instance needs 1 core and 2 GBmemory

    Hardware dependencies: The artifact utilizes the gem5 simulator (v24.0) [9], [55] to emulate Linux and execute benchmarks in full-system mode, requiring only CPU, mem- ory, and disk resources. Each gem5 instance needs 1 core and 2 GBmemory. The artifact’s resources, including ...

  80. [88]

    It also requires Docker Engine (v24+) and Docker Compose (v1.29+) to run all the experiments

    Software dependencies: The artifact requires Vagrant (v2.4) and VirtualBox (v7.0) to build a disk image for running experiments in gem5 full-system mode. It also requires Docker Engine (v24+) and Docker Compose (v1.29+) to run all the experiments

  81. [89]

    LEBench is included in the artifact source, while SPEC 2017 is not included because of copyright issues

    Benchmarks: Reproducing the performance evaluation results requires SPEC 2017 benchmark [11] and LEBench benchmark [85]. LEBench is included in the artifact source, while SPEC 2017 is not included because of copyright issues. B. Artifact Installation & Configuration

    2017

  82. [90]

    It should be placed in the artifact folder

    Pre-setup: In the artifact folder, run the following com- mand to clone the git submodules: $ git submodule update --init --recursive Note that cpu2017-1.1.9.iso is the official image for SPEC 2017 benchmark, which is not released with the artifact since it is not open-source....

    2017

  83. [91]

    17 In the host’s shell and in folder artifact, run the following commands to build the disk image, which takes about 1 hour

    Build: In folder artifact, set up and enter the docker by running: $ cd linux $ docker-compose up -d $ docker-compose exec x86_fs /bin/bash In the docker’s shell, build Linux and gem5 by running: $ cd /root/linux $ python3 compile_scripts/compile.py --num-cores=80 $ cd /root/g...

    2017

  84. [92]

    ASLR violation

    Experiment (E1): [Functional Test] [1 human-minute + 10 compute-minutes]: This experiment runs two user pro- grams hello and hello_invalid, whose source code can be found in /root/experiments/disk-image/experiments/ experiments/src. This experiment demonstrates that Oreo allow...

  85. [93]

    Experiment (E2): [Performance Evaluation with SPEC 2017] This experiment evaluates Oreo’s performance against the baseline using SPEC 2017 Intrate Benchmarks. In our original setup, we warm up the system and microarchitecture structures by executing 10 billion user-space instr...

    2017

  86. [94]

    We ran the benchmark multiple times and used the aver- age latency across all iterations as the final measurement

    Experiment (E3): [Performance Evaluation] [1 human- minute + 8 compute-hours]: This experiment evaluates Oreo’s performance against the baseline using LEBench, which mea- sures and reports the average latency of various system calls. We ran the benchmark multiple times and use...

  87. [95]

    • Leakage path 1 : we use the speculative code region attack as a representative example of the leakage path 1

    Experiment (E4): [Security Evaluation] [5 human- minute + 10 compute-minutes]: This experiment consists of three parts: • The Prefetch Attack. • Leakage path 1 : we use the speculative code region attack as a representative example of the leakage path 1 . We demonstrate that s...

  88. [96]

    This is used to evaluate whether the benchmark is relevant to measure the performance impact of Oreo

    Experiment (E5): This experiment reports the ratio of memory accesses where Oreo applies its protection (i.e., the masked ratio). This is used to evaluate whether the benchmark is relevant to measure the performance impact of Oreo. [Results] The masked ratio of SPEC 2017 bench...

    2017

  89. [97]

    Based on the initialization operation, we also have Obsµ(S0) = Obsµ(S′ 0)

    and Ptw(w, P T0) = Ptw(w, P T′ 0). Based on the initialization operation, we also have Obsµ(S0) = Obsµ(S′ 0). Hence, S0 =pub S′ 0. • The induction step ( Sk =pub S′ k ⇒ Sk+1 =pub S′ k+1): By the induction assumption, we know for all w, Trans(w, P Tk) = Trans(w, P T′ k) and Ptw...

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.