Mandeep Singh Baines (msb@xxxxxxxxxx) wrote: > Hi, > > On 04/26/2011 05:17 PM, Will Drewry wrote: > > Recently, I've been benchmarking some different hardware crypto > > accelerators and many of them appear to be tuned toward largish > > requests (up to 16k) with a given key and a base IV. > > Please can you explicitly say which accelerators you are using and > show some benchmarks? > > Does dmcrypt work in async crypto mode or you have also > "accelerators" like special instructions which run synchronously > (like AES-NI)? > > Of course large block means smaller overhead but the difference should > not be significant (at least in theory). > If it is, we need to know why - it can be because of timing or > the way how the request are submitted not the time > or real encryption (initialization) itself. > > In this case the crypto driver should be optimised first. > > > I've created a > > very simple patch for dm-crypt that uses PAGE_SIZE blocks to aid in > > the driver performance testing, but I lack the cryptographic > > understanding to determine if there is significant exposure by > > allowing a dm-crypt device to use a block size that exceeds the sector > > size. > > As Arno said, there should be no real security problem for these block > sizes. Basically we are just using CBC or XTS mode today. > > For XTS-AES, definition explicitly says that data unit (= your block) > size should not exceed 2^20 128bit blocks (128bit = AES cipher block). > (And even here possible attacks are closely related to birthday > bound, IOW you need to have enough blocks encrypted with the same key.) > > So I do not see real security problem here. But problems are elsewhere. > > > 1. Does anyone know if there will be significant exposure to the > > plaintext if dm-crypt used larger block sizes? > > Should not be. > > > 2. Would an optional, configurable block-size (up to PAGE_SIZE) be of > > interest? > > Short answer would be no :-) > > As I said, I would like to prove first that the problem is really in block > size and not in related problem. > > Now the real problems: > > The whole device mapper and dmcrypt works as transparent block encryption > and we are always operating on 512B sectors. > > Even if device is 4k blocks, this is hidden in underlying layer and > DM just properly aligns data and propagates limits but > still operates on 512B sectors. (It can be ineffective for some > IO patterns, but it works). > > Changing encryption block size causes device to be incompatible with other > systems (note stacked devices, a common thing here - LVM over dmcrypt) > and IOs. You have to generate only aligned IO of your encryption block size. > > (or change dmcrypt significantly) > > IO hints is not enough - maybe example is better here: > > Testing device (some random data there, not important) > # dmsetup table --showkeys > x: 0 417792 crypt aes-cbc-essiv:sha256 aeb26d1f69eb6dddfb9381eed4d7299f091e99aa5d3ff06866d4ce9f620f7aca 0 8:16 0 > > Let's generate some direct IOs (to avoid page cache) > > *Without* your patch: > > # dd if=/dev/mapper/x iflag=direct bs=512 count=32 | sha256sum > eed6cf19ee9b2ecc5f4a6d1b251468fd9d691cbee67124de730078a1eda2c0c4 - > > # dd if=/dev/mapper/x iflag=direct bs=4096 count=4 | sha256sum > eed6cf19ee9b2ecc5f4a6d1b251468fd9d691cbee67124de730078a1eda2c0c4 - > > # dd if=/dev/mapper/x iflag=direct bs=8192 count=2 | sha256sum > eed6cf19ee9b2ecc5f4a6d1b251468fd9d691cbee67124de730078a1eda2c0c4 - > > As you can see, we get the same plain data with different IO sizes. > > Now *with* your patch (page size is 4096): > > # dd if=/dev/mapper/x iflag=direct bs=512 count=32 | sha256sum > dd: reading `/dev/mapper/x': Invalid argument > > # dd if=/dev/mapper/x iflag=direct bs=4096 count=4 | sha256sum > 4f4271e7799097b6e0ed66d81a8341163b8a5a06a2c57f50b930d429a7aa94d1 - > > # dd if=/dev/mapper/x iflag=direct bs=8192 count=2 | sha256sum > 17cf9897059800f5b43af38766471048b872d20a0f565ee553a351b1a6251141 - > > So block size of 512B causes operation to fail (ok - IO hints). > IO of block encryption size and multiple of encryption size returns > apparently something different now. > > This is probably not what we want... > But isn't this what should happen? You're trying to do 512B direct I/O on a block device with a 4096B logical block size. The same error would happen if you tried to do 512B direct I/O on a disk with a 4096B logical block size. A portable user-space application should not assume a logical block size when using direct I/O. > (Note that I did not even tested cross-encryption-block operations.) > > Even if this is somehow solved, many other problems remains: > > - we need to extend mapping table parameters so the block size > must be configurable (encrypted device image must be readable > on system with different page size, I have e.g. Sparc with 8k page size. > (This will be needed for other extensions so it is not real > problem, just it need to be done first.) > > - you need to store this block size info in header, > for LUKS it means using new LUKS header version > (requiring parameter on commandline is dangerous - it must be enforced) > > > I would really better to not support this yet and first try to optimize > crypto layer such way that it can process 512B blocks more > efficiently (of course it will not fix bad hw but it can help batching > sector encryption, maybe suing some hints, dunno). > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt-4q3lyFh4P1g@xxxxxxxxxxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
