linux-kernel - RE: [PATCH] dmaengine: dw-edma: fix endianess confusion

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: <DM6PR12MB4010649558DA330077EB23AADAE70@DM6PR12MB4010.namprd12.prod.outlook.com>
Date:   Fri, 21 Jun 2019 10:44:34 +0000
From:   Gustavo Pimentel <Gustavo.Pimentel@...opsys.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Gustavo Pimentel <Gustavo.Pimentel@...opsys.com>
CC:     Vinod Koul <vkoul@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] dmaengine: dw-edma: fix endianess confusion

On Fri, Jun 21, 2019 at 9:55:11, Arnd Bergmann <arnd@...db.de> wrote:

> On Fri, Jun 21, 2019 at 10:42 AM Gustavo Pimentel
> <Gustavo.Pimentel@...opsys.com> wrote:
> > On Mon, Jun 17, 2019 at 14:17:47, Arnd Bergmann <arnd@...db.de> wrote:
> >
> > > When building with 'make C=1', sparse reports an endianess bug:
> >
> > I didn't know that option.
> >
> > >
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:60:30: warning: cast removes address space of expression
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in argument 1 (different address spaces)
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const volatile [noderef] <asn:2>*addr
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] ptr
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in argument 1 (different address spaces)
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const volatile [noderef] <asn:2>*addr
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] ptr
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in argument 1 (different address spaces)
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const volatile [noderef] <asn:2>*addr
> > > drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] ptr
> > >
> > > The current code is clearly wrong, as it passes an endian-swapped word
> > > into a register function where it gets swapped again. I assume that this
> >
> > Sorry I didn't catch this, endianness-swapped word into a register
> > function where it gets swapped again?
> > Where?
> 
> See dw_edma_v0_core_write_chunk()
> 
>                 sar = cpu_to_le64(child->sar);
>                 SET_LL(&lli[i].sar_low, lower_32_bits(sar));
>                 SET_LL(&lli[i].sar_high, upper_32_bits(sar));
> 
> SET_LL() expands to writel(), which does a cpu_to_le32() swap.
> (the swap  gets left out on architectures that are little-endian only)

That's right! I didn't look inside of writel().

> 
> > > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c
> > > index 97e3fd41c8a8..d670ebcc37b3 100644
> > > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c
> > > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c
> > > @@ -195,7 +195,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk)
> > >       struct dw_edma_v0_lli __iomem *lli;
> > >       struct dw_edma_v0_llp __iomem *llp;
> > >       u32 control = 0, i = 0;
> > > -     u64 sar, dar, addr;
> > > +     uintptr_t sar, dar, addr;
> >
> > Will this type assure variables sar, dar and addr are 64 bits?
> 
> No, just as long as a pointer. I somehow misread these as
> referring to a kernel pointer, but got that part wrong. The
> local variables can just be dropped then, just use
> lower_32_bits(child->sar)) etc.
> 
> > >       int j;
> > >
> > >       lli = chunk->ll_region.vaddr;
> > > @@ -214,11 +214,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk)
> > >               /* Transfer size */
> > >               SET_LL(&lli[i].transfer_size, child->sz);
> > >               /* SAR - low, high */
> > > -             sar = cpu_to_le64(child->sar);
> > > +             sar = (uintptr_t)child->sar;
> >
> > Assuming the host is a big-endian machine and the eDMA on the endpoint
> > strictly requires the address to be little endian.
> > By not using cpu_to_le64(), the address to be written on the eDMA will be
> > in big-endian format, right? If so, that will break the driver.
> 
> No, because of the double-swap you are writing a big-endian address
> here, which is the bug I am referring to.

After doing a quick exercise I realize that cpu_to_le64() shouldn't be 
there at all like you said. Since I only tested this driver on 
little-endian architecture system this issue wasn't visible at all.

> 
>      Arnd