# Theis: A Booster for Building Safer Systems Using the Rust Programming Language
## 4 Design and Construction of Thetis
### Functionally Equivalent Replacement
#### 4.1.2 Replacement of _Union_ Types
Firstly, we selected four open source operating systems written in Rust, namely Redox [10], KatoOS [54], Theseus [55], and BlogOS [56], and analyzed the memory allocation API alloc.rs in the standard library [57]. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Type** & **Keyword** & **Function Name** & **Operators** \\ \hline Dereference a raw pointer & *mut/const T & unsafe[...] & as or other ways \\ Call an unsafe function or method & unsafe fn & Self-defined & / \\ Implement an unsafe trait & unsafe impl & Self-defined & / \\ Access or modify a mutable static variable & static mut & unsafe[...] & read, +, -, *, /... \\ Access field of union & unsafe fn & Self-defined & read, +, -, *, /... \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Unsafe Rust feature extraction table. * Redox v0.6.0 [10]: A Unix-like OS written in Rust that aims to realize the full set of applications and provide system safety for Rust. * Theseus v1.0 [55]: Uses the Rust compiler to guarantee the safety of the OS, which improves the performance of the system itself. * KataOS v2.0 [54]: Designed using the Rust language and built on the seL4 [40] kernel, which is mathematically safe, with the features of confidentiality, integrity, and availability. * BlogOS v2.0 [56]: Used for the teaching of Rust-based OSs and currently includes interrupt handling and memory management functions. All these OSes are designed using Rust and provide unique safety mechanisms for improving safety compared to traditional language-based systems. However, none of them are specifically optimized for unsafe code fragments and simply use the \"unsafe\" keyword to isolate unsafe and safe code fragments. We input all systems and libraries into the Thetis defect detection system, and the proportion of each type of unsafe operation was counted, as shown in Table 2.

We can see that unsafe fragments are unavoidable, even when designing a small standard library. The most commonly used operation is calling unsafe functions or methods, followed by dereferencing raw pointers, even without using union types in some simple systems. Depending on the defect report, Thetis can be used to optimize unsafe operations and reduce memory and thread issues. Furthermore, to better evaluate the accuracy of feature-based defect detection methods, we assessed them by calculating the detection accuracy (Acc). The calculation of Acc is based on the ratio of correctly predicted samples to all predicted samples as a measure of classification accuracy [59]. The specific calculation is shown in the following formula. \[\text{Accuracy}=\frac{\text{TP}+\text{TN}}{\text{TP}+\text{TN}+\text{FP}+ \text{FN}}\]

where TP is the true positive rate, TN is the true negative rate, FP is the false positive rate, and FN is the false negative rate. We manually inspected the defect detection and classification results of Hubris [60], BlogOS, and ArceOS, and the accuracy values obtained are shown in Table 3. From these results, it can be observed that due to the presence of behaviors such as dereferencing raw pointers through library encapsulated functions, dereferencing raw pointers in \"unsafe fn\", and accessing mutable static variables in the system design, there were cases of duplicate classifications and misclassifications in the identification process. However, on average, the proposed defect detection method in this paper achieved an average detection accuracy of 84.6%. We selected Miri, a commonly used defect-checking method in Rust, to perform defect detection on ArceOS and calculate the accuracy of this method. As shown in Table 3, it achieved an accuracy of around 63.6%, and there were numerous cases of false negatives and false positives in the detection results. The accuracy of our method was superior to that of Miri by approximately 20%.