I was indeed using a hardware crypto accelerator on a Atmel SAMA5D2 platform. It works correctly after removing it. I'll work on a patch. Thank you! Nicolas 2017-10-03 17:42 GMT+02:00 David Gstir <david@xxxxxxxxxxxxx>: > Hi Nicolas, > >> On 3 Oct 2017, at 15:01, Nicolas Feignon <nicolas.feignon@xxxxxxxxxxxxxxxxx> wrote: >> >> Hi, >> >> I'm encountering an issue with filesystem encryption on UBIFS. I'm using Kernel >> 4.13.3. >> >> The encryption of filenames does not work correctly for filenames of more that >> 16 characters. It works fine if the names are shorter. Here's what I get: >> >> [~/writeDir]# touch aaaaaaaaaaaaaaaa # 16 characters >> [~/writeDir]# ls >> ls: cannot access aaaaaaaaaaaaaaaa>*0ѐL9: No such file or directory >> aaaaaaaaaaaaaaaa?>??*0?????n??L9 >> >> I set the policy with: >> [~]# openssl rand 64 > key >> [~]# fscryptctl insert_key < key >> a5bb6bff407f6f67 >> [~]# fscryptctl set_policy a5bb6bff407f6f67 writeDir/ >> >> I get the issue for all encryption modes and padding values altough the length >> of filenames at which it doesn't work varies. >> With the default padding of 32 and AES-256-CTS encryption mode, it does not >> work for length >= 16 and <= 32, length >= 48 and <= 64... >> >> I took a look at fs/crypto/fname.c but I can't figure out the problem. It seems >> like it's an overflow somewhere. > > Do you use a hardware crypto accelerator for AES? I saw the same issue with the CAAM driver (see issue 1 here [1]) some time ago. > > Specifically, the blockcipher driver code is required to update ->iv of skcipher_request after encryption/decryption. This is used by the CTS-mode code. Here's the fix that got merged for the CAAM driver [2]. > > - David > > [1] https://marc.info/?l=linux-crypto-vger&m=149640631518134&w=2 > [2] https://marc.info/?l=linux-crypto-vger&m=149865646825902&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|