Address Space Layout Randomization Comparative Analysis on Windows 10 and Ubuntu 18.04 LTS

An important goal of software security is to ensure sensitive/secret data owned by a program shall be exclusively accessible by the program. An obstacle to such security goal is that modern commodity operating systems (OS) for the sake of speed and flexibility have a unified linear address space--any OS kernel program can access all the linear addresses. As a result, rootkits or malicious system software are able to control the OS virtual address space, harvest the sensitive data used by software programs on the compromised computer, and report the data to remote entities controlled by hackers.In this paper, we present a holistic approach against sophisticated malware. Instead of focusing on the security of various abstraction layers of OS, we utilize the hardware techniques to directly provide the trust services to software programs. Without modifying OS, we leverage the virtual machine monitor technologies to create a lightweight hypervisor for fine-grain software runtime memory protection. As a result, a program's memory could be hidden from other high privilege system software in a single commodity OS. In addition, we propose the data locker component in the hypervisor, which prevents the sensitive data of software program in persistent storage from leaking to rootkits or other malware. For the performance evaluation, the implementation based on hardware-assisted x86 virtualization technology is presented and experimental results are reported.

Address Space Layout Randomization (ASLR) is a defensive technique supported by many desktop and server operating systems. While smartphone vendors wish to make it available on their platforms, there are technical challenges in implementing ASLR on these devices. Pre-linking, limited processing power and restrictive update processes make it difficult to use existing ASLR implementation strategies even on the latest generation of smartphones. In this paper we introduce retouching, a mechanism for executable ASLR that requires no kernel modifications and is suitable for mobile devices. We have implemented ASLR for the Android operating system and evaluated its effectiveness and performance. In addition, we introduce crash stack analysis, a technique that uses crash reports locally on the device, or in aggregate in the cloud to reliably detect attempts to brute-force ASLR protection. We expect that retouching and crash stack analysis will become standard techniques in mobile ASLR implementations.

MagBox: Keep the risk functions running safely in a magic box

Memory-centric computing demands careful organization of the virtual address space, but traditional methods for doing so are inflexible and inefficient. If an application wishes to address larger physical memory than virtual address bits allow, if it wishes to maintain pointer-based data structures beyond process lifetimes, or if it wishes to share large amounts of memory across simultaneously executing processes, legacy interfaces for managing the address space are cumbersome and often incur excessive overheads. We propose a new operating system design that promotes virtual address spaces to first-class citizens, enabling process threads to attach to, detach from, and switch between multiple virtual address spaces. Our work enables data-centric applications to utilize vast physical memory beyond the virtual range, represent persistent pointer-rich data structures without special pointer representations, and share large amounts of memory between processes efficiently.

The combination of a real-time executive and an off-the-shelf time-sharing operating system has the potential of providing both predictability and the comfort of a large application base. To isolate the real-time section from a significant class of faults in the (ever-growing) time-sharing operating system, address spaces can be used to encapsulate the time-sharing subsystem. However, in practice, designers seldom use address spaces for this purpose, fearing that the extra cost induced limits the system's predictability. To analyze this cost, we compared in detail two systems with almost identical interfaces-both are a combination of the Linux operating system and a small real-time executive. Our analysis revealed that for interrupt-response times, the delay and jitter caused by address spaces are similar to or even smaller than those caused by caches and blocked interrupts. As a side effect of our analysis, we observed that published figures on predictability must be carefully checked whether or not such hardware features are included in the analysis. This paper is a follow-up of an earlier publication at the 3rd Real-Time Linux workshop. It is different in that we have further optimized our microkernel and examined more hardware.

No abstract available.

Mobile ad hoc networks (MANETs) are networks with self-organizing capabilities and without a fixed infrastructure. Wireless nodes communicate among themselves using multi-hop radio relaying, without requiring the packets to pass through a central access point or a base station. Routing is a function of speed and stability with which the nodes are able to acquire addresses. Efficient routing forms the basis of a fast and reliable communication network. In a highly mobile and infrastructure-less scenario, pre-configuration of addresses is not possible. Therefore node addresses need to be configured dynamically with minimum delay and packet loss. The main task of an address auto-configuration protocol is to manage the resource address space. It must be able to select, allocate, and assign a unique network address to an un-configured node. This paper proposes a new address auto-configuration protocol for mobile ad hoc networks. The scheme uses virtual address space for addressing new nodes joining a network. The aim is to map one point from virtual address sheet to exactly one new node. The reason for using the term "virtual" is that the whole corresponding address space is a 2D flat sheet and each point of this sheet is virtually mapped to a node in MANET. The protocol uses coordinate values for generating addresses.

As one of most outstanding embedded real-time systems, QNX operating system is widely used on many key areas. Increasingly mature virtual machine technique is brought into QNX graphical interface program development to establish a "Host machine-Target machine" mode. On one computer, the developing platform for QNX graphical interface program is set up. Test results indicate that the developing platform obviously increases the efficiency of QNX interface program development and is suggested to other system programs development.

