From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH crypto-next 07/23] block: cryptoloop: Remove VLA usage of skcipher Date: Mon, 24 Sep 2018 10:53:30 -0700 Message-ID: References: <20180919021100.3380-1-keescook@chromium.org> <20180919021100.3380-8-keescook@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Herbert Xu , Jens Axboe , linux-block , Eric Biggers , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Linux Kernel Mailing List To: Ard Biesheuvel Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Mon, Sep 24, 2018 at 4:52 AM, Ard Biesheuvel wrote: > On Wed, 19 Sep 2018 at 04:11, Kees Cook wrote: >> @@ -119,7 +119,7 @@ cryptoloop_transfer(struct loop_device *lo, int cmd, >> unsigned in_offs, out_offs; >> int err; >> >> - skcipher_request_set_tfm(req, tfm); >> + skcipher_request_set_sync_tfm(req, tfm); >> skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, >> NULL, NULL); >> > > Does this work? Everything is a direct wrapper for existing types and functions, so I wouldn't expect any functional change. I haven't been able to test this particular interface, though. cryptoloop is very deprecated, isn't it? -Kees -- Kees Cook Pixel Security