Linux 5.14 With EXT4 Adds Interface To Help Prevent Information Leakage From The Journal

[phoronix]

Phoronix: Linux 5.14 With EXT4 Adds Interface To Help Prevent Information Leakage From The Journal

The EXT4 file-system updates have been sent in for the ongoing Linux 5.14 merge window...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-EXT4

[avem]

And I've always disabled the journal after formatting a partition. Add added "noatime" to mount options.

[ultimA]

How does this prevent information leakage? SSDs do wear-levelling and LBA remapping all the time, so even though the information gets deleted under the specified block address, this shouldn't guarantee that the information is actually deleted from the drive. By the time the ioctl to delete the info reaches the file system layer, the drive will probably have a couple of copies of that same information lying around the disk (that are marked as free blocks though) without the FS layer knowing anything about them. At this point a full-disk scan like all FS recovery programs do should be able to reveal the information that has been thought deleted.

[Almindor]

How does this prevent information leakage? SSDs do wear-levelling and LBA remapping all the time, so even though the information gets deleted under the specified block address, this shouldn't guarantee that the information is actually deleted from the drive. By the time the ioctl to delete the info reaches the file system layer, the drive will probably have a couple of copies of that same information lying around the disk (that are marked as free blocks though) without the FS layer knowing anything about them. At this point a full-disk scan like all FS recovery programs do should be able to reveal the information that has been thought deleted.

A software solution cannot do anything about the hw layer unless the SSDs expose a way to wipe these copies. Not sure what your point is. This is fixing the issue on the ext4/FS level only.

[ultimA]

A software solution cannot do anything about the hw layer unless the SSDs expose a way to wipe these copies. Not sure what your point is. This is fixing the issue on the ext4/FS level only.

I'm questioning the effectiveness and rationale as a whole. I know this is only a sw-layer change, but isn't the problem unfixable even on the hw-level? Because a software can and will tell the hw to erase certain blocks, but neither the sw nor the hw knows which physical flash cells the information has occupied previously (for example, last week, before it was remapped 2 times already).

Without the hardware support, overwriting a logical address with zeroes could leave the current physical address unchanged and just remap the logical address to a new position. In contrast, if hardware support is present, the hardware can guarantee that the blocks that are now to be erased will erase the same physical flash location where the LBA (the logical address) is currently mapped, making sure the information is really gone from that current flash location. But what about the previous locations before the earlier remappings (for example due to wear-leveling)? My point is, even if hardware supports this, the information may still exist at earlier phyiscal locations that not even the hardware knows about anymore. And this would be easy to retrieve using traditional and conventional data recovery tools. So I'm saying even though the software of course forwards the request to the hardware, not even the hardware knows what physical addresses the same LBA was mapped to in the past, and even though the feature is implemented from software all the way through to the hardware, there is actually no guarantee the information will really be deleted securely from the disk.
I must be missing something. What is it?

[Almindor]

I'm questioning the effectiveness and rationale as a whole. I know this is only a sw-layer change, but isn't the problem unfixable even on the hw-level? Because a software can and will tell the hw to erase certain blocks, but neither the sw nor the hw knows which physical flash cells the information has occupied previously (for example, last week, before it was remapped 2 times already).

Without the hardware support, overwriting a logical address with zeroes could leave the current physical address unchanged and just remap the logical address to a new position. In contrast, if hardware support is present, the hardware can guarantee that the blocks that are now to be erased will erase the same physical flash location where the LBA (the logical address) is currently mapped, making sure the information is really gone from that current flash location. But what about the previous locations before the earlier remappings (for example due to wear-leveling)? My point is, even if hardware supports this, the information may still exist at earlier phyiscal locations that not even the hardware knows about anymore. And this would be easy to retrieve using traditional and conventional data recovery tools. So I'm saying even though the software of course forwards the request to the hardware, not even the hardware knows what physical addresses the same LBA was mapped to in the past, and even though the feature is implemented from software all the way through to the hardware, there is actually no guarantee the information will really be deleted securely from the disk.
I must be missing something. What is it?

I don't think you're missing anything. In hw backends that don't relocate this works fine. In hw backends that do it doesn't and cannot. That's still no argument against implementing it.