Object-oriented models are a popular basis for supporting uniform sharing of data and services in operating systems, distributed programming systems, and database systems. We term systems that use objects for these purposes object sharing systems. Operating systems in common use have nonuniform addressing models, making the uniform object naming required by object sharing systems expensive and difficult to implement. We argue that emerging 64-bit architectures make it practical to support uniform naming at the virtual addressing level, eliminating a key implementation problem for object sharing systems. We describe facilities for object-based sharing of persistent data and services in Opal, an operating system we are developing for paged 64-bit architectures. The distinctive feature of Opal is that object sharing is supported in a runtime library, a,bove a single virtual address space that maps all primary and secondary storage in a local area network. This work was supported in part by the National Science Foundation under Grants No. CCR-8619663 and CCR8907666; by the Washington Technology Center; and by Digital Equipment Corporation through the Systems Research Center, DECwest Engineering, the External Research Program, and the Graduate Engineering Education Program. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notico is Siven that copving is bv permission of the Association for Computing Machinery. To copy otherwise. or to republish, requires B fee and/or specific permission. o 1992 ACM 0-89791.539.9/92/0010/0397...$1.50

Many sensor nodes contain resource constrained microcontrollers where user level applications, operating system components, and device drivers share a single address space with no form of hardware memory protection. Programming errors in one application can easily corrupt the state of the operating system or other applications. In this paper, we propose Harbor, a memory protection system that prevents many forms of memory corruption. We use software based fault isolation ("sandboxing") to restrict application memory accesses and control flow to protection domains within the address space. A flexible and efficient memory map data structure records ownership and layout information for memory regions; writes are validated using the memory map. Control flow integrity is preserved by maintaining a safe stack that stores return addresses in a protected memory region. Run-time checks validate computed control flow instructions. Cross domain calls perform low-overhead control transfers between domains. Checks are introduced by rewriting an application's compiled binary. The sand-boxed result is verified on the sensor node before it is admitted for execution. Harbor's fault isolation properties depend only on the correctness of this verifier and the Harbor runtime. We have implemented and tested Harbor on the SOS operating system. Harbor detected and prevented memory corruption caused by programming errors in application modules that had been in use for several months. Harbor's overhead, though high, is less than that of application-specific virtual machines, and reasonable for typical sensor workloads.

NAND Flash memory solid state disk (hereafter SSD) technology is advancing rapidly in capacity and speed. Also, we envision that byte-addressable NVRAM devices, which is being thought as the future replacement of Flash memory technology will be commercially viable for storage within the next 3–7 years. Modern computer system takes hierarchical organization. It consists of CPU, Main Memory and Storage. This hierarchical organization is natural outcome of economic concern. Modern Operating System is designed to effectively exploit the physical characteristics of the device in each system hierarchy. Process management, memory management, and storage management subsystems are all designed to fill the gaps (speed and space) among the layers in different hierarchies while maximizing cost performance ratio. Current operating system paradigm draws clear line between memory and storage and handles them in very different way. Large scale byte-addressable NVRAM combines the physical characteristics of main memory with the nonvolatility of storage, presenting new challenges for system designers. From the DBMS and Operating System’s point of view, the advancement of this device calls for a reconsideration of legacy operating system architectures that have been designed based upon the notion of system hierarchy: CPU, memory and storage.

The wireless sensor network (WSN) is an interesting area for modern day research groups. Tiny sensor nodes are deployed in a diversity of environments but with limited resources. Scarce resources compel researchers to employ an operating system that requires limited memory and minimum power. Tiny operating system (TinyOS) is a widely used operating system for sensor nodes, which provides concurrency and flexibility while adhering to the constraints of scarce resources. Comparatively, TinyOS is considered to be the most robust, innovative, energy-efficient, and widely used operating system in sensor networks. This paper looks at the state-of-the-art TinyOS and the different dimensions of its design paradigm, programming model, execution model, scheduling algorithms, concurrency, memory management, hardware support platforms, and other features. The addition of different features in TinyOS makes it the operating system of choice for WSNs. Sensing nodes with TinyOS seem to show more flexibility in supporting diverse types of sensing applications.

