On Fri, 29 May 2020 at 14:02, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, May 29, 2020 at 02:00:14PM +0200, Ard Biesheuvel wrote: > > > > Even if this is the case, it requires that an skcipher implementation > > stores an output IV in the buffer that skcipher request's IV field > > points to. Currently, we only check whether this is the case for CBC > > implementations, and so it is quite likely that lots of h/w > > accelerators or arch code don't adhere to this today. > > They are and have always been broken because algif_skcipher has > always relied on this. > OK, so the undocumented assumption is that algif_skcipher requests are delineated by ALG_SET_IV commands, and that anything that gets sent to the socket in between should be treated as a single request, right? I think that makes sense, but do note that this deviates from Stephan's use case, where the ciphertext stealing block swap was applied after every call into af_alg, with the IV being inherited from one request to the next. I think that case was invalid to begin with, I just hope no other use cases exist where this unspecified behavior is being relied upon. > > This might be feasible for the generic CTS driver wrapping h/w > > accelerated CBC. But how is this supposed to work, e.g., for the two > > existing h/w implementations of cts(cbc(aes)) that currently ignore > > this? > > They'll have to disable chaining. > > The way I'm doing this would allow some implementations to allow > chaining while others of the same algorithm can disable chaining > and require the whole request to be presented together. > Fair enough.
