On Mon, Jan 04, 2016 at 01:33:54PM +0100, Milan Broz wrote: > > - hmac() is now failing the same way (SETKEY after accept()) > (I initially tested without two patches above, these are not in linux-next yet.) > This breaks all cryptsetup TrueCrypt support (and moreover all systems if > kernel crypto API is set as a default vcrypto backend - but that's not default). Yes algif_hash would need the same compatibility patch and I'm working on that. > - cipher_null before worked without setkey, now it requires to set key > (either before or after accept(). > This was actually probably bad workaround in cryptsetup, anyway it will now cause > old cryptsetup-reencrypt tool failing with your patches. > (Try "cryptsetup benchmark -c cipher_null-ecb". I am not sure what to do here, > but not requiring setkey for "cipher" that has no key internally seems ok for me...) Is cipher_null actually used in production or is this just a benchmark? Using the kernel crypto API to perform no encryption sounds crazy. > As I said, I'll fix it in cryptsetup upstream but we are breaking a lot of existing systems. > Isn't there better way, how to fix it? Setting the key after accept has always been wrong. It's just that it hasn't been noticed until now. The main crypto socket corresponds to the tfm object and is shared by all the child sockets produced by accept(2). So once you have child sockets which may then be used by another thread you must not modify the parent socket/tfm in any way, and in particular you must not change the key. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
