Adressage mémoire | EPFL Graph Search

L’adressage mémoire est, en électronique et en informatique, la façon dont se fait l'accès aux données conservées en mémoire. Une adresse mémoire est un nombre entier naturel (rarement une autre sorte d'identifiant) qui désigne une zone particulière de la mémoire, ou juste le début d'une zone. Le plus souvent, une donnée peut être lue ou écrite. La mémoire peut être temporaire (mémoire vive) pour le travail ou au contraire durable (mémoire non volatile) pour le stockage. Utilisation L'immense majorité des programmes informatiques fait usage de la mémoire lors de son exécution. Le stockage temporaire d'une donnée (une variable) implique l'accès à la mémoire vive : dans ce cas, c'est le processeur qui écrit sur le bus. Lors d'un accès à un composant DMA (par exemple un disque dur), c'est le contrôleur DMA qui, cette fois, agit directement sur le bus système. Adresse physique et adresse virtuelle Les ordinateurs assez puissants pour faire fonctionner de nombreu

Preventing Use-After-Free Attacks with Fast Forward Allocation

Sanidhya Kashyap, Jungwon Lim

Memory-unsafe languages are widely used to implement critical systems like kernels and browsers, leading to thousands of memory safety issues every year. A use-after-free bug is a temporal memory error where the program accidentally visits a freed memory location. Recent studies show that use-after-free is one of the most exploited memory vulnerabilities. Unfortunately, previous efforts to mitigate use-after-free bugs are not widely deployed in real-world programs due to either inadequate accuracy or high performance overhead. In this paper, we propose to resurrect the idea of one-time allocation (OTA) and provide a practical implementation with efficient execution and moderate memory overhead. With one-time allocation, the memory manager always returns a distinct memory address for each request. Since memory locations are not reused, attackers cannot reclaim freed objects, and thus cannot exploit use-after-free bugs. We utilize two techniques to render OTA practical: batch page management and the fusion of bump-pointer and fixed-size bins memory allocation styles. Batch page management helps reduce the number of system calls which negatively impact performance, while blending the two allocation methods mitigates the memory overhead and fragmentation issues. We implemented a prototype, called FFmalloc, to demonstrate our techniques. We evaluated FFmalloc on widely used benchmarks and real-world large programs. FFmalloc successfully blocked all tested use-after-free attacks while introducing moderate overhead. The results show that OTA can be a strong and practical solution to thwart use-after-free threats.

USENIX ASSOC2021

Data transformer apparatus

Mario Paulo Drumond Lages De Oliveira, Babak Falsafi, Siddharth Gupta, Hussein Kassir, Christoph Koch, Arash Pourhabibi Zarandi, Mark Johnathon Sutherland, Zilu Tian

Data transformer apparatus comprising at least a dispatcher module (D), a reader module (R), a converter module (C) and a writer module (W). The dispatcher module (D) is configured to: receive a data transformation request (DTR) including: a first information item (X1) associated to a memory address where data to be transformed (Data1) are stored and to a type attribute (T) of said data to be transformed (Data1); a second information item (X2) indicating a memory address where transformed data (Data2), obtained from said data to be transformed (Data1), have to be written. The reader module (R) is configured to: retrieve the data to be transformed, according to said first information item (X1); obtain the type attribute (T) of the data to be transformed (Data1), based on said first information item (X1); send the data to be transformed (Data1) and the type attribute (T) thereof to the converter module (C). The converter module (C) is configured to: select one or more transformation instructions (INST) based on said type attribute (T); execute, on the data to be transformed (Data1), the selected one or more transformation instructions (INST), thereby obtaining the transformed data (Data2); send the transformed data (Data2) to the writer module (W). The writer module (W) is configured to: receive the transformed data (Data2) from the converter module (C); write the transformed data (Data2) in an output buffer according to said second information item (X2).

2021

Software Support for Non-Volatile Memory (NVM) Programming

David Teksen Aksun

Non-Volatile Memory (NVM) is an emerging type of memory device that provides fast, byte-addressable, and high-capacity durable storage. NVM sits on the memory bus and allows durable data structures designs similar to the in-memory equivalent ones. Expensive serialization/deserialization operations, usually associated with block-based storage, are not necessary. Unfortunately, using NVM is not as simple as placing a data structure in NVM and expecting persistence. As NVM sits on the memory bus, processor caches buffer the cache lines from it that are referenced by load and store instructions. The volatility of the caches and possible power failures at a random point in a program complicate the design and require ways to handle these failures. Prior work focused on implementing crash-consistency mechanisms to correctly recover a program's data after a failure. The goal was to minimize the use of costly cache line write-back and fence instructions, which are necessary for correct durability. Moreover, commercial NVM devices are slower compared to DRAM and affect the design. In addition to performance overheads, correctly implementing crash consistency is hard. The programmers need to carefully reason about cache line write-back instructions and the order of persistent writes. Finding bugs can take from minutes to hours. In this thesis, we use checkpointing as an effective crash-consistency mechanism with low overhead for building durable data structures. We also describe an inter-procedural dataflow analysis for fast detection of NVM programming bugs. We show the practicality of these ideas through three primary contributions and their implementations. Firstly, we present InCLL to address NVM checkpointing. InCLL is a novel technique that uses fine-grained checkpointing and in-cache-line logging to minimize the number of explicit write-back and fence instructions in the fast path of data structure modifications. We evaluate InCLL both on DRAM and Optane devices for the Masstree data structure. Secondly, we present a new checkpointing design, CpNvm, which minimizes NVM write-back instructions on the critical path of the execution. We achieve low overheads for Masstree and Memcached for write-heavy workloads, and almost no overheads for read-only workloads. In addition, we present FlowNvm to find NVM programming bugs. FlowNvm can identify NVM programming pattern violations and anti-patterns at compile-time using inter-procedural dataflow analysis.

EPFL2021

Software Support for Non-Volatile Memory (NVM) Programming

David Teksen Aksun

EPFL2021