Virtualization Techniques for Memory Resource Exploitation

Total Page:16

File Type:pdf, Size:1020Kb

Virtualization Techniques for Memory Resource Exploitation Virtualization techniques for memory resource exploitation Luis Angel Garrido Platero ADVERTIMENT La consulta d’aquesta tesi queda condicionada a l’acceptació de les següents condicions d'ús: La difusió d’aquesta tesi per mitjà del r e p o s i t o r i i n s t i t u c i o n a l UPCommons (http://upcommons.upc.edu/tesis) i el repositori cooperatiu TDX ( h t t p : / / w w w . t d x . c a t / ) ha estat autoritzada pels titulars dels drets de propietat intel·lectual únicament per a usos privats emmarcats en activitats d’investigació i docència. No s’autoritza la seva reproducció amb finalitats de lucre ni la seva difusió i posada a disposició des d’un lloc aliè al servei UPCommons o TDX. No s’autoritza la presentació del seu contingut en una finestra o marc aliè a UPCommons (framing). Aquesta reserva de drets afecta tant al resum de presentació de la tesi com als seus continguts. En la utilització o cita de parts de la tesi és obligat indicar el nom de la persona autora. ADVERTENCIA La consulta de esta tesis queda condicionada a la aceptación de las siguientes condiciones de uso: La difusión de esta tesis por medio del repositorio institucional UPCommons (http://upcommons.upc.edu/tesis) y el repositorio cooperativo TDR (http://www.tdx.cat/?locale- attribute=es) ha sido autorizada por los titulares de los derechos de propiedad intelectual únicamente para usos privados enmarcados en actividades de investigación y docencia. No se autoriza su reproducción con finalidades de lucro ni su difusión y puesta a disposición desde un sitio ajeno al servicio UPCommons No se autoriza la presentación de su contenido en una ventana o marco ajeno a UPCommons (framing). Esta reserva de derechos afecta tanto al resumen de presentación de la tesis como a sus contenidos. En la utilización o cita de partes de la tesis es obligado indicar el nombre de la persona autora. WARNING On having consulted this thesis you’re accepting the following use conditions: Spreading this thesis by the i n s t i t u t i o n a l r e p o s i t o r y UPCommons (http://upcommons.upc.edu/tesis) and the cooperative repository TDX (http://www.tdx.cat/?locale- attribute=en) has been authorized by the titular of the intellectual property rights only for private uses placed in investigation and teaching activities. Reproduction with lucrative aims is not authorized neither its spreading nor availability from a site foreign to the UPCommons service. Introducing its content in a window or frame foreign to the UPCommons service is not authorized (framing). These rights affect to the presentation summary of the thesis as well as to its contents. In the using or citation of parts of the thesis it’s obliged to indicate the name of the author. Virtualization Techniques for Memory Resource Exploitation Luis Angel Garrido Platero Advisor: Paul Carpenter Co-advisor: Rosa Mar´ıaBad´ıa Computer Architecture Department Universitat Polit`ecnicade Catalunya A thesis submitted for the degree of Doctor of Philosophy Acta de qualificaci´ode tesi doctoral Curs acad`emic:2018-2019 Nom i cognoms: Luis Angel Garrido Platero Programa de doctorat: Arquitectura de Computadors Unitat estructural responsable del programa: Departament d'Arquitectura de Computadors Resoluci´odel Tribunal Reunit el Tribunal designat a l'efecte, el doctorand exposa el tema de la seva tesi doctoral titulada Virtualization Techniques for Memory Resource Exploitation. Acabada la lectura i despr´esde donar resposta a les q¨uestionsformulades pels membres titulars del tribunal, aquest atorga la qualificaci´o: NO APTE APROVAT NOTABLE EXCEL·LENT (Nom, cognoms i signatura) (Nom, cognoms i signatura) President/a Secretari/`aria (Nom, cognoms (Nom, cognoms (Nom, cognoms i signatura) i signatura) i signatura) Vocal Vocal Vocal Barcelona, d'/de de El resultat de l'escrutini dels vots emesos pels membres titulars del tribunal, efectuat per l'Escola de Doctorat, a inst`anciade la Comissi´ode Doctorat de la UPC, atorga la MENCIO´ CUM LAUDE: S´ı NO (Nom, cognoms i signatura) (Nom, cognoms i signatura) President de la Comissi´o Permanent de Secretari de la Comissi´o Permanent de l'Escola de Doctorat l'Escola de Doctorat Barcelona, d'/de de Abstract Cloud infrastructures have become indispensable in our daily lives with the rise of cloud-based services offered by companies like Facebook, Google, Amazon and many others. The e-mails we receive everyday, the files and pictures we upload/view to/from social media and all the different market-places through which we make purchases daily rely in some way on services offered by a cloud infrastructure somewhere. These cloud infrastructures use a large numbers of servers provisioned with their own computing resources. Each of these servers use a piece of software, called the Hypervisor (\HV", for short), that allows them to create multiple virtual instances of a subset of their physical computing resources and abstract them into \Virtual Machines" (VMs). The hypervisor multiplexes among the VMs some of the physical resources of the server like CPU and I/O interfaces. But other resources, like memory, are allocated because they cannot be multiplexed over time in the same way. A VM for cloud-based services runs an Operating System (OS), which in turn runs the applications used by the service consumers. The administrator of the cloud infrastructure is responsible for managing the VMs. The management tasks involve determining the resources that the VMs can use, in which physical node they can execute and any other constraint the administrator deems reasonable to enforce, such as Service Level Agreements (SLA) [50, 22]. The VMs within the computing nodes generate varying memory demand be- havior. When memory utilization reaches its limits due to this demand, costly operations such as (virtual) disk accesses and/or VM migrations can occur. As a result, it is necessary to optimize the utilization of the local memory resources within a single computing node. However, pressure on the memory resources can still increase, making it necessary to move (migrate) the VM to a different node with larger memory or add more memory to the same node. At this point, it is important to consider that some of the nodes in the cloud infrastructure might have memory resources that they are not using. So, this opens up the possibility of making this memory available to the nodes that actually need it, avoiding costly migrations or hardware memory enhancements. Considering the possibility to have a node's memory made available to the rest of the nodes in the infrastructure, new architectures have been introduced that provide hardware support for a shared global address space across multiple com- puting nodes. Together with fast interconnects, these architectures enable the sharing of memory resources across computing nodes while enforcing coherence locally within nodes. In this context, every node is a coherence island and the memory is a global resource. This thesis presents multiple contributions to the memory management problem. First, it addresses the problem of optimizing memory resources in a virtualized node through different types of memory abstractions. Two full contributions are presented for managing memory within a single node called SmarTmem and CARLEMM (Continuous-Action Reinforcement Learning for Memory Manage- ment). In this respect, a third contribution is also presented, called CAVMem (Continuous-Action Algorithm for Virtualized Memory Management), that works as the foundation for CARLEMM. SmarTmem is designed to optimize the memory made available through the VMs through the Transcendent Memory (Tmem) abstraction, while CARLEMM tar- gets the optimization of memory made available through ballooning. The initia- tive behind CARLEMM is initially based on a proof-of-concept mechanism called CAVMem that provided insight on the use of Continuous Action Reinforcement Learning (RL) algorithms for memory management. To the best of our knowl- edge, CARLEMM and CAVMem are the first mechanisms to employ CARL for the problem of memory management within a virtualized node. Second, this thesis presents two contributions for memory capacity aggregation across multiple nodes, offering two mechanisms called GV-Tmem (Globally Vis- ible Transcendent Memory) and vMCA (Virtualized Memory Capacity Aggrega- tion), this latter being based on GV-Tmem but with significant enhancements. These mechanisms focus primarily on distributing the memory pool of the infras- tructure across the computing nodes using a user-space process with high-level memory management policies. To summarize, the main contributions of this thesis work are: • A mechanism called SmarTmem for the optimal allocation of Tmem in a single virtualized node. • A mechanism called CAVMem (Continuous Action Algorithm for Virtual- ized Memory Management) developed as a proof-of-concept for the use of Continuous-Action Reinforcement Learning for RAM allocation in a simu- lation of a virtualized node • A mechanism called CARLEMM (Continuous Action Reinforcement Learn- ing for Memory Management), based on the proof-of-concept provided by CAVMem, but enhanced to solve the memory allocation problem in a real computing node. • A mechanism called GV-Tmem (Globally Visible Tmem) for remote memory capacity sharing across multiple computing nodes in a cloud infrastructure • A mechanism called vMCA (virtualized Memory Capacity Aggregation) for the sharing of memory capacity across nodes, but enhanced for resiliency and efficiency in comparison to GV-Tmem. Acknowledgements I would like to thank my advisor Paul Carpenter, which throughout this time has transmitted to me a lot of knowledge regarding our research field and a lot of knowledge on the methodology of research. I would like to thank him for his time and dedication to our work. I would also like to thank Rosa Badia, my co-advisor, for being accessible in par with Paul during all this time.
Recommended publications
  • Memory Deduplication: An
    1 Memory Deduplication: An Effective Approach to Improve the Memory System Yuhui Deng1,2, Xinyu Huang1, Liangshan Song1, Yongtao Zhou1, Frank Wang3 1Department of Computer Science, Jinan University, Guangzhou, 510632, P. R. China {[email protected][email protected][email protected][email protected]} 2Key Laboratory of Computer System and Architecture, Chinese Academy of Sciences Beijing, 100190, PR China 3 School of Computing,University of Kent, CT27NF, UK [email protected] Abstract— Programs now have more aggressive demands of memory to hold their data than before. This paper analyzes the characteristics of memory data by using seven real memory traces. It observes that there are a large volume of memory pages with identical contents contained in the traces. Furthermore, the unique memory content accessed are much less than the unique memory address accessed. This is incurred by the traditional address-based cache replacement algorithms that replace memory pages by checking the addresses rather than the contents of those pages, thus resulting in many identical memory contents with different addresses stored in the memory. For example, in the same file system, opening two identical files stored in different directories, or opening two similar files that share a certain amount of contents in the same directory, will result in identical data blocks stored in the cache due to the traditional address-based cache replacement algorithms. Based on the observations, this paper evaluates memory compression and memory deduplication. As expected, memory deduplication greatly outperforms memory compression. For example, the best deduplication ratio is 4.6 times higher than the best compression ratio.
    [Show full text]
  • Starwind Vmware Backup Plug-Innew Complete Protection of Your Vmware Virtual Machines
    Solution Overview StarWind VMware Backup Plug-inNEW Complete Protection of Your VMware Virtual Machines Premium VMware backup of your virtual machines StarWind Software is focused on developing solutions for safe Server virtualization technology introduces multiple benefits to an IT environment, and it can and efficient virtual machine drastically cut down the costs associated with server infrastructures. VMware vSphere is the backup and restore processes industry leading virtualization platform, which has been adopted by thousands of companies using advanced data transfer and globally. Virtualization is the first step for creation of an effective and flexible datacenter. The storage technologies. next logical step is protection of virtual machines, applications, and data. BACKGROUND OF VMWARE Introducing StarWind VMware Backup Plug-in BACKUP DEVELOPMENT StarWind VMware Backup Plug-in is a powerful and multi-functional backup solution for easy StarWind Software, Inc., and fast VM backup and recovery, that delivers: known as a reliable vendor of Affordability – a simple per host pricing model storage virtualization software acknowledged the importance Cross-hypervisor support – full support for VMware vSphere and Microsoft Hyper-V of data backup in virtualized Agentless architecture – reduced administrative overhead and a simplified installation environments. Such a position Global deduplication – drastically reduced disk space requirements resulting in lower TCO inspired the company to develop Sandbox and autotesting – verification of VM archives’ recoverability a full-service backup solution for ESX virtual machines. F ast Reliable Simple Flexible BENEFITS OF STARWIND VMWARE One powerful solution for storage and backup BACKUP StarWind provides an end-to-end storage virtualization tool and backup data protection • Ease of installation and use developed specifically for VMware environments.
    [Show full text]
  • Ben Livshits 1 Basic Instrumentation
    Runtime monitoring CO444H Ben Livshits 1 Basic Instrumentation • Insert additional code into the program • This code is designed to record important events as they occur at runtime • Some examples • A particular function is being hit or a statement is being hit • This leads to function-level or line-level coverage • Each allocation to measure overall memory allocation 2 Levels of Instrumentation • Native code • Instrument machine code • Tools like LLVM are often used for rewriting • Bytecode • Common for languages such as Java and C# • A variety of tools are available for each bytecode format • JoeQ is in this category as well, although it’s a lot more general • Source code • Common for languages like JavaScript • Often the easiest option – parse the code and add more statements 3 Runtime Code Monitoring •Three major examples of monitoring • Purify/Valgrind • Detecting data races • Detecting memory leaks 4 5 Memory Error Detection Purify • C and C++ are not type-safe • The type system and the runtime fail to enforce type safety • What are some of the examples? • Possible to read and write outside of your intended data structures • Write beyond loop bounds • Or object bounds • Or overwrite the code pointer, etc. 6 Track Each Byte of Memory • Three states for every byte of tracker memory • Unallocated: cannot be read or written • Allocated but not initialized: cannot be read • Allocated and initialized: all operations are allowed 7 Instrumentation for Purify • Check the state of each byte at every access • Binary instrumentation: • Add
    [Show full text]
  • Murciano Soto, Joan; Rexachs Del Rosario, Dolores Isabel, Dir
    This is the published version of the bachelor thesis: Murciano Soto, Joan; Rexachs del Rosario, Dolores Isabel, dir. Anàlisi de presta- cions de sistemes d’emmagatzematge per IA. 2021. (958 Enginyeria Informàtica) This version is available at https://ddd.uab.cat/record/248510 under the terms of the license TFG EN ENGINYERIA INFORMATICA,` ESCOLA D’ENGINYERIA (EE), UNIVERSITAT AUTONOMA` DE BARCELONA (UAB) Analisi` de prestacions de sistemes d’emmagatzematge per IA Joan Murciano Soto Resum– Els programes d’Intel·ligencia` Artificial (IA) son´ programes que fan moltes lectures de fitxers per la seva naturalesa. Aquestes lectures requereixen moltes crides a dispositius d’emmagatzematge, i aquestes poden comportar endarreriments en l’execucio´ del programa. L’ample de banda per transportar dades de disc a memoria` o viceversa pot esdevenir en un bottleneck, incrementant el temps d’execucio.´ De manera que es´ important saber detectar en aquest tipus de programes, si les entrades/sortides (E/S) del nostre sistema se saturen. En aquest treball s’estudien diferents programes amb altes quantitats de lectures a disc. S’utilitzen eines de monitoritzacio,´ les quals ens informen amb metriques` relacionades amb E/S a disc. Tambe´ veiem l’impacte que te´ el swap, el qual tambe´ provoca un increment d’operacions d’E/S. Aquest document preten´ mostrar la metodologia utilitzada per a realitzar l’analisi` descrivint les eines i els resultats obtinguts amb l’objectiu de que serveixi de guia per a entendre el comportament i l’efecte de les E/S i el swap. Paraules clau– E/S, swap, IA, monitoritzacio.´ Abstract– Artificial Intelligence (IA) programs make many file readings by nature.
    [Show full text]
  • Memory Leak Or Dangling Pointer
    Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer.
    [Show full text]
  • Effective and Efficient Memory Protection Using Dynamic Tainting
    1 Effective and Efficient Memory Protection Using Dynamic Tainting Ioannis Doudalis, Student Member, IEEE, James Clause, Member, IEEE, Guru Venkataramani, Member, IEEE, Milos Prvulovic, Senior Member, IEEE, and Alessandro Orso, Member, IEEE, ! Abstract—Programs written in languages allowing direct access to pointer p or a pointer derived from p and 2) if the access memory through pointers often contain memory-related faults, which occurs during the interval when p is valid, (i.e. between the cause non-deterministic failures and security vulnerabilities. We present allocation and deallocation of m). All other accesses to m are a new dynamic tainting technique to detect illegal memory accesses. illegal memory accesses (IMAs), where a pointer is used to When memory is allocated, at runtime, we taint both the memory and the corresponding pointer using the same taint mark. Taint marks access memory outside the bounds of the memory area with are then propagated and checked every time a memory address m which it was originally associated, or outside the time period is accessed through a pointer p; if the associated taint marks differ, during which the pointer is valid. an illegal access is reported. To allow always-on checking using a IMAs are especially relevant for several reasons. First, they low-overhead, hardware-assisted implementation, we make several key are caused by typical programming errors, such as array-out- technical decisions. We use a configurable, low number of reusable taint of-bounds accesses and stale pointer dereferences, and are thus marks instead of a unique mark for each allocated area of memory, reducing the performance overhead without losing the ability to target widespread and common.
    [Show full text]
  • Strict Memory Protection for Microcontrollers
    Master Thesis Spring 2019 Strict Memory Protection for Microcontrollers Erlend Sveen Supervisor: Jingyue Li Co-supervisor: Magnus Själander Sunday 17th February, 2019 Abstract Modern desktop systems protect processes from each other with memory protection. Microcontroller systems, which lack support for memory virtualization, typically only uses memory protection for areas that the programmer deems necessary and does not separate processes completely. As a result the application still appears monolithic and only a handful of errors may be detected. This thesis presents a set of solutions for complete separation of processes, unleash- ing the full potential of the memory protection unit embedded in modern ARM-based microcontrollers. The operating system loads multiple programs from disk into indepen- dently protected portions of memory. These programs may then be started, stopped, modified, crashed etc. without affecting other running programs. When loading pro- grams, a new allocation algorithm is used that automatically aligns the memories for use with the protection hardware. A pager is written to satisfy additional run-time demands of applications, and communication primitives for inter-process communication is made available. Since every running process is unable to get access to other running processes, not only reliability but also security is improved. An application may be split so that unsafe or error-prone code is separated from mission-critical code, allowing it to be independently restarted when an error occurs. With executable and writeable memory access rights being mutually exclusive, code injection is made harder to perform. The solution is all transparent to the programmer. All that is required is to split an application into sub-programs that operates largely independently.
    [Show full text]
  • Tutorial on Debugging, Memory Leaks and Profiling
    High Performance Computing for Science and Engineering I Tutorial on debugging, memory leaks and profiling Michalis Chatzimanolakis Computational Science & Engineering Laboratory OUTLINE - Approaches to debug your code •Using assertions •Using a debugger •Memory sanitation •Using a profiler Assertions in C++ An assertion is a logical statement that will cause your code to abort execution, if it is false. Example: Assertions can affect performance, Assertions perform checks that make sure that as they are essentially ‘if’ statements. some conditions are met. However, it is good practice to add assertions in a code. A simple compilation flag can ignore all assertions, so it is generally a good idea to use them. It is useful to combine assertions with the std functions isinf and isnan They can also be used with screen output. Compiler warnings Compiler warnings are compilation flags that you can (should) add to your Makefiles. Enabling warnings makes the compiler check for several issues in your source file, such as: • Forgetting to initialize a variable • Not using a declared variable • Using a function before declaring it • Having screen/file output with incorrect format (for example, treating doubles as integers) Generally, you should add warnings and try to fix all of them, before proceeding with further debugging your code. Note that different compilers may produce different warnings. The most common compiler warning flags are listed below: -Wall : enables several construction/declaration warnings -Wextra : more warnings than Wall including warnings for unused variables -Werror: will treat all warnings as errors -Wpedantic: warnings related to the use of non standard C++ extensions Using a debugger What is a debugger? A debugger is a program.
    [Show full text]
  • Linux Kernal II 9.1 Architecture
    Page 1 of 7 Linux Kernal II 9.1 Architecture: The Linux kernel is a Unix-like operating system kernel used by a variety of operating systems based on it, which are usually in the form of Linux distributions. The Linux kernel is a prominent example of free and open source software. Programming language The Linux kernel is written in the version of the C programming language supported by GCC (which has introduced a number of extensions and changes to standard C), together with a number of short sections of code written in the assembly language (in GCC's "AT&T-style" syntax) of the target architecture. Because of the extensions to C it supports, GCC was for a long time the only compiler capable of correctly building the Linux kernel. Compiler compatibility GCC is the default compiler for the Linux kernel source. In 2004, Intel claimed to have modified the kernel so that its C compiler also was capable of compiling it. There was another such reported success in 2009 with a modified 2.6.22 version of the kernel. Since 2010, effort has been underway to build the Linux kernel with Clang, an alternative compiler for the C language; as of 12 April 2014, the official kernel could almost be compiled by Clang. The project dedicated to this effort is named LLVMLinxu after the LLVM compiler infrastructure upon which Clang is built. LLVMLinux does not aim to fork either the Linux kernel or the LLVM, therefore it is a meta-project composed of patches that are eventually submitted to the upstream projects.
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • Virtual Memory - Paging
    Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation.
    [Show full text]
  • Memory Vulnerability Diagnosis for Binary Program
    ITM Web of Conferences 7 03004 , (2016) DOI: 10.1051/itmconf/20160703004 ITA 2016 Memory Vulnerability Diagnosis for Binary Program Feng-Yi TANG, Chao FENG and Chao-Jing TANG College of Electronic Science and Engineering National University of Defense Technology Changsha, China Abstract. Vulnerability diagnosis is important for program security analysis. It is a further step to understand the vulnerability after it is detected, as well as a preparatory step for vulnerability repair or exploitation. This paper mainly analyses the inner theories of major memory vulnerabilities and the threats of them. And then suggests some methods to diagnose several types of memory vulnerabilities for the binary programs, which is a difficult task due to the lack of source code. The diagnosis methods target at buffer overflow, use after free (UAF) and format string vulnerabilities. We carried out some tests on the Linux platform to validate the effectiveness of the diagnosis methods. It is proved that the methods can judge the type of the vulnerability given a binary program. 1 Introduction (or both) the memory area. These headers can contain some information like size, used or not, and etc. Memory vulnerabilities are difficult to detect and diagnose Therefore, we can monitor the allocator so as to especially for those do not crash the program. Due to its determine the base address and the size of the allocation importance, vulnerability diagnosis problem has been areas. Then, check all STORE and LOAD accesses in intensively studied. Researchers have proposed different memory to see which one is outside the allocated area. techniques to diagnose memory vulnerabilities.
    [Show full text]