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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Jan 2020 21:08:52 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Gilad Ben-Yossef <gilad@...yossef.com>
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

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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds