Design Considerations for Low Power Internet Protocols

Over the past 10 years, low-power wireless networks have transitioned to supporting IPv6 connectivity through 6LoWPAN, a set of standards which specify how to aggressively compress IPv6 packets over low-power wireless links such as 802.15.4. We find that different low-power IPv6 stacks are unable to communicate using 6LoWPAN, and therefore IP, due to design tradeoffs between code size and energy efficiency. We argue that applying traditional protocol design principles to low-power networks is responsible for these failures, in part because receivers must accommodate a wide range of senders. Based on these findings, we propose three design principles for Internet protocols on low-power networks. These principles are based around the importance of providing flexible tradeoffs between code size and energy efficiency. We apply these principles to 6LoWPAN and show that the resulting design of the protocol provides developers a wide range of tradeoff points while allowing implementations with different choices to seamlessly communicate

Demystifying Compiler Unstable Feature Usage and Impacts in the Rust Ecosystem

Rust programming language is gaining popularity rapidly in building reliable and secure systems due to its security guarantees and outstanding performance. To provide extra functionalities, the Rust compiler introduces Rust unstable features (RUF) to extend compiler functionality, syntax, and standard library support. However, these features are unstable and may get removed, introducing compilation failures to dependent packages. Even worse, their impacts propagate through transitive dependencies, causing large-scale failures in the whole ecosystem. Although RUF is widely used in Rust, previous research has primarily concentrated on Rust code safety, with the usage and impacts of RUF from the Rust compiler remaining unexplored. Therefore, we aim to bridge this gap by systematically analyzing the RUF usage and impacts in the Rust ecosystem. We propose novel techniques for extracting RUF precisely, and to assess its impact on the entire ecosystem quantitatively, we accurately resolve package dependencies. We have analyzed the whole Rust ecosystem with 590K package versions and 140M transitive dependencies. Our study shows that the Rust ecosystem uses 1000 different RUF, and at most 44% of package versions are affected by RUF, causing compiling failures for at most 12%. To mitigate wide RUF impacts, we further design and implement a RUF-compilation-failure recovery tool that can recover up to 90% of the failure. We believe our techniques, findings, and tools can help to stabilize the Rust compiler, ultimately enhancing the security and reliability of the Rust ecosystem.Comment: Published in ICSE'2024 Conference: https://conf.researchr.org/details/icse-2024/icse-2024-research-track/6/Demystifying-Compiler-Unstable-Feature-Usage-and-Impacts-in-the-Rust-Ecosystem. Project webiste: https://sites.google.com/view/ruf-study/home. Released Source Code Zonodo: https://zenodo.org/records/828937

Master of Science

thesisOperating system (OS) kernel extensions, particularly device drivers, are one of the primary sources of vulnerabilities in commodity OS kernels. Vulnerabilities in driver code are often exploited by attackers, leading to attacks like privilege escalation, denial-of-service, and arbitrary code execution. Today, kernel extensions are fully trusted and operate within the core kernel without any form of isolation. But history suggests that this trust is often misplaced, emphasizing a need for some isolation in the kernel. We develop a new framework for isolating device drivers in the Linux kernel. Our work builds on three fundamental principles: (1) strong isolation of the driver code; (2) reuse of existing driver while making no or minimal changes to the source; and (3) achieving same or better performance compared to the nonisolated driver. In comparison to existing driver isolation schemes like driver virtual machines and user-level device driver implementations, our work strives to avoid modifying existing code and implements an I/O path without incurring substantial performance overhead. We demonstrate our approach by isolating a unmodified driver for a null block device in the Linux kernel, achieving near-native throughput for block sizes ranging from 512B to 256KB and outperforming the nonisolated driver for block sizes of 1MB and higher

Programmazione memory-safe senza garbage collection: il caso del linguaggio Rust

