xts.c and block size inkonsistency? cannot pass generic driver comparision tests

[Kestrel seventyfour <kestrelseventyfour@gmail.com>]

Hi,

I have also added xts aes on combining the old hardware cbc algorithm
with an additional xor and the gfmul tweak handling. However, I
struggle to pass the comparision tests to the generic xts
implementation.

In detail, xts.c exposes the block size of the underlying algo, which
is AES_BLOCK_SIZE. But it does not use the walk functions, because
they do not work if the input is not dividable by blocksize. Now the
xts.c has its own implementation, but I wonder, if that implementation
should accept input sizes other than dividable by block size?

Actually if xts would only accept multiples of block size, the cipher
text stealing would be obsolete. If I use walksize=1, I get the issues
with the unaligned or splitted scatterlists.

I really would prefer using walk just returning the remaining bytes
instead of moving out with -EINVAL:
https://elixir.bootlin.com/linux/latest/source/crypto/skcipher.c#L360
Is that intentional? For me its not logical to allow any input size to
xts, but the walk functions return errors if there are inputs not a
multiple of block size. Furthermore, its a waste of resources to
process all previous walks and then return an error on the last walk?!

I would expect xts to work in a similar way as ecb and ignore extra bytes?
https://elixir.bootlin.com/linux/latest/source/crypto/ecb.c#L36

Or is the advice simply, implement xts to work as in xts.c without
using walks and not worry about the inkonsistencies?

Thanks,
D. Kestrel