Eric, On Wed, Apr 19, 2017 at 7:21 PM, Richard Weinberger <richard@xxxxxx> wrote: >> Well, like I said to Jaegeuk for F2FS, that's what the code does, but _why_? >> Like F2FS, it's probably not the case that the hash is sufficient to reliably >> identify a directory entry. Granted, UBIFS does it a lot better than F2FS since >> UBIFS uses two 32-bit hashes rather than just one, but it seems the second hash >> may be neither necessary nor sufficient to identify a specific directory entry, >> and it should be looking at the bytes of ciphertext from the filename instead, >> like what ext4 does. (Provided that is fixed to account for how CTS mode >> encryption works.) > > Let me dig into this, maybe I made a boo boo. > The idea was looking up by the filename hash and resolving > possible collisions using the secondary hash. In ubifs_lookup() we handle two cases: 1. lookup of a bigname, both fscrypt_name->hash and ->minor_hash are valid. ->hash is r5(diskname) and ->minor_hash is the secondary hash, AKA cookie. UBIFS fed this hashes in ubifs_readdir() to fscrypt. 2. lookup of a non-bigname, in this case we compute r5(diskname) and use the diskname itself for lookups. So, in case 1 we avoid collisions by using a 64bit key and in case 2 by using the 32bit key plus a linear search and memcmp() of diskname. -- Thanks, //richard -- 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
![]() |