## 5 Discussion and Analysis  
### Discussion  
**Security of TrustZone**. mobiDOM relies on an implied assumption that TrustZone itself is secure. This seems to be a widely acceptable assumption in the domain of TrustZone-based solutions [9]. However, there have been various attacks against TrustZone, e.g., side-channel attacks [18, 19], CLKSCREW attacks [20], hardware-fault injection attacks [21], etc. Enhancing the security of TrustZone has been actively taken care of in the literature [22] and is not the focus of this work.  
Figure 8: Mappings backup and restoration.  
**Defending against other types of OS-level malware**. mobiDOM can only combat the OS-level data corruption malware that causes I/Os to the external storage. For other types of OS-level malware, a potential solution is to run the malware detector in an isolated execution environment, which will then access the main memory of the normal world periodically (e.g., via direct memory access) in order to identify any misbehavior.  
**Towards making mobiDOM more practical**. One practical issue is to keep the FTL lightweight, since it is a thin firmware layer managed by less powerful processors and RAM. When integrating the malware detector into the FTL, a significant concern lies in the performance of ML-based detection. An option for improving the performance would be conducting a model pruning [23], which can help increase inference speed and decrease the storage size of the ML model; additionally, upon initializing mobiDOM, the ML model can be loaded into the RAM for malware detection later. Another practical issue is to manage interference of I/Os among regular software as well as multiple malware, which may perform I/Os simultaneously. Our experimental results in Section 6 only capture the scenario in which there is only one piece of malware running in the system. We will further investigate such interference in our future work.  
**Handling false positives and false negatives of the malware detector**. Malware detection relies on the AI model, which typically suffers from false positives and false negatives. If there is a false positive, the user will be falsely notified of a malware detected event. To mitigate this false alarm, the user is recommended to double confirm the attacks manually before further action is taken. If there is a false negative, the GC may have reclaimed some of the invalid flash blocks that store original data. Fortunately, our experimental results (Section 6.1) show that the false negatives are rare. The false negative issue will be investigated further in our future work.  
**Malware detection delay**. Our malware detection aware GC strategy relies on the timely detection of the malware. An extreme case is when the malware starts to compromise data, but the malware detector has not yet detected it due to the detection delay. This is right at the end of an epoch, and the GC will check with the malware detector. As no malware has been detected yet, the GC will reclaim invalid blocks that have been just invalidated by the malware. A remediation strategy is that the GC should avoid reclaiming those flash blocks that have been invalidated recently. This will also help mitigate the false negative issue mentioned before.