Pith. sign in

REVIEW 4 major objections 4 minor 34 references

PTSan: A Practical Memory Safety Sanitizer for C/C++ with Pointer-Object Authority

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

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

Pith's one-line read PTSan claims that pointer-based object-authority checking can run at location-based-sanitizer cost — 57.2% average runtime overhead on SPEC CPU 2017 with near-native memory — while catching inter-object and temporal errors that address-vali

desk verdict Pointer-based sanitizer closes much of the cost gap, but the headline 57.2% includes ID-exhausting SPEC benchmarks where the core guarantee already fell back to shared IDs — still worth serious review, with a required qualification. read the letter →

arxiv 2607.19246 v1 pith:E5QDMR7Z submitted 2026-07-21 cs.CR

Eli Davis , Eric Lahtinen , Michael Gordon This is my paper · ORCID
classification cs.CR
keywords memorysafetysanitizerpointer-basedcheckingobjectauthoritytaggedpointersboundsuse-after-freeLLVMinstrumentationIntelLAM
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

The paper tries to close the long-standing cost gap between the two families of C/C++ memory-safety sanitizers: address-validity checkers are cheap but accept any access that lands in mapped memory, while pointer-based checkers that bind each pointer to its allocation catch the redirect-into-another-live-object class of bugs but have historically cost two to three times as much in runtime and memory. PTSan's proposal is a representation change: carry a 16-bit object identifier in the high bits of every pointer, and keep that object's base and span in a flat, fixed-size table indexed by the ID. Because the ID rides in the pointer value, ordinary compiler dataflow propagates it for free, and the residual check work at a dereference stays as ordinary LLVM IR that the optimizer can hoist, merge, and elide, with a min-cut placement scheme for the software strips that remove IDs at compatibility boundaries. If the measurements are right, the payoff is pointer-based checking at 57.2% geomean runtime overhead on SPEC CPU 2017 on stock x86-64 (46.4% with Intel LAM, 54.7% on ARM64), 1.014x physical memory, and full inter-object and temporal detection coverage on an independent test suite. The price is a hard budget of 2^16 live objects (2^15 with LAM), and the paper's own footnote 1 concedes that 7 of 17 SPEC benchmarks exceed it yet remain in the headline number.

What carries the argument

The central object is the tagged pointer: 16 bits of object ID in bits 63–48 of a 64-bit pointer, canonical address in the low 48 bits, indexing a flat runtime table that stores each object's base and span, with entries cleared at free. Three properties do the work. Identity propagation is free: because the ID is part of the pointer value, copies, PHI nodes, selects, loads/stores, and address arithmetic carry it without per-pointer shadow metadata. The residual work at an access — shift out the ID, load bounds, compare the entire access range — stays ordinary LLVM IR with bounds loads kept separable from the checks, so the optimizer hoists, merges, and elides checks, and a whole-function min

What would settle it

Run a workload that keeps more than 2^16 small allocations alive simultaneously (Table 2 shows several SPEC benchmarks do) in strict mode and check whether the program actually stops at the 65,537th live object rather than continuing through a fallback ID; then repeat on a 5-level-paging kernel and check whether addresses above 2^48 corrupt the ID field. For the temporal claim, cycle the FIFO ID ring and re-tenant a freed address, then dereference the stale pointer: the paper predicts the access passes once the old ID is recycled, and a demonstration would pin down the probabilistic boundary.

Watch

Extended reading notes

Core claim

PTSan's central claim: object-authority checking need not pay for per-pointer metadata propagation. A 16-bit object ID in the upper bits of each 64-bit pointer indexes a flat bounds table, so identity rides in the pointer value through ordinary dataflow, and a dereference needs only one interval-containment check. Because that check is plain LLVM IR with separable bounds loads, the compiler hoists, merges, and elides checks and turns loop checks into preheader range checks; Intel LAM removes remaining tag strips in hardware. The trade is a finite live-object budget (2^16 IDs; 2^15 with LAM), covering 91% of a 167-program suite in the paper's measurements. On an independent safety test suite,

