242 lines
8.6 KiB
Plaintext
242 lines
8.6 KiB
Plaintext
|
Introduction:
|
||
|
|
=============
|
||
|
|
|
||
|
|
The Qualcomm crypto engine (qce40) driver is a module that
|
||
|
|
provides common services for accessing the Qualcomm crypto device.
|
||
|
|
Currently, the two main clients of qce40 are
|
||
|
|
-qcrypto driver (module provided for accessing CE HW by kernel space apps)
|
||
|
|
-qcedev driver (module provided for accessing CE HW by user space apps)
|
||
|
|
This module provides the same interface to the clients as does qce.c and is
|
||
|
|
based off qce.c. Following are the updates from qce.c
|
||
|
|
- Add support for AES XTS mode
|
||
|
|
- Add support for CMAC mode
|
||
|
|
- Add support for AES CCM mode
|
||
|
|
- Add support for SHA1/SHA256 HMAC
|
||
|
|
- Read HASH/MAC information directly from CE hardware registers instead of
|
||
|
|
using datamover.
|
||
|
|
|
||
|
|
The crypto engine (qce40) module is a client to the DMA driver for the Qualcomm
|
||
|
|
DMA device - Application Data Mover (ADM). ADM is used to provide the DMA
|
||
|
|
transfer capability between Qualcomm crypto device hardware and DDR memory
|
||
|
|
for crypto operations.
|
||
|
|
|
||
|
|
Figure 1.
|
||
|
|
---------
|
||
|
|
|
||
|
|
Linux kernel
|
||
|
|
(ex:IPSec)<--*Qualcomm crypto driver----+
|
||
|
|
(qcrypto) |
|
||
|
|
(for kernel space app) |
|
||
|
|
|
|
||
|
|
+-->|
|
||
|
|
|
|
||
|
|
| *qce40 <----> Qualcomm
|
||
|
|
| driver ADM driver <---> ADM HW
|
||
|
|
+-->| | |
|
||
|
|
| | |
|
||
|
|
| | |
|
||
|
|
| | |
|
||
|
|
Linux kernel | | |
|
||
|
|
misc device <--- *QCEDEV Driver-------+ | |
|
||
|
|
interface (qcedev) (Reg interface) (DMA interface)
|
||
|
|
(for user space app) \ /
|
||
|
|
\ /
|
||
|
|
\ /
|
||
|
|
\ /
|
||
|
|
\ /
|
||
|
|
\ /
|
||
|
|
\ /
|
||
|
|
Qualcomm crypto CE3 HW
|
||
|
|
|
||
|
|
|
||
|
|
The entities marked with (*) in the Figure 1, are the software components of
|
||
|
|
the Linux Qualcomm crypto modules.
|
||
|
|
|
||
|
|
===============
|
||
|
|
IMPORTANT NOTE:
|
||
|
|
===============
|
||
|
|
(1) The CE hardware can be accessed either from user space OR kernel space,
|
||
|
|
at one time. Both user space and kernel space clients cannot access the
|
||
|
|
qce driver (and the CE hardware) at the same time.
|
||
|
|
- If your device has user space apps that needs to access the crypto
|
||
|
|
hardware, make sure to have the qcrypto module disabled/unloaded.
|
||
|
|
This will result in the kernel space apps to use the registered
|
||
|
|
software implementation of the crypto algorithms.
|
||
|
|
- If your device has kernel space apps that needs to access the
|
||
|
|
crypto hardware, make sure to have qcedev module disabled/unloaded
|
||
|
|
and implement your user space application to use the software
|
||
|
|
implemenation (ex: openssl/crypto) of the crypto algorithms.
|
||
|
|
|
||
|
|
(2) If your device has Playready(Windows Media DRM) application enabled and
|
||
|
|
uses the qcedev module to access the crypto hardware accelarator,
|
||
|
|
please be informed that for performance reasons, the CE hardware will need
|
||
|
|
to be dedicated to playready application. Any other user space application
|
||
|
|
should be implemented to use the software implemenation (ex: openssl/crypto)
|
||
|
|
of the crypto algorithms.
|
||
|
|
|
||
|
|
|
||
|
|
Hardware description:
|
||
|
|
=====================
|
||
|
|
|
||
|
|
Qualcomm Crypto HW device family provides a series of algorithms implemented
|
||
|
|
in the device hardware.
|
||
|
|
|
||
|
|
Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
|
||
|
|
algorithms, and concurrent operations of hashing and ciphering.
|
||
|
|
|
||
|
|
In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides
|
||
|
|
fast AES algorithms.
|
||
|
|
|
||
|
|
In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
|
||
|
|
HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as
|
||
|
|
defined by the 3GPP forum.
|
||
|
|
|
||
|
|
|
||
|
|
Software description
|
||
|
|
====================
|
||
|
|
|
||
|
|
The crypto device is defined as a platform device. The driver is
|
||
|
|
independent of the platform. The driver supports multiple instances of
|
||
|
|
crypto HW.
|
||
|
|
All the platform specific parameters are defined in the board init
|
||
|
|
file, eg. arch/arm/mach-msm/board-msm8960.c for MSM8960.
|
||
|
|
|
||
|
|
The qce40 driver provide the common services of HW crypto
|
||
|
|
access to the two drivers as listed above (qcedev, qcrypto. It sets up
|
||
|
|
the crypto HW device for the operation, then it requests ADM driver for
|
||
|
|
the DMA of the crypto operation.
|
||
|
|
|
||
|
|
Two ADM channels and two command lists (one command list for each
|
||
|
|
channel) are involved in an operation.
|
||
|
|
|
||
|
|
The setting up of the command lists and the procedure of the operation
|
||
|
|
of the crypto device are described in the following sections.
|
||
|
|
|
||
|
|
The command lists contains a single command. For the first DMA channel it
|
||
|
|
is set up as follows:
|
||
|
|
|
||
|
|
The command is for the DMA transfer from DDR memory to the
|
||
|
|
crypto device to input data to crypto device. The dst crci of the command
|
||
|
|
is set for crci-in for this crypto device.
|
||
|
|
|
||
|
|
The command list for the second DMA channel is set up as follows:
|
||
|
|
|
||
|
|
One command to DMA data from crypto device to DDR memory for encryption or
|
||
|
|
decryption output from crypto device.
|
||
|
|
|
||
|
|
To accomplish ciphering and authentication concurrent operations, the driver
|
||
|
|
performs the following steps:
|
||
|
|
(a). set up HW crypto device
|
||
|
|
(b). hit the crypto go register.
|
||
|
|
(c). issue the DMA command of first channel to the ADM driver,
|
||
|
|
(d). issue the DMA command of 2nd channel to the ADM driver.
|
||
|
|
|
||
|
|
SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish
|
||
|
|
hash operation (or any authentication only algorithm), 2nd DMA channel is
|
||
|
|
not required. Only steps (a) to (c) are performed.
|
||
|
|
|
||
|
|
At the completion of the DMA operation (for (c) and (d)) ADM driver
|
||
|
|
invokes the callback registered to the DMA driver. This signifies the end of
|
||
|
|
the DMA operation(s). The driver reads the status and other information from
|
||
|
|
the CE hardware register. For HASH functions (SHA1/SHA256, HMAC, CMAC and
|
||
|
|
CCM) were the MAC/HASH information is read off hardware registers.
|
||
|
|
|
||
|
|
[ NOTE: This is different from what is done in the qce module that support
|
||
|
|
CE3.x hardware. In CE4.0 there is not CRCI_HASH and hence we cannot rely
|
||
|
|
on the data mover to populate the HMAC/SHA information. This information
|
||
|
|
is acquired fromte h ahrdware by reading directly from some registers that
|
||
|
|
hold this information ]
|
||
|
|
|
||
|
|
The driver than nvokes the callback to the qce driver client.
|
||
|
|
This signal the completion and the results of the DMA along with the status of
|
||
|
|
the CE hardware to the qce40 driver client. This completes a crypto operation.
|
||
|
|
|
||
|
|
In the qce40 driver initialization, memory for the two command lists, descriptor
|
||
|
|
lists for each crypto device are allocated out of coherent memory, using Linux
|
||
|
|
DMA API. The driver pre-configures most of the two ADM command lists
|
||
|
|
in the initialization. During each crypto operation, minimal set up is required.
|
||
|
|
src_dscr or/and dst_dscr descriptor list of the ADM command are populated
|
||
|
|
from the information obtained from the corresponding data structure. eg: for
|
||
|
|
AEAD request, the following data structure provides the information:
|
||
|
|
|
||
|
|
struct aead_request *req
|
||
|
|
......
|
||
|
|
req->assoc
|
||
|
|
req->src
|
||
|
|
req->dst
|
||
|
|
|
||
|
|
The DMA address of a scatter list will be retrieved and set up in the
|
||
|
|
descriptor list of an ADM command.
|
||
|
|
|
||
|
|
Power Management
|
||
|
|
================
|
||
|
|
none
|
||
|
|
|
||
|
|
|
||
|
|
Interface:
|
||
|
|
==========
|
||
|
|
|
||
|
|
The interface is defined in kernel/drivers/crypto/msm/inc/qce.h
|
||
|
|
|
||
|
|
The clients qcrypto, qcedev drivers are the clients using
|
||
|
|
the interfaces.
|
||
|
|
|
||
|
|
The following services are provided by the qce driver -
|
||
|
|
|
||
|
|
qce_open(), qce_close(), qce_ablk_cipher_req(),
|
||
|
|
qce_hw_support(), qce_process_sha_req()
|
||
|
|
|
||
|
|
qce_open() is the first request from the client, ex. Qualcomm crypto
|
||
|
|
driver (qcedev, qcrypto), to open a crypto engine. It is normally
|
||
|
|
called at the probe function of the client for a device. During the
|
||
|
|
probe,
|
||
|
|
- ADM command list structure will be set up
|
||
|
|
- Crypto device will be initialized.
|
||
|
|
- Resource associated with the crypto engine is retrieved by doing
|
||
|
|
platform_get_resource() or platform_get_resource_byname().
|
||
|
|
|
||
|
|
The resources for a device are
|
||
|
|
- crci-in, crci-out, crci-hash-done
|
||
|
|
- two DMA channel IDs, one for encryption and decryption input, one for
|
||
|
|
output.
|
||
|
|
- base address of the HW crypto device.
|
||
|
|
|
||
|
|
qce_close() is the last request from the client. Normally, it is
|
||
|
|
called from the remove function of the client.
|
||
|
|
|
||
|
|
qce_hw_support() allows the client to query what is supported
|
||
|
|
by the crypto engine hardware.
|
||
|
|
|
||
|
|
qce_ablk_cipher_req() provides ciphering service to the client.
|
||
|
|
qce_process_sha_req() provides hashing service to the client.
|
||
|
|
qce_aead_req() provides aead service to the client.
|
||
|
|
|
||
|
|
|
||
|
|
Module parameters:
|
||
|
|
==================
|
||
|
|
|
||
|
|
The following module parameters are defined in the board init file.
|
||
|
|
-CE hardware base register address
|
||
|
|
-Data mover channel used for transfer to/from CE hardware
|
||
|
|
These parameters differ in each platform.
|
||
|
|
|
||
|
|
|
||
|
|
Dependencies:
|
||
|
|
=============
|
||
|
|
|
||
|
|
Existing DMA driver.
|
||
|
|
The transfers are DMA'ed between the crypto hardware and DDR memory via the
|
||
|
|
data mover, ADM. The data transfers are set up to use the existing dma driver.
|
||
|
|
|
||
|
|
User space utilities:
|
||
|
|
=====================
|
||
|
|
n/a
|
||
|
|
|
||
|
|
Known issues:
|
||
|
|
=============
|
||
|
|
n/a
|
||
|
|
|
||
|
|
To do:
|
||
|
|
======
|
||
|
|
n/a
|