linux-kernel - Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG

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:   Tue, 3 Jul 2018 12:01:32 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Fabio Estevam <festevam@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        linux-ntb@...glegroups.com,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Horia Geantă <horia.geanta@....com>,
        Dan Douglass <dan.douglass@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when
 using io{read|write}64



On 03/07/18 11:36 AM, Andy Shevchenko wrote:
>> This is now in linux-next as commit 46e4bf08f6388 and it breaks
>> booting imx6 (32-bit ARM):
> 
> 
>> Any ideas on how to fix this issue?
> 
> Oops, first of all the header should be hi-lo instead of lo-hi.
> Does it fix it?
> 
> Otherwise I didn't (briefly) see what can be the issue.

I had to dig to find this: but Horia had said[1] that the HW was
specified to use lo-hi and I think we ended up changing to that for this
commit based on his feedback. This is also mentioned in the commit message.

Besides that, it looks like we are hitting an undefined instruction. So
my best guess is that we are somehow now calling a proper 64bit read
when we should be calling two 32-bit reads.

Fabio, can you send your configuration?

Thanks,

Logan

[1]
http://lkml.kernel.org/r/VI1PR0401MB259145C2DFDB5E4084EA5DFC98D20@VI1PR0401MB2591.eurprd04.prod.outlook.com