Dynamic space limits for Haskell

Yang, Emily; Mazières, David

doi:10.1145/2594291.2594341

Cited by 8 publications

(3 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This discussion suggests that, if size vulnerabilities are a real concern, they need to be treated with special care. One approach would be to limit the amount of memory an untrusted component can allocate [47], so that exhausting the memory allotted to that component doesn't reveal information about the state of the rest of the system (and so that also global denial-of-service attacks are prevented). A more speculative idea is to develop quantitative versions [6,39] of the noninterference results discussed here that apply only if the total memory used by the program is below a certain limit.…”

Section: Infinite Memorymentioning

confidence: 99%

The Meaning of Memory Safety

Amorim¹,

Hriţcu²,

Pierce³

2018

Lecture Notes in Computer Science

View full text Add to dashboard Cite

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 "memorysafe 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.

show abstract

Section: Infinite Memorymentioning

confidence: 99%

The Meaning of Memory Safety

Amorim¹,

Hriţcu²,

Pierce³

2018

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…A Haskell server receives untrusted code over the wire, specifies its expected type, and compiles it in Safe mode[40] together with runtime resource limits[42]. In this way it supports type-system-enforced safety rather than modified runtimes for sandboxing, such as found in Javascript[41].…”

mentioning

confidence: 99%

SC-Haskell

Vollmer

Scott

Musuvathi

et al. 2017

Proceedings of the 22nd ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming

View full text Add to dashboard Cite

A core, but often neglected, aspect of a programming language design is its memory (consistency) model. Sequential consistency (SC) is the most intuitive memory model for programmers as it guarantees sequential composition of instructions and provides a simple abstraction of shared memory as a single global store with atomic read and writes. Unfortunately, SC is widely considered to be impractical due to its associated performance overheads.Perhaps contrary to popular opinion, this paper demonstrates that SC is achievable with acceptable performance overheads for mainstream languages that minimize mutable shared heap. In particular, we modify the Glasgow Haskell Compiler to insert fences on all writes to shared mutable memory accessed in nonfunctional parts of the program. For a benchmark suite containing 1,279 programs, SC adds a geomean overhead of less than 0.4% on an x86 machine.The efficiency of SC arises primarily due to the isolation provided by the Haskell type system between purely functional and thread-local imperative computations on the one hand, and imperative computations on the global heap on the other. We show how to use new programming idioms to further reduce the SC overhead; these create a virtuous cycle of less overhead and even stronger semantic guarantees (static data-race freedom).

show abstract

“…Here, we abuse notation by describing types for configuration parts using the same metavariables as the "instance" of the type, e.g., t for the type of task 4. We believe that we can extend LIFC(α, λ) to such models using the resource limits techniques of[48]. We leave this extension to future work.…”

mentioning

confidence: 99%

IFC Inside: Retrofitting Languages with Dynamic Information Flow Control

Heule

Stefan

Yang

et al. 2015

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Many important security problems in JavaScript, such as browser extension security, untrusted JavaScript libraries and safe integration of mutually distrustful websites (mash-ups), may be effectively addressed using an efficient implementation of information flow control (IFC). Unfortunately existing fine-grained approaches to JavaScript IFC require modifications to the language semantics and its engine, a non-goal for browser applications. In this work, we take the ideas of coarse-grained dynamic IFC and provide the theoretical foundation for a language-based approach that can be applied to any programming language for which external effects can be controlled. We then apply this formalism to serverand client-side JavaScript, show how it generalizes to the C programming language, and connect it to the Haskell LIO system. Our methodology offers design principles for the construction of information flow control systems when isolation can easily be achieved, as well as compositional proofs for optimized concrete implementations of these systems, by relating them to their isolated variants.

show abstract

Dynamic space limits for Haskell

Cited by 8 publications

References 28 publications

The Meaning of Memory Safety

The Meaning of Memory Safety

SC-Haskell

IFC Inside: Retrofitting Languages with Dynamic Information Flow Control

Contact Info

Product

Resources

About