On Fri, 10 Mar 2023 at 11:15, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Feb 20, 2023 at 08:28:05AM +0100, Ard Biesheuvel wrote: > > > > We would still not have any in-tree users of cfb(aes) or any other > > cfb(*), so in that sense, yes. > > > > However, skciphers can be called from user space, and we also rely on > > this template for the extended testing of the various cfb() hardware > > implementations that we have in the tree. > > > > So the answer is no, I suppose. I would like to simplify it a bit, > > though - it is a bit more complicated than it needs to be. > > Could we hold onto this for a little bit? I'd like to finally > remove crypto_cipher, and in doing so I will add a virtual address > interface (i.e., not sg) to skcipher like we do with scomp and shash. > 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. 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?
