Linux 5.14 To Allow EXT4 Journal Checkpoints From User-Space For Extra Privacy
The new journal checkpoint ioctl allows triggering a checkpoint from user-space and flushes the journal. EXT4_IOC_CHECKPOINT forces all the transactions to the log, checkpoints the transactions, and flushes to disk. "Systems that wish to achieve content deletion SLO [service level objective] can set up a daemon that calls this ioctl at a regular interval such that it matches with the SLO requirement. Thus, with this patch, the ext4_dir_entry2 wipeout patch, and the Ext4 "-o discard" mount option set, Ext4 can now guarantee that all file contents, file metatdata, and filenames will not be accessible through the filesystem and will have had discard or zeroout requests issued for corresponding device blocks."
Besides the new ioctl, the other equally important part is the discard/zeroout flags for helping to ensure no information leaks from the EXT4 journal for deleted files containing potentially sensitive filenames.
The updated EXT4 journal checkpoint documentation goes on to explain:
A journal checkpoint can be triggered from userspace via the ioctl EXT4_IOC_CHECKPOINT. This ioctl takes a single, u64 argument for flags. Currently, three flags are supported. First, EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN can be used to verify input to the ioctl. It returns error if there is any invalid input, otherwise it returns success without performing any checkpointing. This can be used to check whether the ioctl exists on a system and to verify there are no issues with arguments or flags. The other two flags are EXT4_IOC_CHECKPOINT_FLAG_DISCARD and EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT. These flags cause the journal blocks to be discarded or zero-filled, respectively, after the journal checkpoint is complete. EXT4_IOC_CHECKPOINT_FLAG_DISCARD and EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT cannot both be set. The ioctl may be useful when snapshotting a system or for complying with content deletion SLOs.
These patches now part of the EXT4 dev tree should land with Linux 5.14 this summer for those concerned about the leakage from the journal of any deleted filenames / basically ensuring when a file is deleted, its traces are gone. The original motivator for this EXT4 work appears to have been for Google Cloud with persistent disks and ensuring no remnants of personally identifiable information might be left around after file deletion.