Load-bearing premise

The load-bearing premise is the 2^16 live-object budget (2^15 with LAM): the paper's own footnote 1 concedes that 7 of 17 SPEC benchmarks exceed it and remain in the headline 57.2% aggregate, so the object-authority guarantee holds only for programs that stay within the budget — enforced by failing closed when it is exceeded — and whose addresses stay in the low 48 bits, which 5-level paging would break.

Editorial extensions

If this is right

  • Recompile-only deployment: PTSan is a compiler flag plus a static runtime, so pointer-based checking can be adopted with no source changes, no new ABI, and no custom allocator — and none of the redzones, shadow memory, or quarantine that triple memory use in location-based tools.
  • Cost parity: 57.2% geomean runtime overhead on SPEC CPU 2017 on stock x86-64 (46.4% with LAM, 54.7% on ARM64) is roughly a third of the published overhead of prior pointer-based systems with comparable guarantees.
  • A previously undetectable error class becomes checkable: inter-object out-of-bounds accesses that land inside another live object — the shape of the paper's ImageMagick example — are caught, something an address-validity check cannot express.
  • Near-native memory: 1.014x geomean peak physical memory on SPEC, with a fixed ~1.2 MiB metadata footprint, is the property that makes deployment in memory-constrained fleets plausible.
  • A measurable scope of applicability: 91% of a 167-program suite fits the 2^16 live-object budget, peak ID demand is cheap to measure in advance, and strict mode fails closed on exhaustion rather than silently weakening the guarantee.

Reading between the lines

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

  • The headline 57.2% aggregate is broader than the guarantee: footnote 1 concedes that 7 of 17 SPEC benchmarks exceed the 2^16 live-object budget and are included in the aggregate, so an in-budget-only geomean would be the cleaner statement of the strong-guarantee cost; the paper does not report one.
  • The temporal guarantee is the probabilistic edge the paper concedes: once the FIFO ID ring cycles, a stale pointer passes if a replacement object re-tenants its address with the same ID. Randomizing ID reuse — the paper lists it as future work — would harden this, and an attacker who can drive allocations could probe whether the deterministic ring is observable.
  • The representation is tied to the 48-bit address-space layout: on 5-level-paging kernels user addresses reach 56 bits and the 16-bit tag disappears, so the design's shelf life depends on that memory model persisting or on tag-preserving hardware masking arriving.
  • The LAM numbers are prospective: the 46.4% figure requires a custom kernel, because mainline Linux's LAM U57 variant masks too few bits, so production use of that configuration is blocked on kernel and hardware maturity rather than on the sanitizer itself.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. PTSan is an LLVM sanitizer that stores a 16-bit object ID in the high bits of 64-bit pointers, indexing a flat bounds table, and performs pointer-based (object-authority) range checks before memory accesses. The paper argues that this representation eliminates per-pointer metadata propagation, keeps checks as ordinary LLVM IR amenable to hoisting/merging/elision, and uses a min-cut placement of tag strips. It reports 57.2% geomean runtime overhead on SPEC CPU 2017 on stock x86-64 (46.4% with Intel LAM, 54.7% on ARM64), 31.5% on LLVM MultiSource, near-native physical memory (1.014x), and MSET detection coverage matching the original SoftBound+CETS results for inter-object and temporal bugs. The paper includes a security analysis under attacker levels and bug primitives, an optimization ablation, and open-source release.

Significance. If the central claims hold, PTSan would be a notable advance: it offers a pointer-identity checking model—which catches inter-object overflows that location-based sanitizers miss—at overhead close to redzone sanitizers, with near-native memory. The design is creative: embedding the object ID in the pointer and exposing checks as optimizable IR is a genuinely different point in the design space. The evaluation is broad (SPEC, MultiSource, MSET, server workloads, two ISAs) and the paper is honest in its footnotes about ID-budget and stack-temporal caveats. The open-source release is a concrete strength. However, the headline numbers as presented do not cleanly correspond to the strong-guarantee configuration, and several claims need re-scoping before the paper can be accepted.

