On Fri, Aug 09, 2019 at 03:06:23PM +0000, Pascal Van Leeuwen wrote: > > -----Original Message----- > > From: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > > Sent: Friday, August 9, 2019 4:18 PM > > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx; > > herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Eric Biggers <ebiggers@xxxxxxxxxx> > > Subject: RE: XTS template wrapping question > > > > > -----Original Message----- > > > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf > > Of > > > Pascal Van Leeuwen > > > Sent: Friday, August 9, 2019 1:39 PM > > > To: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Eric > > > Biggers <ebiggers@xxxxxxxxxx> > > > Subject: XTS template wrapping question > > > > > > Herbert, Eric, > > > > > > While working on the XTS template, I noticed that it is being used > > > (e.g. from testmgr, but also when explictly exported from other drivers) > > > as e.g. "xts(aes)", with the generic driver actually being > > > "xts(ecb(aes-generic))". > > > > > > While what I would expect would be "xts(ecb(aes))", the reason being > > > that plain "aes" is defined as a single block cipher while the XTS > > > template actually efficiently wraps an skcipher (like ecb(aes)). > > > The generic driver reference actually proves this point. > > > > > > The problem with XTS being used without the ecb template in between, > > > is that hardware accelerators will typically advertise an ecb(aes) > > > skcipher and the current approach makes it impossible to leverage > > > that for XTS (while the XTS template *could* actually do that > > > efficiently, from what I understand from the code ...). > > > Advertising a single block "aes" cipher from a hardware accelerator > > > unfortunately defeats the purpose of acceleration. > > > > > > I also wonder what happens if aes-generic is the only AES > > > implementation available? How would the crypto API know it needs to > > > do "xts(aes)" as "xts(ecb(aes))" without some explicit export? > > > (And I don't see how xts(aes) would work directly, considering > > > that only seems to handle single cipher blocks? Or ... will > > > the crypto API actually wrap some multi-block skcipher thing > > > around the single block cipher instance automatically??) > > > > > Actually, the above was based on observations from testmgr, which > > doesn't seem to test xts(safexcel-ecb-aes) even though I gave that > > a very high .cra_priority as well as that what is advertised under > > /proc/crypto, which does not include such a thing either. > > > > However, playing with tcrypt mode=600 shows some interesting > > results: > > > > WITHOUT the inside-secure driver loaded, both LRW encrypt and > > decrypt run on top of ecb-aes-aesni as you would expect. > > Both xts encrypt and decrypt give a "failed to load transform" > > with an error code of -80. Strange ... -80 = ELIBBAD?? > > (Do note that the selftest of xts(aes) using xts-aesni worked > > just fine according to /proc/crypto!) > > > > WITH the inside-secure driver loaded, NOT advertising xts(aes) > > itself and everything at cra_priority of 300: same (expected). > > > > WITH the inside-secure driver loaded, NOT advertising xts(aes) > > itself and everything safexcel at cra_priority of 2000: > > LRW decrypt now runs on top of safexcel-ecb-aes, but LRW > > encrypt now runs on top of aes-generic? This makes no sense as > > the encrypt datapath structure is the same as for decrypt so > > it should run just fine on top of safexcel-ecb-aes. And besides > > that, why drop from aesni all the way down to aes-generic?? > > xts encrypt and decrypt still give the -80 error, while you > > would expect that to now run using the xts wrapper around > > safexcel-ecb-aes (but no way to tell if that's happening). > > > > WITH the inside-secure driver loaded, advertising xts(aes) > > itself and everything at cra_priority of 2000: > > still the same LRW assymmetry as mentioned above, but > > xts encrypt and decrypt now work fine using safexcel-aes-xts > > > > Conclusions from the above: > > > > - There's something fishy with the selection of the underlying > > AES cipher for LRW encrypt (but not for LRW decrypt). > > > Actually, this makes no sense at all as crypto_skcipher_alloc > does not even see the direction you're going to use in your > requests. Still, it is what I consistently see happening in > the tcrypt logging. Weird! There's a known bug when the extra self-tests are enabled, where the first allocation of an algorithm actually returns the generic implementation, not the highest priority implementation. See: https://lkml.kernel.org/linux-crypto/20190409181608.GA122471@xxxxxxxxx/ Does that explain what you saw? > > > - xts-aes-aesni (and the xts.c wrapper?) appear(s) broken in > > some way not detected by testmgr but affecting tcrypt use, > > while the inside-secure driver's local xts works just fine > > Is this reproducible without any local patches? If so, can you provide clear reproduction steps? - Eric
