SoK: Eternal War in Memory¶
Szekeres, L., Payer, M., Tao Wei, & Song, D. (2013). SoK: Eternal War in Memory. 2013 IEEE Symposium on Security and Privacy.
Cited by¶
2 citations across 2 artifacts.
Each citation links to the sentence it supports in the citing article.
Domain-specific¶
- Pointer
- The pathological failure modes of pointer use arise where a pointer and the object it should name come apart — for the lifetime faults, through the gap between pointer lifetime and referent lifetime: a dangling pointer holds the address of storage that has been reclaimed and possibly reallocated to an unrelated purpose, so a dereference reads or writes an object belonging to a different computation; use-after-free is the runtime manifestation of a dangling pointer; null dereference, a distinct fault, follows a pointer holding the null sentinel value, which by convention names no valid object, into a trap or segmentation fault
This sourceThe definitions of dangling pointers and use-after-free as temporal memory errors, where freed memory may be reused by another object.
Supported in partVerified against the source
- The pathological failure modes of pointer use arise where a pointer and the object it should name come apart — for the lifetime faults, through the gap between pointer lifetime and referent lifetime: a dangling pointer holds the address of storage that has been reclaimed and possibly reallocated to an unrelated purpose, so a dereference reads or writes an object belonging to a different computation; use-after-free is the runtime manifestation of a dangling pointer; null dereference, a distinct fault, follows a pointer holding the null sentinel value, which by convention names no valid object, into a trap or segmentation fault
- Segmentation Fault
- Memory-safe languages and hardening mechanisms aim to prevent or contain the invalid references that lead to faults, while non-executable mappings, guard pages, address-space layout randomization, and protection keys change which corrupt operations complete
This sourceSzekeres et al. systematise memory-corruption defenses — type-safe languages, non-executable data and W⊕X, ASLR, and canary schemes — classifying each 'by the particular phase of exploit they try to inhibit'; the survey predates hardware protection keys, which are documented in the Intel architecture manuals instead.
Supported in partVerified against the source
- Memory-safe languages and hardening mechanisms aim to prevent or contain the invalid references that lead to faults, while non-executable mappings, guard pages, address-space layout randomization, and protection keys change which corrupt operations complete
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 2 of 2 citations: 2 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:c4d0e9626e3e · see in the full table