major comments (4)
  1. [§8.2.1, Table 2, Footnote 1] The headline 57.2% SPEC geomean includes 7 benchmarks that exceed the 2^16 live-object budget (500.perlbench, 502.gcc, 520.omnetpp, 523.xalancbmk, 510.parest, 526.blender, 544.nab). Section 8.3.1 states that in this regime PTSan 'falls back to shared IDs and protection degrades for the affected objects,' so the object-authority guarantee is not in force for these workloads. Including them in the same aggregate as SoftBound+CETS/CUP comparisons overstates the cost of the claimed security property. Recomputing the geomean over the 10 in-budget benchmarks gives roughly 51%, not 57.2%. The abstract and conclusion should present the in-budget geomean as the primary result, with the full-suite number explicitly labeled as an upper-bound instrumentation-cost estimate.
  2. [§8.4, Table 4, Footnote 3] The MSET temporal coverage result (16/16 UAF/UAR, all temporal buckets) requires the non-default flag -ptsan-stack-temporal-safety, which adds ~3% overhead (Table 10: x86 geomean goes from 57.1% to 61.2%). The runtime-overhead headline uses the default stack-ID handling, which reuses stack IDs immediately and does not clear bounds entries at function exit. Thus the paper's claim of simultaneously achieving 57.2% overhead and full MSET temporal coverage is not accurate for a single configuration. The abstract and Section 8.4 should state which configuration produced each number and report the default-configuration temporal coverage separately.
  3. [§6.2, §5.1] The local preservation rule is stated but not proved. Section 6.2 asserts that check elision, merging, and hoisting 'preserve the security of the original unoptimized transformation' (Section 5.1), and Section 5.5 says imprecision 'costs performance, not safety.' However, the paper provides no theorem, induction, or machine-checked argument for the rule. Since the central contribution is a security guarantee with optimizer transformations, a rigorous proof (or a precise formal statement of the rule and its hypotheses) is needed, not just an informal clause list. Without it, the 'safety is preserved under optimization' claim is unsupported.
  4. [§3.1, §4.1] The low-48-bit address assumption is stated, but the paper does not address 5-level paging (LA57), where user virtual addresses can occupy up to 56 bits, leaving no room for a 16-bit tag. Since the paper targets 'stock x86-64' and commodity kernels, this is a deployment limitation that should be explicitly discussed, even if the assumption is valid on default 4-level paging configurations.
minor comments (4)
  1. [Abstract/Conclusion] The abstract and conclusion report 57.2% without the Footnote 1 qualification. Please qualify the number as including ID-exhausting workloads, or move the in-budget number to the front.
  2. [Table 10] The negative overheads for 544.nab with stack temporal protection enabled (-27.3% / -21.2%) are surprising and should be explained; they appear to be noise or a warm-up effect and should be pinned down or removed.
  3. [§8.1] The RSan comparison is on a 13-benchmark subset with its own baseline, while PTSan is compared on 17 benchmarks. This asymmetry should be stated clearly near the comparison, even though the paper does acknowledge it later.
  4. [§5.3] The discussion of pointer-forgery says a passing forgery requires a correct identifier-address pair, but the analysis would benefit from a proof sketch of why an overflowing P2 offset that accidentally produces a valid ID cannot bypass the check except in the A1 case.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; overhead and coverage claims rest on external benchmarks and disclosed assumptions.

full rationale