Linguaggi di programmazione a basso livello permettono di ottenere prestazioni elevate, spesso a discapito di quella che viene definita "memory-safety", termine che racchiude un insieme di errori inerenti ad accessi ad aree di memoria non autorizzati. L'accesso ad aree di memoria non consentite porta inevitabilmente alla presenza di vulnerabilità a livello di sicurezza del sistema, è dunque necessario tenere questo problema in grande considerazione al momento dello sviluppo di un software. Rust è un linguaggio di programmazione di basso livello nato negli ultimi anni che ha introdotto tre concetti concetti fondamentali volti a garantire la memory-safety, cercando di rimanere prestante come linguaggi che invece non la garantiscono, come ad esempio C

Memory Subsystems for Security, Consistency, and Scalability

In response to the continuous demand for the ability to process ever larger datasets, as well as discoveries in next-generation memory technologies, researchers have been vigorously studying memory-driven computing architectures that shall allow data-intensive applications to access enormous amounts of pooled non-volatile memory. As applications continue to interact with increasing amounts of components and datasets, existing systems struggle to eÿciently enforce the principle of least privilege for security. While non-volatile memory can retain data even after a power loss and allow for large main memory capacity, programmers have to bear the burdens of maintaining the consistency of program memory for fault tolerance as well as handling huge datasets with traditional yet expensive memory management interfaces for scalability. Today’s computer systems have become too sophisticated for existing memory subsystems to handle many design requirements. In this dissertation, we introduce three memory subsystems to address challenges in terms of security, consistency, and scalability. Specifcally, we propose SMVs to provide threads with fne-grained control over access privileges for a partially shared address space for security, NVthreads to allow programmers to easily leverage nonvolatile memory with automatic persistence for consistency, and PetaMem to enable memory-centric applications to freely access memory beyond the traditional process boundary with support for memory isolation and crash recovery for security, consistency, and scalability

Hardware-Assisted Security Mechanisms On Arm-Based Multi-Core Processors

During the last decade, Trusted Execution Environment (TEE) provided by ARM TrustZone had become one of the most popular techniques to build security on mobile devices. On a TrustZone-enabled system, the software can execute in either Secure World (trusted) and Normal World (untrusted). Meanwhile, along with the expeditious development of TrustZone technology, the security of TEE is also challenged by dealing with more and more on-board hardware and in-TEE applications. In this dissertation, we explicitly study the security of ARM TrustZone technology with the latest ARM architecture in three aspects. First, we study the security of the TrustZone-assisted asynchronous introspection. Previously, asynchronous introspection mechanisms have been developed in the secure world to detect security policy violations in the normal world. However, we identify a new normal-world evasion attack that can defeat the asynchronous introspection by removing the attacking traces in parallel from one core when the secure-world checking is performing on another core. As the countermeasure, we propose a trustworthy asynchronous introspection mechanism called SATIN, which can effectively prevent evasion attacks with a minor system overhead by increasing the attackers\u27 evasion time cost and decreasing the defender\u27s inspecting time. Second, we design an ARM TrustZone-assisted connectivity mechanism, called TZNIC, to enable the secure world\u27s access to network even at the presence of a malicious OS. TZNIC deploys two NIC drivers, one secure-world driver, and one normal-world driver, that multiplex one physical NIC. We utilize the ARM TrustZone high-privilege to protect the secure-world driver, and further resolve several challenges about sharing one set of hardware peripheral between two isolated software environments. The evaluation shows that TZNIC can provide a reliable network channel for the secure world. Third, we investigate the memory-safety of secure-world trusted applications. Though the existing TrustZone hardware focuses on protecting the application\u27s confidentiality and integrity from malicious accesses of the normal world, there is little the secure world can do when the inside applications contain vulnerabilities and further get exploited by the normal world. To enhance the security of the secure-world application, we propose RusTEE, a TrustZone-based SDK that enables the development of trusted applications in the memory-safe programming language Rust. RusTEE can utilize the built-in security checks of Rust to mitigate all memory-corruption vulnerabilities for trusted applications. Besides, we enhance the trusted application\u27s security by enforcing the memory-safety on its invocations of system-service APIs and cross-world communication channels