28 Jan, 2021

2 commits


27 Jan, 2021

3 commits


26 Jan, 2021

9 commits


25 Jan, 2021

5 commits


22 Jan, 2021

10 commits


21 Jan, 2021

3 commits

  • In case no job rings are available, secure memory structures are not
    initialized, since caam_jr_probe()->init_misc_func()->caam_sm_startup()
    is not called.
    This could happen if all job ring devices bind to the jr uio driver
    instead of the caam/jr driver.
    Running sm_test in this case will lead to a crash.

    Add a check to verify that SM has been initialized - if not the tests
    will be skipped.

    Reported-by: Gaurav Jain
    Signed-off-by: Horia Geantă
    Reviewed-by: Gaurav Jain

    Horia Geantă
     
  • Introduction
    ===

    Currently we are facing some limitations in the caam/jr module lifecycle.
    There are some discussion in upstream:
    Link: https://lore.kernel.org/linux-crypto/20190904023515.7107-13-andrew.smirnov@gmail.com
    Link: https://lore.kernel.org/linux-crypto/20191105151353.6522-1-andrew.smirnov@gmail.com
    but in the end it all seems to get down to implementations not being able
    to gracefully unregister crypto algorithms from crypto API while there are
    users / allocated tfms (cra_refcnt > 1).

    [*] OTOH functionalities in caam/jr that don't interact with crypto API
    (like Secure Memory or black keys / blobs generation) don't face this
    limitation.

    Issue at hand
    ===

    When unloading the caam_jr module, the .remove callback for the last JR
    device exits with -EBUSY (see "Introduction" above) and doesn't perform
    the clean-up (crypto algorithms unregistering etc.).

    One side effect of this is leeding to an oops, which occurs due to a
    corruption in the linked list of "misc devices"
    (drivers/char/misc.c - misc_list):
    1. caam_jr module is unloaded without calling unregister_algs()->
    caam_keygen_exit()->misc_deregister() for the last job ring device;
    this leaves a dangling entry in the misc_list double-linked list
    2. rng_core module is unloaded and calls misc_deregister(); this implies
    removing the corresponding entry in the misc_list; while doing this the
    dangling entry is accessed - which leads to an oops since the address is
    no longer valid (address points to the caam_jr module address space,
    but caam_jr has been previously unloaded).

    Fix this by moving the clean-up of non-crypto related functionalities [*]
    before crypto related ones.

    Fixes: 3af836d4b311 ("MLK-24420-3 crypto: caam - add ioctl calls for black keys and blobs generation")
    Signed-off-by: Horia Geantă
    Reviewed-by: Gaurav Jain

    Horia Geantă
     
  • In case of long format of qDMA command descriptor, there are one frame
    descriptor, three entries in the frame list and two data entries. So the
    size of dma_pool_create for these three fields should be the same with
    the total size of entries respectively, or the contents may be overwritten
    by the next allocated descriptor.

    Signed-off-by: Guanhua Gao

    Guanhua Gao
     

20 Jan, 2021

8 commits