On Tue, 20 Aug 2019 at 12:57, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > On Tue, 20 Aug 2019 at 13:24, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > > > On Mon, 19 Aug 2019 at 16:24, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > > > Align the s5p ctr(aes) implementation with other implementations > > > of the same mode, by setting the block size to 1. > > > > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > > --- > > > drivers/crypto/s5p-sss.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c > > > index ef90c58edb1f..010f1bb20dad 100644 > > > --- a/drivers/crypto/s5p-sss.c > > > +++ b/drivers/crypto/s5p-sss.c > > > @@ -2173,7 +2173,7 @@ static struct crypto_alg algs[] = { > > > .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | > > > CRYPTO_ALG_ASYNC | > > > CRYPTO_ALG_KERN_DRIVER_ONLY, > > > - .cra_blocksize = AES_BLOCK_SIZE, > > > + .cra_blocksize = 1, > > > > This makes sense but I wonder how does it work later with > > s5p_aes_crypt() and its check for request length alignment > > (AES_BLOCK_SIZE). With block size of 1 byte, I understand that > > req->nbytes can be for example 4 bytes which is not AES block > > aligned... If my reasoning is correct, then the CTR mode in s5p-sss is > > not fully working. > > > > > I re-ran the kernelci.org tests with this change, and I saw no more failures. > > https://kernelci.org/boot/all/job/ardb/branch/for-kernelci/kernel/v5.3-rc1-197-gc8809c50be4f/ Indeed, self tests are passing. Anyway the change is correct so: Reviewed-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> Best regards, Krzysztof