MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime

Simpson, Matthew S.; Barua, Rajeev

doi:10.1109/scam.2010.15

Cited by 19 publications

(5 citation statements)

References 42 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Memory safety is a common concern that aims at avoiding memory errors in software. There are tons of works 6,10,16,[39][40][41][42][43][44][45][46][47][48][49][50] focusing on ensuring memory safety.…”

Section: Related Workmentioning

confidence: 99%

SafeOSL: Ensuring memory safety of C via ownership‐based intermediate language

et al. 2021

View full text Add to dashboard Cite

The unsafe features of C make it a big challenge to ensure memory safety of C programs, and often lead to memory errors that can result in vulnerabilities. Various formal verification techniques for ensuring memory safety of C have been proposed. However, most of them either have a high overhead, such as state explosion problem in model checking, or have false positives, such as abstract interpretation. In this article, by innovatively borrowing ownership system from Rust, we propose a novel and sound static memory safety analysis approach, named SafeOSL. Its basic idea is an ownership-based intermediate language, called ownership system language (OSL), which captures the features of the ownership system in Rust. Ownership system specifies the relations among variables and memory locations, and maintains invariants that can ensure memory safety. The semantics of OSL is formalized in K-framework, which is a rewriting-logic based tool. C programs to be checked are first transformed into OSL programs and then detected by OSL semantics. Experimental results have demonstrated that SafeOSL is effective in detecting memory errors of C. Moreover, the translations and experiments indicate that the intermediate language OSL could be reused by other programming languages to detect memory errors.

show abstract

Section: Related Workmentioning

confidence: 99%

SafeOSL: Ensuring memory safety of C via ownership‐based intermediate language

et al. 2021

View full text Add to dashboard Cite

show abstract

“…Abadi et al propose a framework that enforces the control-flow integrity to mitigate memory attacks [14]. Simpson and Barua enforce both spatial and temporal memory safety of C programs without introducing high overhead by modelling temporal errors as spatial errors and removing redundant checks [42]. Similarly, Frama-C generates runtime memory monitor automatically to check E-ACSL specifications [30].…”

Section: Related Workmentioning

confidence: 99%

Securing Smart Contract On The Fly

Li,

Choi,

Long

2019

Preprint

View full text Add to dashboard Cite

We present Solythesis, a source to source Solidity compiler which takes a smart contract code and a user specified invariant as the input and produces an instrumented contract that rejects all transactions that violate the invariant. The design of Solythesis is driven by our observation that the consensus protocol and the storage layer are the primary and the secondary performance bottlenecks of Ethereum, respectively. Solythesis operates with our novel delta update and delta check techniques to minimize the overhead caused by the instrumented storage access statements. Our experimental results validate our hypothesis that the overhead of runtime validation, which is often too expensive for other domains, is in fact negligible for smart contracts. The CPU overhead of Solythesis is only 0.12% on average for our 23 benchmark contracts.

show abstract

“…The memory leak problem has been addressed extensively in the context of other languages such as C++ [12,21] and Java [6-8, 11, 14, 22]. Leakpoint [12] finds memory leaks in C++ applications.…”

Section: Memory Leak Detection In Other Programming Languagesmentioning

confidence: 99%

“…Similar to Leakpoint, LeakSpot monitors reference creations, which makes it possible to find the cause of the leaks easily and fix the leaks quickly. MemSafe [21] finds memory errors including memory leaks in C programs. Both Leakpoint and MemSafe assume that objects are explicitly allocated and deleted by calling library functions, which is true for C/C++ application.…”

mentioning

confidence: 99%

LeakSpot: detection and diagnosis of memory leaks in JavaScript applications

Rudafshani

Ward

2016

Softw. Pract. Exper.

View full text Add to dashboard Cite

Summary The migration of application logic to the client side of modern web applications and the use of JavaScript as the main language for client‐side development have made memory leaks in JavaScript an issue for web applications. Client‐side web applications communicate with the server asynchronously, remaining on the same web page during their lifetime. Thus, even minor memory leaks can eventually lead to excessive memory usage, negatively affecting user‐perceived response time and possibly causing page crashes. To detect memory leaks and guide developers in fixing the leaks quickly and easily, this paper introduces LeakSpot, a tool that creates a run‐time heap model by modifying the application code in a browser‐agnostic way to record object allocations, accesses, and references created to objects. LeakSpot reports those allocation sites causing the leaks instead of all the leaky allocation sites. It also identifies the locations in the code where leaked objects are accumulated, for example, the locations where a reference from a data structure is created but forgotten to be removed by the developer. To facilitate debugging and fixing the leaks, for every leaked object, LeakSpot reports all the locations in the code that create a reference to the object. To confirm usefulness and efficacy of LeakSpot experimentally, we have used LeakSpot to find and fix four memory leaks in a JavaScript benchmark suite and in open‐source web applications. LeakSpot is also shown to be effective in pointing out the potential causes of three leaks in large and popular web applications. Copyright © 2016 John Wiley & Sons, Ltd.

show abstract

MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime

Cited by 19 publications

References 42 publications

SafeOSL: Ensuring memory safety of C via ownership‐based intermediate language

SafeOSL: Ensuring memory safety of C via ownership‐based intermediate language

Securing Smart Contract On The Fly

LeakSpot: detection and diagnosis of memory leaks in JavaScript applications

Contact Info

Product

Resources

About