PTSan's central claims are empirical and externally anchored. Runtime overhead is measured against SPEC CPU 2017, LLVM MultiSource, and Phoronix workloads; memory overhead is measured via cgroup memory.peak; detection coverage is measured against the independent MSET suite and compared with published SoftBound+CETS rows. No parameter is fitted to a subset of these data and then reported as a prediction: the 57.2%/54.7%/46.4% overhead numbers and 1.014x memory figure are direct measurements, and the ablation (Table 5) is a set of additional measurements, not a derivation from the target result. The check formula in Section 4.4 is the definition of range containment and is implemented as stated, so it is not a case of defining X in terms of Y. The finite live-object budget is an explicitly stated assumption (Sections 3.1, 4.1), and the paper measures ID pressure and discloses the consequences of exhaustion: footnote 1 says ID-exhausting SPEC runs "fall outside PTSan's strong-guarantee regime", and Section 8.3.1 says PTSan "falls back to shared IDs and protection degrades for the affected objects". These are honest scope limitations and correctness/interpretation caveats, not circular reasoning: the aggregate overhead is still a measurement, even if it does not represent the cost of the strong guarantee on those 7 benchmarks. The only self-reference is the future-work mention of CodeHawk-C [34], which does not support the paper's central overhead, memory, or coverage claims. Accordingly there is no load-bearing self-citation, no fitted-input-called-prediction, and no derivation that reduces to its own inputs.

Assumptions & free parameters 2 free parameters · 7 assumptions · 0 invented entities

PTSan's guarantees rest primarily on the 48-bit address space / finite-ID budget and on the correctness of the LLVM analyses and the informal preservation rule. No external fitted constants are used; the only hand-chosen numeric parameters are the ID budget and the min-cut cost weights.

free parameters (2)
  • Live-object ID budget = 2^16 default; 2^15 with LAM
    Chosen because glibc malloc returns addresses in the low 48-bit space, leaving 16 high pointer bits (Section 4.1). This finite budget is the central scalability tradeoff; 7/17 SPEC benchmarks exceed it (Table 2), degrading the guarantee for those runs.
  • Min-cut conversion costs (tag vs strip) = tag cost=1, strip cost=2, loop-depth exponential
    Hand-chosen weights in the Section 6.7 polarity min-cut. They determine where strips/retags are placed and materially affect reported overhead; no sensitivity analysis is given.
assumptions (7)
  • domain assumption Program addresses fit in the low 48 bits and glibc malloc returns addresses there.
    Invoked in Section 4.1 to justify the 16-bit ID field; false under 5-level paging or non-default ABIs that use higher bits, shrinking the ID space.
  • domain assumption At most 2^16 (or 2^15 with LAM) simultaneously live allocation objects.
    Assumption 1 in Section 3.1; central to ID uniqueness. Empirically violated by 7/17 SPEC benchmarks (Table 2), where strict mode would fail closed or permissive mode degrades.
  • domain assumption Toolchain and instrumentation are correct and complete; all allocations/deallocations/accesses are instrumented or intercepted.
    Section 3.1; completeness is acknowledged as the practical limit. Uninstrumented code receiving stripped pointers is outside the guarantee (Section 5.5).
  • domain assumption LLVM analyses (dominance, postdominance, loop info, TLI, Scalar Evolution) are correct.
    Section 6 intro: optimizations rely on these; imprecision is claimed to cost performance, not safety.
  • ad hoc to paper The local preservation rule guarantees that elided/hoisted/merged checks cover the same accesses with compatible metadata.
    Section 6.2 states the rule and asserts all optimizations instantiate it, but no machine-checked proof is provided; a violation would break the safety claim.
  • domain assumption ASLR is enabled and the attacker cannot predict identifier assignment (for A2/A3).
    Section 3.1/3.2; temporal and forgery analysis depends on ASLR and unpredictable ID assignment.
  • domain assumption The program is free of data races between freeing an object and accessing it in another thread (for temporal claims).
    Section 3.1; racy use-after-free is explicitly placed outside the temporal guarantee.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PTSan: A Practical Memory Safety Sanitizer for C/C++ with Pointer-Object Authority." pith.science (2026). https://pith.science/paper/E5QDMR7Z

@misc{pith2026260719246,
  author       = {Pith},
  title        = {Pith review of: PTSan: A Practical Memory Safety Sanitizer for C/C++ with Pointer-Object Authority},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/E5QDMR7Z}},
  note         = {Machine review of arXiv:2607.19246}
}
read the original abstract

