linux-kernel - Re: [PATCH] crypto: caam: disable pkc for non-E 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1517fbd7-8f23-f5f5-983d-469a1856bbe8@nxp.com>
Date:   Thu, 23 Sep 2021 17:26:45 +0300
From:   Horia Geantă <horia.geanta@....com>
To:     Michael Walle <michael@...le.cc>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     Pankaj Gupta <pankaj.gupta@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH] crypto: caam: disable pkc for non-E SoCs

On 9/22/2021 8:55 PM, Michael Walle wrote:
> Am 22. September 2021 17:51:23 MESZ schrieb "Horia Geantă" <horia.geanta@....com>:
>> On 9/16/2021 1:03 AM, Michael Walle wrote:
>>> On newer CAAM versions, not all accelerators are disabled if the SoC is
>>> a non-E variant. While the driver checks most of the modules for
>>> availability, there is one - PKHA - which sticks out. On non-E variants
>> Currently there's no dedicated support for "partially disabled" non-E
>> (export-controlled) parts in Linux kernel caam driver(s).
>>
>> Up until recently firmware (U-boot) was deleting the "crypto" DT node
>> for all non-E parts [1].
>> Modifying the f/w indeed triggers changes across the s/w stack.
> 
> Well, it does check if a module is available or not. And this seem to be the only module which have "something in between". I.e. the number of available modules is not zero but it also doesn't work as expected. 
> 
>> Since you are modifying only the caam code handling PKHA, is it correct
>> to assume that everything else is working fine?
> 
> Everything else is skipped because the "number of instances" is zero. 
> 
>> For example: is the number of AES accelerators (AESA_VERSION[AESA_NUM])
>> being reported as 0 on non-E parts? 
> 
> yes, see above. 
> 
Ok, thanks for confirming.
Documentation is not clear about what happens when the "NSEC" fuse is blown.

It looks like the reported number of accelerator instances is not reflecting
what's "built" into caam IP block, but what is available.
Blowing the "NSEC" fuse permanently disables some accelerators (e.g. AES),
while others are either not affected (e.g. MDHA, RNG) or partially disabled
(when they implement also functions that are not export-controlled) - only PKHA
seems to be in the last case.

>>> it is still reported as available, that is the number of instances is
>>> non-zero, but it has limited functionality. In particular it doesn't
>>> support encryption and decryption, but just signing and verifying. This
>>> is indicated by a bit in the PKHA_MISC field. Take this bit into account
>>> if we are checking for availablitly.
>> typo:			 ^ availability
> 
> If there is nothing else wrong, could this be fixed while applying?
> 
Fine by me, but Herbert will have to do this.

>>>
>>> This will the following error:
>>> [    8.167817] caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected.
>>>
>>> Tested on an NXP LS1028A (non-E) SoC.
>> Thanks.
>> Unfortunately I don't have a non-E part to test on.
> 
> You can take a look at the ls1028a RM where this bit is. described to verify what the patch is doing ;) 
> 
Yes, I've done this already.

Reviewed-by: Horia Geantă <horia.geanta@....com>

Thanks,
Horia