linux-kernel - Re: [PATCH 00/11] crypto: ccree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOtvUMeiaFzL1E49Vy5+MY96_g=91eW3AnkDG1+1ZRoTekJYew@mail.gmail.com>
Date:   Sun, 26 Jan 2020 15:37:58 +0200
From:   Gilad Ben-Yossef <gilad@...yossef.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Ofir Drang <ofir.drang@....com>, Hadar Gat <hadar.gat@....com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 00/11] crypto: ccree - fixes and cleanups

On Thu, Jan 23, 2020 at 10:09 PM Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
>
> Hi Gilad,
>
> On Thu, Jan 23, 2020 at 7:19 PM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> > On Thu, Jan 23, 2020 at 5:46 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Thu, Jan 23, 2020 at 12:44 PM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> > > > On Wed, Jan 22, 2020 at 6:51 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > > > On Thu, Jan 16, 2020 at 11:25 AM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> > > > > > A bunch of fixes and code cleanups for the ccree driver
> > > > >
> > > > > Thank you!
> > > > >
> > > > > I wanted to give this a try, but it looks like CCREE is no longer working
> > > > > on R-Car H3, both with/without this series.
> > > > >
> > > > > E.g. with renesas-devel[*] and renesas_defconfig +
> > > > > CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n, I get the following crash:
> > > >
> > > > Thank you for the bug report Geert!
> > > >
> > > > My R-Car board is on loan at the moment to another project. I didn't
> > > > see this on our internal test board.
> > > > I will track down my R-Car board and reproduce this - hopefully
> > > > beginning of next week and will get back to you.
> > >
> > > In the mean time, I've bisected this failure to commit cdfee5623290bc89
> > > ("driver core: initialize a default DMA mask for platform device").
> > > However, this looks like a red herring, and seems to be only an exposer
> > > of an underlying problem.
> >
> > Thank you for continue digging into this.
> >
> > > What's happening is that cc_map_aead_request() receives a request with
> > > cryptlen = 0.  Due to DRV_CRYPTO_DIRECTION_ENCRYPT, the length to map is
> > > increased by 8.  This seems to works fine if there is sufficient space
> > > in the request's scatterlist.  However, if the scatterlist has only a
> > > single entry of size zero, cc_map_sg() tries to map a zero-length DMA
> > > buffer, and the BUG)() is triggered.
> > >
> >
> > OK, this does rings a bell - can you verify please if
> > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is enabled and if it does can you
> > see if it happens if it is turned off?
>
> No, I didn't have that option enabled.

OK, I still did not get reunited with my R-Cat board, but I think I
have a direction.

I'm about to send an RFC patch which while  probably does not address
the root cause
will stop the crash if the issue is what I think it is and so will let
me know what you are
seeing is what I think you are seeing.

I'd be delighted if you can give it a spin...

Thanks,
Gilad