Hi Eric, Thanks for your answer On Wed, Mar 17, 2021 at 11:33:46AM -0700, Eric Biggers wrote: > On Wed, Mar 17, 2021 at 06:15:54PM +0100, Maxime Ripard wrote: > > Hi Eric, > > > > I've followed your work to integrate fscrypt for an eMMC, and now that > > it's been merged started to write the support for the Allwinner H6 [1] > > that has an encryption / decryption engine (EMCE, page 332) for the eMMC > > controller (page 495). > > > > I have some code that does most of the work to enable it and I'm at a > > point where I can run xfstests (so the accesses seem to go through the > > crypto engine, and they decrypt something), but the content of the files > > are off compared to the software implementation. > > > > My first guess would be to check how the key is setup in the hardware, > > but it's where I'm not really sure what's going on. It looks from the > > cqhci driver that the AES-XTS key has twice the size, and it's written > > in two steps for some reason? [2] > > > > Since the AES-XTS key size allegedly supported by the driver is 256 bits > > but the key size is 64 bytes, the comment makes sense, but I'm not > > really sure what is happening and what I'm supposed to be doing with > > that key. > > > > Thanks! > > Maxime > > > > 1: http://files.pine64.org/doc/datasheet/pine-h64/Allwinner_H6%20V200_User_Manual_V1.1.pdf > > 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/cqhci-crypto.c#n92 > > An AES-256-XTS key is 64 bytes; however, internally, the XTS algorithm divides > it into two AES-256 keys. AES-256-XTS implementations usually take the key as a > single 64-byte value; however, some require that users specify the two halves > separately. Also, some implementations use incorrect naming, like calling the > first half of the AES-256-XTS key the "key" and the second half the "salt". > > Looking at section 3.15.4 in the document you linked to, that looks to be the > case here. You probably need to write the 64-byte AES-256-XTS key to > EMCE_KEY0..7 and EMCE_SALT0..7. I've added the second part into the "salt" registers, and I'm still getting the same result: the test generic/592 fails with a mismatch. > If the ciphertext still doesn't match, you'll need to check the other things > that you could be going wrong, including: > > * Endianness and order of the key words. For example, if the hardware expects > the key words in big endian byte order and/or the key words in reverse > order, you'll need to take that into account when writing the registers so > that the hardware understands the intended 64-byte AES-256-XTS key. Thanks for the suggestion, however any combination of little/big endian and natural/reverse order doesn't change the outcome. > * Mapping of DUN (data unit number) to IV. It should be little endian. For > example DUN 1000 should result in the hardware using exactly the IV > u8 iv[16] = {0xe8, 0x03, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}. > > * Data unit size. The hardware must use exactly > data_unit_size bytes for the AES-256-XTS message size, and it must increment > the DUN by exactly 1 after each data_unit_size bytes encrypted/decrypted. > Note, fscrypt uses 4096 bytes for data_unit_size. Indeed, I somehow missed that you were setting the DUN in cqhci_crypto_prep_task_desc, and I'm guessing that's where my issue lies: it doesn't look like there's any field to set the DUN in the controller, which doesn't make much sense to me. The documentation is pretty short, but it looks like it might be inferred from the MMC commands arguments (the Access Mode bit in the MMC controller, page 517). Would that make sense? Thanks Maxime
