On 05/19/2011 11:14 AM, Yves-Alexis Perez wrote: >> The logic now works that table line received from dmcrypt >> is directly usable - cryptsetup uses that e.g. for resize. >> Replacing the key with zeroes or something will break this. > > I don't know enough dm-crypt arch, but aiui from the paper, everytime > you use the crypto-api to do stuff, it'll use the key in CPU debug > registers and not the dummy key. Do you mean cryptsetup resize doesn't > use the crypto-api (and will thus fail)? cryptsetup (including resize command) works through DM API (dm-ioctl) to setup dmcrypt, Only dmcrypt internally uses crypto-api. (Cryptsetup resize will simple create the whole table again, submitting key from userspace. This exercise will disappear with the new table format.) So it doesn't read key from crypto-api directly but thought that DM mapping table. There is already mechanism which ensures that all buffers with key are wiped when working with dm-ioctl. So this only slightly extends the window when is the key in memory (during initial setting). (Except that mentioned internal dmcrypt structure with plain key - key is set through crypto-api for tpm _and_ also stored here.) If you see how luksSuspend (aka key wipe message works): - it suspends device to stop IO - it wipes internal dmcrypt key buffer - it wipes tfm keys through crypto-api (for block cipher, ESSIV etc) (there is tfm per cpu in recent kernels as well) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