While address space layout randomization (ASLR) has been extensively studied for user-space programs, the corresponding OS kernel's KASLR support remains very limited, making the kernel vulnerable to just-in-time (JIT) return-oriented programming (ROP) attacks. Furthermore, commodity OSs such as Linux restrict their KASLR range to 32 bits due to architectural constraints (e.g., x86-64 only supports 32-bit immediate operands for most instructions), which makes them vulnerable to even unsophisticated brute-force ROP attacks due to low entropy. Most in-kernel pointers remain static, exacerbating the problem when pointers are leaked. Adelie, our kernel defense mechanism, overcomes KASLR limitations, increases KASLR entropy, and makes successful ROP attacks on the Linux kernel much harder to achieve. First, Adelie enables the position-independent code (PIC) model so that the kernel and its modules can be placed anywhere in the 64-bit virtual address space, at any distance apart from each other. Second, Adelie implements stack re-randomization and address encryption on modules. Finally, Adelie enables efficient continuous KASLR for modules by using the PIC model to make it (almost) impossible to inject ROP gadgets through these modules regardless of gadget's origin. Since device drivers (typically compiled as modules) are often developed by third parties and are typically less tested than core OS parts, they are also often more vulnerable. By fully re-randomizing device drivers, the last two contributions together prevent most JIT ROP attacks since vulnerable modules are very likely to be a starting point of an attack. Furthermore, some OS instances in virtualized environments are specifically designated to run device drivers, where drivers are the primary target of JIT ROP attacks. Our evaluation shows high efficiency of Adelie's approach. [full abstract is in the paper]

Contemporary discrete GPUs support rich memory management features such as virtual memory and demand paging. These features simplify GPU programming by providing a virtual address space abstraction similar to CPUs and eliminating manual memory management, but they introduce high performance overheads during (1) address translation and (2) page faults. A GPU relies on high degrees of thread-level parallelism (TLP) to hide memory latency. Address translation can undermine TLP, as a single miss in the translation lookaside buffer (TLB) invokes an expensive serialized page table walk that often stalls multiple threads. Demand paging can also undermine TLP, as multiple threads often stall while they wait for an expensive data transfer over the system I/O (e.g., PCIe) bus when the GPU demands a page. In modern GPUs, we face a trade-o on how the page size used for memory management affects address translation and demand paging. The address translation overhead is lower when we employ a larger page size (e.g., 2MB large pages, compared with conventional 4KB base pages), which increases TLB coverage and thus reduces TLB misses. Conversely, the demand paging overhead is lower when we employ a smaller page size, which decreases the system I/O bus transfer latency. Support for multiple page sizes can help relax the page size trade-o so that address translation and demand paging optimizations work together synergistically. However, existing page coalescing (i.e., merging base pages into a large page) and splintering (i.e., splitting a large page into base pages) policies require costly base page migrations that undermine the benefits multiple page sizes provide. In this paper, we observe that GPGPU applications present an opportunity to support multiple page sizes without costly data migration, as the applications perform most of their memory allocation en masse (i.e., they allocate a large number of base pages at once). We show that this en masse allocation allows us to create intelligent memory allocation policies which ensure that base pages that are contiguous in virtual memory are allocated to contiguous physical memory pages. As a result, coalescing and splintering operations no longer need to migrate base pages. We introduce Mosaic, a GPU memory manager that provides application-transparent support for multiple page sizes. Mosaic uses base pages to transfer data over the system I/O bus, and allocates physical memory in a way that (1) preserves base page contiguity and (2) ensures that a large page frame contains pages from only a single memory protection domain. We take advantage of this allocation strategy to design a novel in-place page size selection mechanism that avoids data migration. This mechanism allows the TLB to use large pages, reducing address translation overhead. During data transfer, this mechanism enables the GPU to transfer only the base pages that are needed by the application over the system I/O bus, keeping demand paging overhead low. Our evaluations show that Mosaic reduces address translation overheads while efficiently achieving the benefits of demand paging, compared to a contemporary GPU that uses only a 4KB page size. Relative to a state-of-the-art GPU memory manager, Mosaic improves the performance of homogeneous and heterogeneous multi-application workloads by 55.5% and 29.7% on average, respectively, coming within 6.8% and 15.4% of the performance of an ideal TLB where all TLB requests are hits. CCS CONCEPTS • Computer systems organization → Parallel architectures;

Nowadays, Computer Science (CS) students must cope with continuous challenges related to programming skill acquisition. In some occasions, they have to deal with the internals of memory management (pointers, pointer arithmetic, and heap management) facing a vision of programming from the low abstraction level offered by C. Even using C++ and references, not all scenarios where objects or collections of objects need to be managed can be covered. Based on the difficulties identified when dealing with such low‐level abstractions, the C‐Sim application, aimed at learning these concepts in an easy way, has been developed. To support the tool, the C programming language was selected. It allows showing concepts, remaining as close as possible both to the hardware and the operating system. To validate C‐Sim, pre and posttests were filled in by a group of 60 first‐year CS students, who employed the tool to learn about memory management. Grades of students using C‐Sim were also obtained and compared with those that did not use the tool the former academic year. As main outcomes, 82.26% of students indicated that they had improved programming and memory management knowledge, and 83.64% pointed out that the use of this type of tools improves the understanding and quality of the practice lessons. Furthermore, the marks of students have significantly increased. Finally, C‐Sim was designed from the ground up as a learning aid and can be useful for lecturers, who can complement their lessons using interactive demonstrations. Students can also employ it to experiment and learn autonomously.