Introduction
Intel has released a patch to allow users to use a larger cache size, which leads to a reduced frequency of cache eviction and, thus, fewer transient snapshot generations. It is understandable that Intel adopts a strategy requiring minimal engineering effort. Unfortunately, this approach is not ideal, as it only reduces the occurrence of transient snapshots without eliminating them entirely.Â
Multi-Layered, Log-Structured Secure Disk (MlsDisk) is a virtual block device for existing file systems (like Ext4) to transparently protect I/O against strong TEE adversaries. Compared to the patch on Intel SGX-PFS, MlsDisk introduces the flush atomicity guarantee to make sure that all writes are flushed to the disk if and only if the sync operation is completed.
In addition, MlsDisk offers a broader range of security guarantees while delivering higher I/O performance, especially for random writes. MlsDisk effectively protects several security attributes including confidentiality (against the snooping attack), integrity (against the tampering attack), freshness (against replay attack), consistency (against tampering/crashing attack), irreversibility (against rollback attack), and atomicity (against transient snapshot attack).
Mitigation methods of Transient snapshot attack
A transient snapshot attack involves three parts: the generation, capture, and replay of transient snapshots. Unfortunately, it does not seem possible to prevent the capture or replay part. So we have to focus on preventing the generation of transient snapshots.
To prevent SGX-PFS from generating transient snapshots, we suggest adding an extra security guarantee, atomicity, which promises that all writes before a flush are persisted in an all-or-nothing manner. In other words, only a flush (or close) operation explicitly initiated by the user of SGX-PFS can generate a new snapshot of a protected file on the disk, thus eliminating the transient snapshots that are not aware by the user.
While this new property sounds simple, we believe it requires a big change (more likely an architectural one) to the current implementation of SGX-PFS. This judgment is based on our own experience of implementing a new solution for securing file I/O for TEE.
See our paper for more information.