linux-kernel - Re: [PATCH] crypto: caam - use the same jr for rng init/exit

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:   Fri, 20 Sep 2019 15:50:24 +0000
From:   Horia Geanta <horia.geanta@....com>
To:     Andrey Smirnov <andrew.smirnov@...il.com>
CC:     "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        Chris Healy <cphealy@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Iuliana Prodan <iuliana.prodan@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] crypto: caam - use the same jr for rng init/exit

On 9/18/2019 9:01 AM, Andrey Smirnov wrote:
> On Wed, Sep 11, 2019 at 2:35 AM Horia Geanta <horia.geanta@....com> wrote:
>>
>> On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
>>> In order to allow caam_jr_enqueue() to lock underlying JR's
>>> device (via device_lock(), see commit that follows) we need to make
>>> sure that no code calls caam_jr_enqueue() as a part of caam_jr_probe()
>>> to avoid a deadlock. Unfortunately, current implementation of caamrng
>>> code does exactly that in caam_init_buf().
>>>
> 
> I don't think your patch addresses the above, so it can probably be
> cut out of the message.
> 
No, it does not, it addresses the issue right below.

Not sure what you mean by "cut out of the message". If you look carefully
in the original message, at some pointer there is a scissors line.

>>> Another big problem with original caamrng initialization is a
>>> circular reference in the form of:
>>>
>>>  1. caam_rng_init() aquires JR via caam_jr_alloc(). Freed only by
>>>     caam_rng_exit()
>>>
>>>  2. caam_rng_exit() is only called by unregister_algs() once last JR
>>>     is shut down
>>>
>>>  3. caam_jr_remove() won't call unregister_algs() for last JR
>>>     until tfm_count reaches zero, which can only happen via
>>>     unregister_algs() -> caam_rng_exit() call chain.
>>>
>>> To avoid all of that, convert caamrng code to a platform device driver
>>> and extend caam_probe() to create corresponding platform device.
>>>
>>> Additionally, this change also allows us to remove any access to
>>> struct caam_drv_private in caamrng.c as well as simplify resource
>>> ownership/deallocation via devres.
>>>
>> I would avoid adding platform devices that don't have
>> corresponding DT nodes.
>>
>> There's some generic advice here:
>> https://www.kernel.org/doc/html/latest/driver-api/driver-model/platform.html#legacy-drivers-device-probing
>>
>> and there's also previous experience in caam driver:
>> 6b175685b4a1 crypto: caam/qi - don't allocate an extra platform device
>>
> 
> Hmm, I am not sure how that experience relates to the case we have
> with hwrng, but OK, I'm going to assume that platform driver approach
> is a no-go.
> 
Not specific to hwrng, but platform drivers in general:
    [...]
    SMMU. A platform device allocated using platform_device_register_full()
    is not completely set up - most importantly .dma_configure()
    is not called.

Horia