
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
Содержание Layerscape LS1028A BSP
Страница 135: ......