An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise

Developed.for over 30 years, Linux has already become the computing foundation for today's digital world; from gigantic, complex :mainframes (e.g., supercomputers) to cheap, wimpy embedded devices (e.g., IoTs), countless applications are built: on top of it. Yet, such an infrastructure has been plagued by numerous memory and concurrency hugs since the day it was born, due to many rogue memory operations are permitted by C language. A recent project Rust-for-Linux (RFL) has the potential to address Linux's safety concerns once and for all by embracing Rust's static ownership and type checkers into the kernel code, the kernel may finally be free from memory and concurrency bugs without hurting its performance, While it has been gradually matured and even merged into Linux mainline, however, RP I. is rarely studied and still remains unclear whether it has indeed reconciled the safety and performance dilemma for the kernel. To this end, we conduct the first empirical study on RFL to understand its status quo and benefits, especially/on how Rust fuses with I and whether the fusion assures driver safety without overhead, We collect and analyze 6 key RH, drivers, which involve hundreds of issues and PRs, thousands of Github commits and mail exchanges of the Linux mailing list, as well as over 12K discussions on Zulip. We have found while Rust mitigates kernel vulnerabilities, it is beyond Rust's capability to fully eliminate them; what is more, if not handled properly, its safety assurance even costs the developers dearly in terms of both runtime overhead and development efforts.