Projects

Selected research projects.

You can find more of them here.

On adequacy of Linux kernel tests & reliability of coverage measurement tools

Advisors: Tianyin Xu, Darko Marinov

[Publications] [Talks] [Software]

Contributions to open-source projects:

• LLVM: https://github.com/llvm/llvm-project/commits/?author=whentojump
• Linux kernel
• …

This work is a collaboration with Steve VanderLeest and many other fantastic people from The Boeing Company.

On reliability of cloud-native systems

[Publications] [Software]

Advisor: Tianyin Xu

During this project, I learned a lot from and had an incomparable experience with my amazing mentors Tyler Gu and Xudong Sun. Thanks!

---8<------8<--- Older stuffs below. May be moved around. ---8<------8<---

Cycle-accurate record and replay of cloud FPGAs

Advisor: Baris Kasikci

[Publications] [Software]^{[open soon]}

During this project, I was fortunate to be mentored by Jiacheng Ma and Gefei Zuo, and to work with Yin Yuan.

Safe and expressive kernel extensions in Rust

Advisor: Tianyin Xu

[Publications] [Software]^{[open soon]}

Berkeley packet filter (BPF) subsystem offers a promising way of extending the kernel in networking, observability, security and many other use cases. However, to ensure safety, the native BPF verifier imposes several restrictions to the properties of BPF programs (like size and control flow), thus limiting their expressiveness. In this work, we propose a new mechanism of kernel extension, by placing compiled Rust programs at hook points that were conventionally for BPF programs to run, and turning to the language, rather than the verifier, for safety guarantee.

I contributed to:

• Kernel, runtime and compiler support: We are adding necessary system calls for loading the programs, inserting a runtime crate to perform {helper, argument} type checks, and building LLVM passes within rustc to further manipulate the programs and enforce safety policy.
• “Application” development: We are rewriting practical BPF programs with the new abstraction, from relatively simple ones (e.g. those shipped in the kernel source tree, like trace_event), to nontrivial ones (e.g. XRP).
• Micro-benchmarking: I am conducting performance evaluation with respect to several factors, like tail calls and vulnerability mitigation.

During this project, I also had the honor to work with Dan Williams and Jinghao Jia, among many other excellent researchers.

Figure 2¹. BPF programs are subject to the size limit imposed by the verifier (shown in blue). If a program has to exceed that limit, it should first be split into smaller tail calls. These tail calls then get chained together in order to execute (shown in orange, each dot representing one call). One of our goals is to let standalone Rust programs cross the same boundary, while maintaining comparable performance.

---

1. Incidentally, I'm not sure whether you have noticed, the figure looks pretty decent either in light or dark mode. Try it out: toggle. I was simply shocked by this effect! and did some serious research about it. The black magic turns out to be: grey will look white if on black, and will look black if on white. I'd really like to share this less academic, but quite philosophical finding, in case you are about to search something like "PNG 3.0" for hours like I did. ↩︎

IEEE 1451 standard development

Advisor: Jun Wu

[Publications] [Software]

IEEE 1451 is a family of standards whose goal is to promote interoperability among various interfaces or network protocols commonly seen in Internet of Things (IoT). I am a member of the working group led by Prof. Jun Wu, with a focus on the network level.

My contributions include:

• Specifications on IoT management: My group’s mission is to standardize the way of accessing and managing IoT with Simple Network Management Protocol (SNMP). To this end, we carefully investigated the common practices in industry, identified the gap between current approaches and new demands of interoperable IoT, and formulated draft specifications in terms of reference model, message structure, management information, etc.
• Specifications on security TEDS: I also worked closely with colleagues from NIST on security transducer electronic datasheet (TEDS), which helps IoT applications know about the security protocols being used (e.g. TLS for MQTT, VACM for SNMP, etc.) and their parameters in a zero-configuration manner.
• Hardware and software porototyping: I developed more than three generations of the hardware prototypes with heterogeneous computing devices (from ARM-based microcontrollers, single-board computers, to x86-based industrial PCs). I also participated in software development on top of these platforms, implementing/validating the specifications of the draft standard. The prototypes were presented at IECON'18/19/20/21 and ISIE'21. A live demonstration has also been set up and running since 2020, connecting multiple testbeds from other teams around the world.

During this project, I also worked closely with Kang Lee and Eugene Song (check this nice photo¹ of us!) among many other respected industry experts.

Figure 3^2,3. Transducer interface module (TIM) 4.0⁴, one of many hardware prototypes I developed for this project. Notably, it has two processing units: a microcontroller, and a SoC shipped along with the Raspberry Pi. It thus incorporates the benefits of both: (1) real-time capabilities of the microcontroller (2) OS, runtime and networkability of the Raspberry Pi⁵. Moreover, the two are connected through an on-board serial bus, making inter-chip communication or even “over-the-air” firmware upgrade possible.

---

1. Photo credit: Jie Ren. ↩︎

2. Processor (and logo) credits: Raspberry Pi Foundation and STMicroelectronics. ↩︎

3. Intel Corporation owns the copyright on the "whatever inside" slogan. Inside, though, there are no actual Intel products. ↩︎

4. Indeed, we never figured out a serious versioning scheme. So this is more like a parody of the buzzword "industry 4.0" than any meaningful release code, although I did develop and produce roughly that number of generations (i.e. in SemVer jargon, major versions) over the years. ↩︎

5. This README for RPi.GPIO project gives a very elegant summary of the technical differences. I like it! and cite this text over and over :) ↩︎