linux-kernel - Re: [RFC] crypto: caam: re-init JR on resume

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: <VI1PR0402MB348516318CA986084CBE7B5C98ED0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
Date:   Tue, 25 Feb 2020 14:53:34 +0000
From:   Horia Geanta <horia.geanta@....com>
To:     Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Aymen Sghaier <aymen.sghaier@....com>
CC:     "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] crypto: caam: re-init JR on resume

On 2/21/2020 10:43 AM, Matthias Schiffer wrote:
> On Mon, 2020-02-03 at 11:18 +0100, Matthias Schiffer wrote:
>> The JR loses its configuration during suspend-to-RAM (at least on
>> i.MX6UL). Re-initialize the hardware on resume.
>>
>> Signed-off-by: Matthias Schiffer <matthias.schiffer@...tq-group.com>
>> ---
>>
>> I've come across the issue that the CAAM would not work anymore after
>> deep sleep on i.MX6UL. It turned out that the CAAM loses its state
>> during suspend-to-RAM, so all registers read as zero and need to be
>> reinitialized.
>>
>> This patch is my first attempt at fixing the issue. It seems to work
>> well enough, but I assume I'm missing some synchronization to prevent
>> that some CAAM operation is currently under way when the suspend
>> happens? I don't know the PM and crypto subsystems well enough to
>> judge
>> if this is possible, and if it is, how to prevent it.
>>
>> I've only compile-tested this version of the patch, as I had to port
>> it
>> from our board kernel, which is based on the heavily-modified NXP
>> branch.
> 
> It would be great to get some feedback on this patch. Is the hardware
> support to lose its state? Does my fix look correct?
> 
For most parts, yes, CAAM HW block loses state.

We are working at upstreaming PM support.

A non-exhaustive high-level list of things to be done, on top of your patch:
-caam controller driver (ctrl.c) also needs support for PM,
for e.g. RNG has to be reinitialized when resuming
-caam/jr driver: a few other registers have to be saved & restored
-caam/jr driver: flush/abort the jobs in the input ring when suspending
-implementations of algorithms using "split key" (a.k.a. "derived key"),
which is a black / encrypted key, have to convert the key to
a persistent blob since KEKs (JDKEK, TDKEK, TDSK registers) are lost
and in certain cases cannot be restored to initial values

Horia