In Linux v6.6, the crypto_engine_ctx structure was removed and the
crypto_engine_ops was moved from this structure to the crypto_alg
structure. The Tegra Security Engine driver was updated accordingly to
populate the crypto_engine_ops in the appropriate structure depending
on whether the crypto_engine_ctx structure is present or not.
Currently conftest is using the presence of the crypto_engine_ctx
structure to decide where to populate the crypto_engine_ops. While
this works, it is possible that a kernel older than v6.6 also includes
a backport of commit e5e7eb023f24 ("crypto: engine - Move
crypto_engine_ops from request into crypto_alg") that moves the ops
to the crypto_alg structure. Although backporting this commit alone
should not cause any problems, it is better to detect if this commit
is present rather than relying on the presence of crypto_engine_ctx
structure.
To detect the presence of commit e5e7eb023f24 we can simply detect if
one of the functions added and exported by this commit is present.
For example, the function crypto_engine_register_aead() was added and
exported by this commit. Therefore, update conftest to detect if
commit e5e7eb023f24 is present and then update the Tegra Security
Engine accordingly.
Bug 5564561
Change-Id: I3f7688e6e954a158094a9a2fdf73354f765ed680
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3499816
(cherry picked from commit c1631d32f8d80cd31f54e7297c542f308a281d25)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3508186
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
The HW supports only storing 15 keys at a time. This limits the number
of tfms that can work without failutes. Reserve keyslots to solve this
and use the reserved ones during the encryption/decryption operation.
This allow users to have the capability of hardware protected keys
and faster operations if there are limited number of tfms while not
halting the operation if there are more tfms.
Bug 4883011
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Change-Id: I7de17eb1acf3b5a9f55a42e9df2aa8b64e20cb6d
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3347661
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
The intermediate hash values generated during an update task were
handled incorrectly in the driver. The values have a defined format for
each algorithm. Copying and pasting from the HASH_RESULT register
balantly would not work for all the supported algorithms. This incorrect
handling causes failures when there is a context switch between multiple
operations.
To handle the expected format correctly, add a separate buffer for
storing the intermediate results for each request. Remove the previous
copy/paste functions which read/wrote to the registers directly. Instead
configure the hardware to get the intermediate result copied to the
buffer and use host1x path to restore the intermediate hash results.
Bug 4883011
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Change-Id: I54952620906ccfd57d560c4619d17211f67b9ac3
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3328440
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Ahash init() function was called asynchronous to the crypto engine queue.
This could corrupt the request context if there is any ongoing operation
for the same request. Queue the init function as well to the crypto
engine queue so that this scenario can be avoided.
Bug 4883011
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Change-Id: I7d5e4629fbd47215c7d7748b675030c1cb63e5ea
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3328439
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
The buffer which sends the commands to host1x was shared for all tasks
in the engine. This causes a problem with the setkey() function as it
gets called asynchronous to the crypto engine queue. Modifying the same
cmdbuf in setkey() will corrupt the ongoing host1x task and in turn
break the encryption/decryption operation. Hence use a separate cmdbuf
for setkey().
Bug 4883011
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Change-Id: Ia6a5376e2c8dfc98e11414666ebf9ade41f10fee
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3328437
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
