linux-kernel - Re: [PATCH v6 12/14] crypto: caam - force DMA address to 32-bit on 64-bit i.MX SoCs

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]

Date:   Tue, 13 Aug 2019 11:50:33 -0700
From:   Andrey Smirnov <andrew.smirnov@...il.com>
To:     Horia Geanta <horia.geanta@....com>
Cc:     "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        Chris Spencer <christopher.spencer@....co.uk>,
        Cory Tusar <cory.tusar@....aero>,
        Chris Healy <cphealy@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Aymen Sghaier <aymen.sghaier@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 12/14] crypto: caam - force DMA address to 32-bit on
 64-bit i.MX SoCs

On Tue, Aug 13, 2019 at 6:38 AM Horia Geanta <horia.geanta@....com> wrote:
>
> On 8/12/2019 10:27 PM, Andrey Smirnov wrote:
> > On Mon, Aug 5, 2019 at 1:23 AM Horia Geanta <horia.geanta@....com> wrote:
> >>
> >> On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> >>> @@ -603,11 +603,13 @@ static int caam_probe(struct platform_device *pdev)
> >>>               ret = init_clocks(dev, ctrlpriv, imx_soc_match->data);
> >>>               if (ret)
> >>>                       return ret;
> >>> +
> >>> +             caam_ptr_sz = sizeof(u32);
> >>> +     } else {
> >>> +             caam_ptr_sz = sizeof(dma_addr_t);
> >> caam_ptr_sz should be deduced by reading MCFGR[PS] bit, i.e. decoupled
> >> from dma_addr_t.
> >>
> >
> > MCFGR[PS] is not mentioned in i.MX8MQ SRM and MCFG_PS in CTPR_MS is
> > documented as set to "0" (seems to match in real HW as well). Doesn't
> > seem like a workable solution for i.MX8MQ. Is there something I am
> > missing?
> >
> If CTPR_MS[PS]=0, this means CAAM does not allow choosing the "pointer size"
> via MCFGR[PS]. Usually in this case the RM does not document MCFGR[PS] bit,
> which is identical to MCFGR[PS]=0.
>
> Thus the logic should be smth. like:
>         caam_ptr_sz = CTPR_MS[PS] && MCFGR[PS] ? 64 : 32;
>

Where is PS located in MCFGR? Same as in CTPR_MS, i.e. BIT(17)?

> >> There is another configuration that should be considered
> >> (even though highly unlikely):
> >> caam_ptr_sz=1  - > 32-bit addresses for CAAM
> >> CONFIG_ARCH_DMA_ADDR_T_64BIT=n - 32-bit dma_addr_t
> >> so the logic has to be carefully evaluated.
> >>
> >
> > I don't understand what you mean here. 32-bit CAAM + 32-bit dma_addr_t
> > should already be the case for i.MX6, etc. how is what you describe
> > different?
> >
> Sorry for not being clear.
>
> caam_ptr_sz=1  - > 32-bit addresses for CAAM
> should have been
> caam_ptr_sz=*64*  - > 32-bit addresses for CAAM
> i.e. CAAM address has "more than" (>) 32 bits (exact number of bits is
> SoC / chassis specific) and thus will be represented on 8 bytes.
>

Ah, I see. Can this use-case be addressed in a separate series when
the need for it arises?

Thanks,
Andrey Smirnov