Re: [Bug] s5p-sss crypto driver doesn't set next AES-CBC IV

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 19 Feb 2019 at 10:58, Kamil Konieczny
<k.konieczny@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> On 15.02.2019 19:51, Eric Biggers wrote:
> > Hello,
> >
> > The AES-CBC implementation in the s5p-sss crypto driver is failing the improved
> > crypto self-tests I currently have out for review.  The improved tests check
> > that all CBC implementations update the IV buffer to be the last ciphertext
> > block.  This has always been required so that requests can be chained, but
> > unfortunately it wasn't tested for by the self-tests until now.
> >
> > See the boot logs for Exynos platforms from the KernelCI job here:
> > https://kernelci.org/boot/all/job/ardb/branch/for-kernelci/kernel/v5.0-rc1-149-g64c945c018af/
> >
> > alg: skcipher: cbc-aes-s5p encryption test failed (wrong output IV) on test vector 0, cfg=\"in-place\"
> > 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
> > [...]
>
> I checked dmesg logs after my patch with:
>
> root@target:~# dmesg |grep alg: |grep aes
> [    4.087168] crypto: alg: self-tests for aes-generic (aes) passed
> [    6.305202] crypto: alg: self-tests for ecb-aes-s5p (ecb(aes)) passed
> [    6.405489] crypto: alg: self-tests for cbc-aes-s5p (cbc(aes)) passed
> [    6.505000] crypto: alg: self-tests for ctr-aes-s5p (ctr(aes)) passed
>
> and I noticed there are no cbc-aes-generic nor ctr-aes-generic
>
> Did you test them in separate tree ? Why they are not registered in /proc/crypto ?
>

Generic CBC and CTR are template based, so they are only instantiated on demand.



[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux