HackerPapers

arXiv:1705.07354cs.PL

The Meaning of Memory Safety

Arthur Azevedo de Amorim, Catalin Hritcu, Benjamin C. Pierce

Early discovery. Linked by one identifiable commenter. This paper is outside the main ranking; a mention is not an endorsement.

Abstract

We give a rigorous characterization of what it means for a programming language to be memory safe, capturing the intuition that memory safety supports local reasoning about state. We formalize this principle in two ways. First, we show how a small memory-safe language validates a noninterference property: a program can neither affect nor be affected by unreachable parts of the state. Second, we extend separation logic, a proof system for heap-manipulating programs, with a memory-safe variant of its frame rule. The new rule is stronger because it applies even when parts of the program are buggy or malicious, but also weaker because it demands a stricter form of separation between parts of the program state. We also consider a number of pragmatically motivated variations on memory safety and the reasoning principles they support. As an application of our characterization, we evaluate the security of a previously proposed dynamic monitor for memory safety of heap-allocated data.

arXiv comments
POST'18 final version
Journal reference
DOI
Subjects
cs.PLProgramming Languages cs.CRCryptography and Security

On Hacker News

Linked by 1 identifiable commenter in 1 comment across 1 thread, from May 2018 to May 2018.

Comments linking this paper, per year.

Discussed in comments1 thread

    • The question and all answers so far assume that memory safety is a clear and well-understood concept! Au contraire! Can I bring [1] to your attention? The paper argues that our intuition about memory safety means allowing for local reasoning about state. [1]…

      YorkshireSeasonView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.