On Thu, 18 Jul 2019 at 09:22, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote: > > > > Not just the generic implementation: there are numerous synchronous > > and asynchronous implementations of xts(aes) in the kernel that would > > have to be fixed, while there are no in-kernel users that actually > > rely on CTS. Also, in the cbc case, we support CTS by wrapping it into > > another template, i.e., cts(cbc(aes)). > > > > So retroactively redefining what xts(...) means seems like a bad idea > > to me. If we want to support XTS ciphertext stealing for the benefit > > of userland, let's do so via the existing cts template, and add > > support for wrapping XTS to it. > > XTS without stealing should be renamed as XEX. Sure you can then > wrap it inside cts to form xts but the end result needs to be called > xts. > If we were adding XTS to the kernel today, then I would agree with you. But xts() has an established meaning now, and I don't think it makes sense to update all implementations for a theoretical use case, given that no portable userland code can rely on the correct semantics today, since CAAM is the only one that implements them correctly. In any case, I won't have time to fix the ARM or arm64 implementations (or review the changes if someone else steps up) until the end of September.