Memory safety errors remain the dominant source of severe vulnerabilities in C and C++. Pointer-based sanitizers provide stronger guarantees than location-based tools such as LLVM's ASan, but their overhead and compatibility limitations have constrained production use. We present PTSan, an LLVM sanitizer that makes pointer-based checking practical by storing an object identifier in each pointer's high bits and its bounds in a fixed-size runtime table. This representation trades a finite live-object budget for low overhead, optimizer visibility, and commodity-hardware support. Because identity travels with the pointer value, ordinary LLVM dataflow propagates it without explicit per-pointer metadata instructions. Separating metadata lookup from check enforcement exposes both as LLVM IR, enabling check hoisting, elision, and merging, plus whole-function min-cut placement of compatibility tag strips. Intel Linear Address Masking eliminates the remaining strips in hardware when available. On stock hardware PTSan runs at parity with the fastest published location-based sanitizer: 57.2% geomean overhead on SPEC CPU 2017 on x86-64 (46.4% with Intel LAM), 54.7% on ARM64, and 31.5% (x86-64) on the application-shaped LLVM MultiSource suite. This is roughly a third of the published overhead percentage of prior systems with similar pointer-object authority guarantees, while preserving the inter-object, non-object, and temporal detection coverage measured by an independent memory safety test suite. Its physical-memory overhead is effectively native, a critical property for production deployment as memory costs become a first-order constraint. We also demonstrate practical overhead on real-world server and security workloads. These results show that PTSan brings practical pointer-based memory safety into a recompile-only sanitizer deployment model.

Figures

Figures reproduced from arXiv: 2607.19246 by the authors.

