Master and Semester Projects for Spring 2026
1) Title: Extending Sailor for the Arm Architecture (Semester Project)
Background: Sailor [1,2] is a tool build by our lab (in collaboration with IBM Research) to automatically identify security-sensitive ISA-state relevant for implementing context switching. It leverages the machine-readable official ISA specification in Sail [3,4,5] and the symbolic execution engine Isla [6] to gather ISA-level information. We use some simple python scripts to parse Isla-traces and implement the algorithm to classify ISA-state as security-sensitive. Sailor already works for the RISC-V ISA.
Project Goals and Overview:
– Extend Sailor for Arm: Isla can already generate traces for the Arm architecture. The trace parsing and algorithm implementation is expected to be architecture agnostic, so should be reusable. Challenge will be to figure out how to automatically feed all possible Arm instructions to Isla.
– Use generated insights for Security Analysis: We can use the generated insights to find context switch bugs in existing open-source Arm software.
References:
[1] https://www.usenix.org/conference/usenixsecurity25/presentation/kalani
[2] https://github.com/neeluk7/sailor_artifact
[3] https://github.com/rems-project/sail
[4] https://github.com/riscv/sail-riscv
[5] https://github.com/rems-project/sail-arm
[6] https://github.com/rems-project/isla
If you are interested in working on this project, please reach out to us by email.
PhD Student: Neelu Kalani ([email protected])
2) Title: Investigating backward-compatibility of custom RISC-V ISA-extensions using Sailor (Semester Project)
Background: Sailor [1,2] is a tool build by our lab (in collaboration with IBM Research) to automatically identify security-sensitive ISA-state relevant for implementing context switching. It leverages the machine-readable official ISA specification in Sail [3,4,5] and the symbolic execution engine Isla [6] to gather ISA-level information. Introducing new custom ISA-extensions can change the security-sensitive ISA-state identified by Sailor, but we expect that it shouldn’t change if the ISA-extension is disabled.
Project Goals and Overview:
– Apply Sailor to custom ISA-extensions: The Sail model keeps getting updated with newer ISA-extensions. We can apply Sailor to Sail models including some of these ISA-extensions (e.g. ePMP, Vector, especially extensions that introduce new ISA-state).
– Analyze how security-sensitivity of ISA-state is affected with the introduction of the new ISA-extensions: Is the set of security-sensitive ISA-state the same with and without this extension specified in the Sail model? Also same when the extension is enabled/disabled?
References:
[1] https://www.usenix.org/conference/usenixsecurity25/presentation/kalani
[2] https://github.com/neeluk7/sailor_artifact
[3] https://github.com/rems-project/sail
[4] https://github.com/riscv/sail-riscv
[5] https://github.com/rems-project/sail-arm
[6] https://github.com/rems-project/isla
If you are interested in working on this project, please reach out to us by email.
PhD Student: Neelu Kalani ([email protected])
3) Title: Programmable Batching for High-Performance RPC Systems (Master Thesis)
Background: Modern networked applications (e.g., gRPC) rely on batching at multiple layers to improve throughput. However, static or heuristic-based batching can negatively affect both latency and throughput under varying loads [1]. Inspired by Linux’s sched-ext [2], which enables user-defined scheduling through eBPF, this project explores the idea of programmable batching, where user-space policies dynamically control batching behavior in both the kernel and application layers to achieve better performance trade-offs.
Project Goals and Overview: In this project, you will analyze existing batching and queuing points in both the kernel and user-space applications, design a BPF-based interface to expose batching decisions to user-defined policies, and implement a prototype that enables dynamic batching control. You will evaluate your design using realistic workloads and quantify its impact on latency, throughput, and CPU efficiency compared to existing batching strategies.
Prerequisites: Background in systems programming (C/C++). Familiarity with the Linux kernel, eBPF, and RPC frameworks is a plus but not required.[1] Batching with End-to-End Performance Estimation https://dl.acm.org/doi/pdf/10.1145/3713082.3730372
[2] sched-ext https://docs.kernel.org/scheduler/sched-ext.html
If you are interested in working on this project, please reach out to us by email.
PhD Student: Rui Yang ([email protected])
4) Title: Offloading HTTP/2 Message Processing into the Kernel (Semester Project)
Background: Modern RPC frameworks like gRPC build on HTTP/2, which defines a rich framing layer for multiplexed message streams. Today, most HTTP/2 parsing and stream management happen in user space, introducing redundant data copies and limiting the ability to process and schedule messages efficiently.
Koma, an in-kernel message scheduling framework we have built in DCSL, supports in-kernel parsing of HTTP/2 frames to enable message-oriented scheduling for gRPC. However, much of HTTP/2’s connection and stream management—such as flow control—still resides in user space, limiting how effectively Koma can accelerate HTTP/2 processing. This project aims to extend Koma’s HTTP/2 implementation to handle more of these mechanisms directly in the kernel, reducing user–kernel interactions and enabling more efficient message scheduling.
Project Goals and Overview: In this project, you will study the existing Koma HTTP/2 code path, implement in-kernel handling for flow control and basic stream-state management, and integrate these features with Koma. You will then benchmark your implementation using real gRPC workloads to analyze how deeper in-kernel HTTP/2 support impacts latency, throughput, and CPU utilization.
Prerequisites: Background in systems programming (C/C++). Familiarity with the Linux kernel and RPC frameworks is a plus but not required.
If you are interested in working on this project, please reach out to us by email.
PhD Student: Rui Yang ([email protected])