Re: LUKS2 support for null/plaintext target
Jordan Glover <Golden_Miller83-g/[email protected]>
| Newsgroups | gmane.linux.kernel.device-mapper.dm-crypt |
|---|---|
| Message-ID | <HR1_2D_XSeTc2zLOBn4VxqML7PgGozaJjxIccFuR78H_4BgIuRmtWKaoFIXFtFA3C2iDyLJtvF4v4qHfsgwMFQr6exAbigHfv1JKnyTd4VA=@protonmail.ch> |
On Sunday, December 15, 2019 8:49 PM, Chris Murphy <lists-zXQU9YWDTqjmlV4oE/1sFAC/[email protected]> wrote: > On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover > Golden_Miller83-g/[email protected] wrote: > > > I think encrypting previously unencrypted data on the same disk > > doesn't guarantee that old data won't be recoverable especially > > on ssd/nvme which are ubiquitous today. Officially supporting > > such case on LUKS will give users false sense of security of > > their data. > > This problem exists even in the backup and restore to LUKS encrypted > volume case. In fact it's less reliable because there's no assurance > with backup->restore method that all previously occupied LBAs are > > overwritten, whereas an inplace conversion can assure that all LBAs in > the previous range are read and encrypted. It's a matter of > implementation, there's the potential for false sense of security > regardless. > > Chris Murphy AFAIK simply overwriting data isn't reliable method for cleaning ssd/nvme. For those either ATA SECURE ERASE[1] or blkdiscard[2] should be used. Unless I'm mistaken, inplace conversion does neither while user can run them manually during backup/restore. [1] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase [2] http://man7.org/linux/man-pages/man8/blkdiscard.8.html Jordan _______________________________________________ dm-crypt mailing list [email protected] https://www.saout.de/mailman/listinfo/dm-crypt