Figure 1
Figure 1. PTSan pointer layout: the 16-bit object ID indexes a flat table of [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. ID-strip hoisting. Finite labels are capacities: strip and tag cost 1 and 2, respectively, multiplied by 4 per loop level. The base placement in [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
Figure 3
Figure 3. Construction of the polarity min-cut graph. Pointer SSA values [PITH_FULL_IMAGE:figures/full_fig_p011_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Distribution of PTSan runtime overhead over the measured LLVM [PITH_FULL_IMAGE:figures/full_fig_p019_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

34 extracted references · 3 linked inside Pith

  1. [1]

    The Urgent Need for Memory Safety in Software Products

    Cybersecurity and Infrastructure Security Agency. The Urgent Need for Memory Safety in Software Products. Sept. 20, 2023.URL:https : / / www . cisa . gov / news - events / news / urgent - need - memory - safety - software - products(visited on 05/04/2026)

    2023

  2. [2]

    chromium

    Chromium Project.Memory Safety.URL:https:// www . chromium . org / Home / chromium - security / memory-safety/(visited on 05/04/2026)

    2026

  3. [3]

    SoK: Eternal War in Memory

    Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song. “SoK: Eternal War in Memory”. In:2013 IEEE Symposium on Security and Privacy. 2013

    2013

  4. [4]

    SoK: Sanitizing for Security

    Dokyung Song, Julian Lettner, Prabhu Rajasekaran, Yeoul Na, Stijn V olckaert, Per Larsen, and Michael Franz. “SoK: Sanitizing for Security”. In:2019 IEEE Symposium on Security and Privacy. 2019

    2019

  5. [5]

    LLM Agents Can Autonomously Exploit One-day Vulnerabilities

    Richard Fang, Rohan Bindu, Akul Gupta, and Daniel Kang. “LLM Agents Can Autonomously Exploit One-day Vulnerabilities”. In:CoRRabs/2404.08144 (2024). arXiv:2404.08144

    arXiv 2024

  6. [6]

    Teams of LLM Agents Can Exploit Zero-Day Vulnerabilities

    Richard Fang, Rohan Bindu, Akul Gupta, Qiusi Zhan, and Daniel Kang. “Teams of LLM Agents Can Exploit Zero-Day Vulnerabilities”. In:CoRR abs/2406.01637 (2024). arXiv:2406.01637

    arXiv 2024

  7. [7]

    AddressSanitizer: A Fast Address Sanity Checker

    Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. “AddressSanitizer: A Fast Address Sanity Checker”. In:2012 USENIX Annual Technical Conference. 2012

    2012

  8. [8]

    RangeSani- tizer: Detecting Memory Errors with Efficient Range Checks

    Floris Gorter and Cristiano Giuffrida. “RangeSani- tizer: Detecting Memory Errors with Efficient Range Checks”. In:Proceedings of the 34th USENIX Secu- rity Symposium. 2025

    2025

Show all 34 references
  1. [9]

    SoftBound+CETS Revisited: More Than a Decade Later

    Benjamin Orthen, Oliver Braunsdorf, Philipp Zieris, and Julian Horsch. “SoftBound+CETS Revisited: More Than a Decade Later”. In:EuroSec ’24. 2024

    2024

  2. [10]

    CUP: Comprehensive User-Space Protection for C/C++

    Nathan Burow, Derrick McKee, Scott A. Carr, and Mathias Payer. “CUP: Comprehensive User-Space Protection for C/C++”. In:ASIACCS ’18. 2018

    2018

  3. [11]

    Intel Explore Design Center.URL:https : / / edc

    Intel Corporation.Linear Address Masking (LAM), Core Ultra Processor Series 3 Datasheet, V olume 1 of 2. Intel Explore Design Center.URL:https : / / edc . intel . com / content / www / us / en / design/platforms/core- processor- series- 3- datasheet - volume - 1 - of - 2 / lin...

    2026

  4. [12]

    Evaluating the Effectiveness of Memory Safety San- itizers

    Emanuel Q. Vintila, Philipp Zieris, and Julian Horsch. “Evaluating the Effectiveness of Memory Safety San- itizers”. In:2025 IEEE Symposium on Security and Privacy. 2025

    2025

  5. [13]

    SoftBound: Highly Compatible and Complete Spatial Memory Safety for C

    Santosh Nagarakatte, Jianzhou Zhao, Milo M. K. Martin, and Steve Zdancewic. “SoftBound: Highly Compatible and Complete Spatial Memory Safety for C”. In:PLDI. 2009

    2009

  6. [14]

    CETS: Compiler- Enforced Temporal Safety for C

    Santosh Nagarakatte, Jianzhou Zhao, Milo M. K. Martin, and Steve Zdancewic. “CETS: Compiler- Enforced Temporal Safety for C”. In:ISMM ’10. 2010

    2010

  7. [15]

    CVE-2025-57807.URL:https://nvd.nist

    National Vulnerability Database.CVE-2025-57807 Detail. CVE-2025-57807.URL:https://nvd.nist. gov / vuln / detail / CVE - 2025 - 57807(visited on 05/11/2026)

    2025

  8. [16]

    Linux kernel documentation

    The Linux Kernel Developers.Complete Virtual Memory Map (x86-64). Linux kernel documentation. URL:https : / / docs . kernel . org / arch / x86 / x86 64/mm.html(visited on 07/17/2026)

    2026

  9. [17]

    Data-Oriented Programming: On the Expressiveness of Non-Control Data Attacks

    Hong Hu, Shweta Shinde, Sendroiu Adrian, Zheng Leong Chua, Prateek Saxena, and Zhenkai Liang. “Data-Oriented Programming: On the Expressiveness of Non-Control Data Attacks”. In:2016 IEEE Sym- posium on Security and Privacy (SP). 2016

    2016

  10. [18]

    Smokestack: Thwarting DOP Attacks with Runtime Stack Layout Randomization

    Misiker Tadesse Aga and Todd Austin. “Smokestack: Thwarting DOP Attacks with Runtime Stack Layout Randomization”. In:CGO ’19. 2019

    2019

  11. [19]

    SaVioR: Thwarting Stack- Based Memory Safety Violations by Randomizing Stack Layout

    Seongman Lee, Hyeonwoo Kang, Jinsoo Jang, and Brent ByungHoon Kang. “SaVioR: Thwarting Stack- Based Memory Safety Violations by Randomizing Stack Layout”. In:IEEE Transactions on Dependable and Secure Computing19.4 (2022). 17

    2022

  12. [20]

    Algorithm for Solution of a Problem of Maximum Flow in a Network with Power Esti- mation

    E. A. Dinic. “Algorithm for Solution of a Problem of Maximum Flow in a Network with Power Esti- mation”. In:Soviet Mathematics Doklady11 (1970). English translation of Doklady Akademii Nauk SSSR 194(4):754–757

    1970

  13. [21]

    Leaky Address Masking: Exploiting Un- masked Spectre Gadgets with Noncanonical Address Translation

    Math ´e Hertogh, Sander Wiebing, and Cristiano Giuf- frida. “Leaky Address Masking: Exploiting Un- masked Spectre Gadgets with Noncanonical Address Translation”. In:2024 IEEE Symposium on Security and Privacy. 2024

    2024

  14. [22]

    LLVM Project.LLVM test-suite Guide.URL:https: //llvm.org/docs/TestSuiteGuide.html(visited on 06/09/2026)

    2026

  15. [23]

    Open-source automated benchmarking soft- ware.URL:https://www.phoronix- test- suite

    Michael Larabel and Matthew Tippett.Phoronix Test Suite. Open-source automated benchmarking soft- ware.URL:https://www.phoronix- test- suite. com/(visited on 06/11/2026)

    2026

  16. [24]

    WatchdogLite: Hardware-Accelerated Compiler-Based Pointer Checking

    Santosh Nagarakatte, Milo M. K. Martin, and Steve Zdancewic. “WatchdogLite: Hardware-Accelerated Compiler-Based Pointer Checking”. In:CGO ’14. 2014

    2014

  17. [25]

    Heap Bounds Protection with Low Fat Pointers

    Gregory J. Duck and Roland H. C. Yap. “Heap Bounds Protection with Low Fat Pointers”. In:CC

  18. [26]

    Stack Bounds Protection with Low Fat Pointers

    Gregory J. Duck, Roland H. C. Yap, and Lorenzo Cavallaro. “Stack Bounds Protection with Low Fat Pointers”. In:NDSS Symposium 2017. 2017

    2017

  19. [27]

    Delta Pointers: Buffer Overflow Checks Without the Checks

    Taddeus Kroes, Koen Koning, Erik van der Kouwe, Herbert Bos, and Cristiano Giuffrida. “Delta Pointers: Buffer Overflow Checks Without the Checks”. In: EuroSys ’18. 2018

    2018

  20. [28]

    Memory Tagging and how it improves C/C++ mem- ory safety

    Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, and Dmitry Vyukov. Memory Tagging and how it improves C/C++ mem- ory safety. 2018. arXiv:1802.09517

    2018 arXiv

  21. [29]

    White paper

    Arm Ltd.Armv8.5-A Memory Tagging Extension. White paper. 2019.URL:https://developer.arm. com / documentation / 102925 / latest/(visited on 06/10/2026)

    2019

  22. [30]

    org/ (visited on 05/05/2026)

    Fil-C Project.Fil-C.URL:https : / / fil - c . org/ (visited on 05/05/2026)

    2026

  23. [31]

    org / invisicaps (visited on 05/05/2026)

    Fil-C Project.InvisiCaps: The Fil-C Capability Model.URL:https : / / fil - c . org / invisicaps (visited on 05/05/2026)

    2026

  24. [32]

    Fil-C Project.How Fil-C Works.URL:https://fil- c.org/how(visited on 05/05/2026)

    2026

  25. [33]

    Fil-C Project.Fil-C Runtime.URL:https : / / fil - c.org/runtime(visited on 05/05/2026)

    2026

  26. [34]

    May 4, 2026

    Aarno Labs.CodeHawk Analyzer. May 4, 2026. URL:https : / / github . com / static - analysis - engineering/CodeHawk(visited on 05/04/2026). 18 Appendix A. Additional Evaluation Data This appendix collects per-benchmark and supplemen- tary data for the evaluation of Section 8 an...

    2026

Pith tools

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