MIME-Version: 1.0
References: <20230217144348.1537615-1-ardb@kernel.org> <Y/L6rSGDidhhWq2v@gondor.apana.org.au>
 <CAMj1kXE8ZjVh=hLVgnRGr8cJpkqzRHsVxuq3dm1P=Aqc1QpcXg@mail.gmail.com>
 <ZAsDT00Jgs2p6luL@gondor.apana.org.au> <CAMj1kXHhF7CyeGV2QHu6MRVQNKo1EHFkshewOfptEOdJ5znJDA@mail.gmail.com>
 <ZAw2eHDQELdiVXcZ@gondor.apana.org.au>
In-Reply-To: <ZAw2eHDQELdiVXcZ@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Sat, 11 Mar 2023 09:15:42 +0100
Message-ID: <CAMj1kXGC81=z_h-gcdQ0OoNA01kSAJz58QNiB1ixCPFA0_YnUw@mail.gmail.com>
Subject: Re: [PATCH v2] crypto: lib - implement library version of AES in CFB mode
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     linux-crypto@vger.kernel.org, ebiggers@kernel.org,
        James Bottomley <James.Bottomley@hansenpartnership.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, 11 Mar 2023 at 09:06, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Fri, Mar 10, 2023 at 05:18:05PM +0100, Ard Biesheuvel wrote:
> >
> > Does that mean you are bringing back blkcipher? I think that would the
> > right thing to do tbh, although it might make sense to enhance
> > skcipher (and aead) to support this.
>
> I haven't gone into that kind of detail yet but my first impression
> is that it would be the analogue of shash and skcipher would simply
> wrap around it just like ahash wraps around shash.
>
> > Could we perhaps update struct skcipher_request so it can describe
> > virtually mapped address ranges, but permit this only for synchronous
> > implementations? Then, we could update the skcipher walker code to
> > produce a single walk step covering the entire range, and just use the
> > provided virtual addresses directly, rather than going through a
> > mapping interface?
>
> Since skcipher doesn't actually need to carry any state with it
> I'd like to avoid having an skcipher_request at all.

Doesn't that depend on the implementation? It might have a >0 size
request context size, no? Or do we just allocate that on the stack?