On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively >> using that code. >> This is clear userspace breakage which should not happen this way. > > I'll try to add some compatibility code for your case, assuming > your modus operandi is accept(2) followed by a single setkey before > proceeding to encryption/decryption.
Hi, yes, basically it prepares socket()/bind()/accept() and then it calls setkey once. (I'll try to fix in next releases to call setkey first though.) I am doing exactly the same for AF_ALG HMAC (hmac(<hash>) key, does this requirement for order if accept/setkey applies there as well? (It is not enforced yet.) Anyway, you can easily simulate that skcipher API call just with running "cryptsetup benchmark" (with accept() patch it will print N/A for all ciphers while without patch it measures some more-or-less magic performance numbers :) > >> (Moreover it still doesn't work for cipher_null that has min/max key size 0.) > > Setkey works just fine on cipher_null. Yes, it works if ALG_SET_KEY is set to zero-length key. I just re-introduced old bug to code, sorry. Thanks! Milan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
