Requests are submitted indirectly via Queue Manager (QMan) HW block that is part of DPAA1.
• Data Path SEC Interface (DPSECI) - available on SoCs implementing DPAA v2.x
Similar to QI, requests are submitted via Queue Manager (QMan) HW block; however, the architecture is different -
instead of using the platform bus, the Management Complex (MC) bus is used, MC firmware performing needed
configuration to link DP* objects - see DPAA2 Linux Software chapter for more details.
NXP provides device drivers for all these interfaces. Current chapter is focused on JRI, though some general / common topics
are also covered. For QI and DPSECI backends and compatible frontends, please refer to the dedicated chapters: for DPAA1,
Security Engine for DPAA2.
On top of these backends, there are the "frontends" - drivers that sit between the Linux Crypto API and backend drivers. Their
main tasks are to:
• register supported crypto algorithms
• process crypto requests coming from users (via the Linux Crypto API) and translate them into the proper format understood
by the backend being used
• forward the CAAM engine responses from the backend being used to the users
Note: It is obvious that QI and DPSECI backends cannot co-exist (they can be compiled in the same "multi-platform" kernel image,
however run-time detection will make sure only the proper one is active). However, JRI + QI and JRI + DPSECI are valid
combinations, and both backends will be active if enabled; if a crypto algorithm is supported by both corresponding frontends (for
e.g. both caamalg and caamalg_qi register cbc(aes)), a user requesting cbc(aes) will be bound to the implementation having the
highest "crypto algorithm priority". If the user wants to use a specific implementation:
• it is possible to ask for it explicitly by using the specifc (unique) "driver name" instead of the generic "algorithm name" - please
see official Linux kernel Crypto API documentation (section Crypto API Cipher References And Priority); currently default
priorities are: 3000 for JRI frontend and 2000 for QI and DPSECI frontends
• crypto algorithm priority could be changed dynamically using the "Crypto use configuration API" (provided that
CONFIG_CRYPTO_USER is enabled); one of the tools available that is capable to do this is "Linux crypto layer configuration
tool" and an example of increasing the priority of QI frontend based implementation of
echainiv(authenc(hmac(sha1),cbc(aes))) algorithm is:
$ ./crconf update driver "echainiv-authenc-hmac-sha1-cbc-aes-caam-qi" type 3 priority 5000
Figure 3. Linux kernel - SEC device drivers overview
Linux kernel
Layerscape LS1028A BSP User Guide, Rev. 0.3, 04/2019
64
NXP Semiconductors
To Next Page
Loading...
