Source code, design doc, evaluation, and bachlor thesis are unavailable now. They will be released once prepared.
基于Rust for Linux实现新Rust驱动，并系统性总结了Rust操作系统内核框架的优势与不足，评估了Rust驱动框架的性能并给出了可行优化方法。硕士阶段基于此研究了跨语言安全问题。
一是基于纯安全语言构建安全系统，这包括将硬件（页表、虚拟化架构等）、软件（程序分析、canary等）防护方法直接去除，利用Rust强大的编译器限制与检查机制进行安全性的保证。 二是基于新型安全语言构造新的配套安全系统，这包括新硬件（Rust on CHERI），新框架（Rust for Linux/ WebAssembly）等。 由于新型安全语言的出现，原来的安全系统不必面面俱到，而是可以各司其职，在部署上更方便，性能损耗也能大幅度降低。
从根本原因来说，现在构建大型项目的底层基本是由C和C++来构建，因为其对性能、灵活性等高要求。 但这种灵活性使得代码很难管理，因此后期的调试难度很大，而且也容易被利用。 所以Rust这种底层高效安全语言出现了，最直接的办法就是将最难以维护的部件使用Rust编写，这样就可以保证安全性。 但多个底层语言构成的系统是极少的，因此会衍生出很多相应的问题。所以我们需要预研基于安全语言的新型系统。 顺便一提，基于安全语言的系统很早就有研究了，但抛弃已有系统，同时要求所有开发者都只使用不通用的安全语言是一件很难的事。 安全语言通常比较晦涩，学术上构造的更为如此，因此之前的研究都没有出圈，面对应用需要不停的迭代，目前比较著名的有Rust，OCaml，Scala等。
在这些问题之上我们能做什么呢？
一是从软件工程上看的开发方法和模式。如何从已有的C与C++项目风格中，转换成Rust风格。 我们调研了Rust for Linux/AOSP/Firefox，他们的包装完整度和开发难度依次递减。（未完TBD）
二是新型软件架构。以WebAssembly（WASM）为例，跨语言之间交互的结构非常底层，用到的是C ABI，几乎接近于binary的调用逻辑。 由于Rust本身的ABI并未稳定，因此Rust模块化不能直接实现，需要额外操作确保Rust模块之间以及与其他语言能够以通用接口沟通。 WASM本身支持跨平台和跨语言，而且提供模块之间的隔离，同时Rust对此兼容非常好，因此非常适合对应模型，作为新型系统模块化的模块基础。 同时现在已经出现了WASM打包进eBPF，能够直接在Linux kernel运行，这也展示了WASM作为安全、高效、模块化设计的典范。 （未完TBD）
三是新型软硬件结合安全。朴素的想，软件有自己擅长的，硬件也有。 Rust编译器需要完整的语境才能保证安全，而计算机发展过程从未考虑过这种语境，它只考虑功能。 可以这么理解，CPU本身执行非常像C，它只做该做的，但是一旦需要获取额外的信息，比如变量被使用的次数，变量之间的联系，硬件一概不管。 但这种语义对于Rust编译器来说非常关键，如果能够硬件维护一些数据，那么和编译器配合就可以在用户无感的情况下大大提升性能或者安全性。 以CHERI为例，Rust本身对指针管理有所有权的概念，与CHERI的Capability非常相似。 （未完TBD）
总的来说，理想是很丰满的，但每一个方向都需要相当大的投入和尝试。由于本人的能力和时间问题，没办法在研究生涯中继续探索以上的三个方向，因此只做了预研。
GitHub repo is not currently ready for publication. It lacks of documentation, example, and evaluation.
其实在防御之前，我们必须要定下来一个Threat Model，也就是说我们需要弄清楚现在最可能的攻击模式（Security），或者最容易出错的（Reliability/Usability）的情况是怎么样的。
对于大项目转移到安全语言，逐步迁移是不可避免的中间过程，甚至可能成为常态。因此，跨语言的交互十分重要，它会暴露双方的弱点，造成安全性问题。 从基本的语言模型来说，语言双方可能因为不兼容（数据结构表示不同、内存模型不同等）导致出现问题，出现各种类型的问题（并发、内存威胁等）。 因此，我们设计并实现了对C/C++与Rust交互的ABI检测工具，判断是否与代码层API相同，提前检测出交互错误。
当然，除了ABI还有各个层的不兼容，这些是未来可以探索的方向。（未完TBD）