qseecom.ko is a loadable kernel module which acts as the QTI secure client
in the non-secure world. It provides a sample interface for communicating with
the secure world(QSEE) and TME-L for various crypto and other miscellaneous operations.

The TZ binary provides support for secure AES, ECC and RSA crypto operations.

TME-L supports AES crypto operations directly from HLOS if IPC support is
available in the target.

Similar to TZ, customers can develop a custom application(aka TZapp) to be
used for secure crypto and other functionalities. This custom application will
be loaded into the tzapp reserved memory region captured in the device tree source.
Note: All the requests to Tzapp will be routed via TZ.

Summary of all the supported operations via qseecom for various targets is
listed in the below table.

        ______________________________________________________
        |                      |         |         |         |
        |      Operations      | IPQ95xx | IPQ53xx | IPQ54xx |
________|______________________|_________|_________|_________|
|       |                      |         |         |         |
|       |   RSA(sign/verify)   |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|  TZ   |        AESv1         |    Y    |    Y    |    N    |
|       |                      |         |         |         |
|       |        AESv2         |    Y    |    Y    |    Y    |
|_______|______________________|_________|_________|_________|
|       |                      |         |         |         |
| TME-L |         AES          |    N    |    N    |    Y    |
|_______|______________________|_________|_________|_________|
|       |                      |         |         |         |
|       | Basic Multiplication |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|       |    Sample Crypto     |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|       |     RSA(enc/dec)     |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|       |        AESv2         |    Y    |    Y    |    Y    |
| TZAPP |                      |         |         |         |
|       |      Fuse read       |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|       |     Fuse write       |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|       |     Logbitmask       |    Y    |    Y    |    Y    |
|       |                      |         |         |         |
|       |        Misc          |    Y    |    Y    |    Y    |
|_______|______________________|_________|_________|_________|

--------------------------------------------------------------------------------

TZ operations

TZ supports both AES and RSA crypto operations.
The AES operations can be performed in two ways:
AESv1 -> Supported via a crypto library in TZ (Supported chipsets:IPQ95xx/IPQ53xx)
         A key blob will be generated, containing the actual AES key, but encrypted
         with a device-unique key not visible to non-secure code, and returned
         to user, which can be used for encrypt/decrypt operations.
AESv2 -> Key derivation is supported via a hardware sequencer in TME-L (Supported chipsets: IPQ95xx/IPQ53xx/IPQ54xx)
         A key will be derived by TME-L and stored in TZ. Only the key handle
         will be returned to the user. User can decide which key handle needs
         to be used for encrypt/decrypt operations.

Please refer the qseecom_props structure in qseecom driver(drivers/misc/qseecom.c)
to know the list of TZ API's supported by each platform.
Note: IPQ53xx platform uses the same qseecom_props structure of IPQ95xx platform.

--------------------------------------------------------
|Steps for triggering secure RSA crypto operation in TZ|
--------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

RSA API: (qseecom_props function = RSA_SEC_KEY)
It is used for signing and verifying data based on RSA algorithm with public
and private keys in TZ.

RSA pad scheme:
Select the required RSA padding scheme with the below sysfs entry (1 -> PKCS, 2 -> PSS)
(1) eg: echo 1 > /sys/rsa_sec_key/rsa_pad_scheme
View the selected RSA pad scheme as shown below
(2) cat /sys/rsa_sec_key/rsa_pad_scheme

Generate or Import the key blob to be used for encrypt/decrypt

RSA Generate Key blob:
Choose the key size for RSA generate operation (0->2k, 1->4k)
(1) eg: echo 0 > /sys/rsa_sec_key/rsa_keysize
Note: Default size is 2k
(2) cat /sys/rsa_sec_key/rsa_generate > key_blob.txt

RSA Import Key blob:
(1) cat hex.dat > /sys/rsa_sec_key/rsa_import
(2) cat /sys/rsa_sec_key/rsa_import > import_key_blob.txt

Note:
hex.dat contents must be a properly generated RSA vector.

spec of the hex.dat file used in RSA Import Key blob:
hex.dat size is 1066 bytes.

1066 bytes split up:
        528 bytes -> import modulus
        2 bytes -> import modulus length in hexadecimal
        5 bytes -> public exponent
        1 byte -> public exponent length in hexadecimal
        528 bytes -> private exponent
        2 bytes -> private exponent length in hexadecimal

public, private exponent can be any value other than 3
modulus can be any value lesser than 4096

RSA Sign data:
(1) cat key_blob.txt > /sys/rsa_sec_key/rsa_key_blob
    or
    cat import_key_blob.txt > /sys/rsa_sec_key/rsa_key_blob
(2) echo -n "data.txt" > /sys/rsa_sec_key/rsa_sign
    (Note: data.txt is the input file that contains plain data.
     The plain data max size is 2k bytes.)
(3) cat /sys/rsa_sec_key/rsa_sign > signed_data.txt

RSA Verification of Signature:
(1) cat key_blob.txt > /sys/rsa_sec_key/rsa_key_blob
    or
    cat import_key_blob.txt > /sys/rsa_sec_key/rsa_key_blob
(2) cat signed_data.txt > /sys/rsa_sec_key/rsa_verify
(3) cat /sys/rsa_sec_key/rsa_verify > verification_result.txt
(4) cat verification_result.txt

RSA Update key blob:
Use these steps to update the padding scheme present in a key blob
(1) cat key_blob.txt > /sys/rsa_sec_key/rsa_key_blob
    or
    cat import_key_blob.txt > /sys/rsa_sec_key/rsa_key_blob
    Note: Users can also input an externally saved key blob which was not created
          using Generate/Import commands
Select the padding type (1 -> PKCS, 2 -> PSS)
(2) eg: echo 2 > /sys/rsa_sec_key/rsa_pad_scheme
(3) cat /sys/rsa_sec_key/rsa_update_keyblob > updated_key_blob.txt

Note:
RSA generate functionality can take random amount of time to execute. This is
because in this RSA algorithm we have to generate 2 random numbers with certain
properties and then proceed. We can use the RSA import functionality if in case
time is a concern.

The shk seed value in fuses is 0 by default in non-secure ipq targets for IPQ807x/IPQ50xx/IPQ60xx
To make the keyblobs target dependent, shk values must be changed from default value in non-secure target systems.
Without doing this, we will be able to encrypt in one board and decrypt in another board using the same keyblob.
Note: For IPQ95xx/IPQ53xx targets, this will be taken care by TME-L.

----------------------------------------------------------
|Steps for triggering secure AESv1 crypto operation in TZ|
----------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx

AES TZ API: (qseecom_props function = AES_SEC_KEY)
This is used for performing AES encrypt/decrypt operations in TZ.

AES Generate Key blob:
(1) cat /sys/sec_key/generate > key_blob.txt

AES Import Key blob:
(1) cat key.txt > /sys/sec_key/import
(2) cat /sys/sec_key/import > imported_key_blob.txt

Note: TZ takes care of IV and AES mode/type
AES Encrypt data:
(1) cat key_blob.txt > /sys/sec_key/key_blob
    or
    cat imported_key_blob.txt > /sys/sec_key/key_blob
(2) cat data.txt > /sys/sec_key/seal
Note: size of data.txt must be less than 2K bytes
(3) cat /sys/sec_key/seal > encrypted_data.txt

AES Decrypt data:
(1) cat key_blob.txt > /sys/sec_key/key_blob
    or
    cat imported_key_blob.txt > /sys/sec_key/key_blob
(2) cat encrypted_data.txt > /sys/sec_key/unseal
(3) cat /sys/sec_key/unseal

----------------------------------------------------------
|Steps for triggering secure AESv2 crypto operation in TZ|
----------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

AES 256 V2 TZ API's supported in TME-L based platform can be used as below:
(qseecom_props function = AES_SEC_KEY aes_v2 = true)

Below are sample inputs:

Context data is 64 or 128 bytes which can be fed as below:
(1) echo -n "34613132613738396434316363323738656166343132363635613831643530313461313261373839643431636332373865616634313236363561383164353031" > /sys/sec_key/context_data

source_data determines which base key to be used for derivation.
It can be either 1 (OEM product seed) or 2 (CRBK)
(2) echo 1 > /sys/sec_key/source_data

bindings data has device and software state bindings for key:
(3) echo 32 > /sys/sec_key/bindings_data

To derive the key with given inputs:
(4) cat /sys/sec_key/derive_aes_key > key_handle.txt
(5) cat key_handle.txt

(or)

To derive the key for 128 byte context:
(4) cat /sys/sec_key/derive_aes_max_ctxt_key > key_handle.txt
(5) cat key_handle.txt

clear key API:
Note:
The user cannot derive more than 3 keys. Trying to derive a 4th key would result
in an error saying "key handle out of slot". If the user wants to derive a new key
after 3 successful attempts, then the user has to clear an already existing key
by passing it's key handle to the clear_key sysfs entry. Once a derived key handle
is cleared, the key cannot be used for further encryption/decryption of data.

To clear a derived key:
eg: cat key_handle.txt > /sys/sec_key/clear_key

Giving the required aes256 parameters:
In encrypt/decrypt SCM call, TZ will send distribute IPC to TMEL to distribute
the derived Key to destination slots in (CE5 for IPQ95xx / TCSR Regs for
IPQ53xx and IPQ54xx). There are 2 destination slots available & depending on the
destination index passed via aes_type entry, the keys will be distributed to
the respective slots and will be used for encrypt/decrypt operations.
Either of these slots can be specified before encrypt/decrypt calls.
1 -> destination slot 1
2 -> destination slot 2
Example:
(6) echo 1 > /sys/sec_key/aes_type
aes_mode can be either 0 (ECB) or 1 (CBC)
(7) echo 1 > /sys/sec_key/aes_mode
(8) echo -n -e \\x69\\x01\\x50\\x05\\x26\\x35\\x27\\x2c\\xf4\\xe0\\x19\\x1c\\xa9\\x74\\x36\\x45 > /sys/sec_key/aes_ivdata

Specify the key handle to be used for encrypt/decrypt:
(9) cat key_handle.txt > /sys/sec_key/derive_aes_key

To encrypt:
(10) echo "Aes Encryption!" > /sys/sec_key/aes_encrypt
Note: Input plain text must be less than 2K bytes and a multiple of AES
block size which is 16 bytes.
(11) cat /sys/sec_key/aes_encrypt > /tmp/enc.txt

To decrypt:
(12) cat /tmp/enc.txt > /sys/sec_key/aes_decrypt
(13) cat /sys/sec_key/aes_decrypt > /tmp/pt.txt
(14) cat /tmp/pt.txt

-------------------------------------------------------------------------------

TME-L IPC operations

In IPC supported targets, the AES operations can also be performed via IPC calls
direcly to TME-L instead of routing via TZ.

------------------------------------------------------
|Steps for performing AES crypto operation from TME-L|
------------------------------------------------------
Supported targets: IPQ54xx

AES 256 API's supported in TME-L based platform can be used as below:
(qseecom_props function = AES_SEC_KEY ipc_support = true)

key handle for AES encrypt/decrypt can be obtained in three ways: (Generate/Import/Derive)

Generate:
Key will be generated using PRNG
Provide AES256 mode (0->ECB 1->CBC)
(1) echo 0 > /sys/tmel_sec_key/tmel_aes_mode
Generate key handle
(2) cat /sys/tmel_sec_key/tmel_aes_generate_key > key_handle.txt

Import:
Key will be generated using the plain text key provided by user
Provide AES256 mode (0->ECB 1->CBC)
(1) echo 0 > /sys/tmel_sec_key/tmel_aes_mode
Provide plain text key
Example:
(2) echo -n "01234567890123456789012345678901" > pt_key.txt
(3) cat pt_key.txt > /sys/tmel_sec_key/tmel_aes_pt_key
Import key handle
(4) cat /sys/tmel_sec_key/tmel_aes_import_key > key_handle.txt

Derive:
CRBK or OEM product seed stored in the chip will be used to derive a key
Provide AES256 mode (0->ECB 1->CBC)
(1) echo 0 > /sys/tmel_sec_key/tmel_aes_mode
Provide base key (0->CRBK 1->OEM Product seed)
(2) echo 0 > /sys/tmel_sec_key/tmel_aes_input_key
Context data is 64 or 128 bytes which can be fed as below:
Example:
(3) echo -n "34613132613738396434316363323738656166343132363635613831643530313461313261373839643431636332373865616634313236363561383164353032" > /sys/tmel_sec_key/tmel_aes_context_data
Provide the security bindings for KDF context. Please refer the Crypto user
guide for the list of supported values. By default software context is applied.
The security bindings can be provided as below,
Example:
echo 32 > /sys/tmel_sec_key/tmel_aes_sec_ctx
Note: If software context is used as security bindings, salt/label will be included
in KDF context. The salt/label can be 64 bytes at max and can be fed as below:
Example:
(4) echo -n "0123456789012345678901234567890123456789012345678901234567890123" > /sys/tmel_sec_key/tmel_aes_salt_label_data
Derive key handle
(5) cat /sys/tmel_sec_key/tmel_aes_derive_key > key_handle.txt

Once a key handle is obtained via any of the three operations mentioned above,
it can be used for encrypt/decrypt operations.

Note: TME-L will generate IV internally for AES encryption and does not accept IV
from user.

To encrypt:
Provide the key handle to used for enc/dec
(1) cat key_handle.txt > /sys/tmel_sec_key/tmel_aes_key
Provide the plain text to encrypt. Note: Plain text must be multiple of AES block size (i.e 16 bytes) and less than 2k bytes
Example:
(2) echo "Aes Encryption!" > /sys/tmel_sec_key/tmel_aes_encrypt
(3) cat /sys/tmel_sec_key/tmel_aes_encrypt > enc.txt

To decrypt:
(1) cat enc.txt > /sys/tmel_sec_key/tmel_aes_decrypt
(2) cat /sys/tmel_sec_key/tmel_aes_decrypt > dec.txt
(3) cat dec.txt

Clear:
(1) cat key_handle.txt > /sys/tmel_sec_key/tmel_aes_clear_key
Note: User cannot get more than 4 key handles from TME-L. Trying to get a 5th key
would result in an error. If the user wants to get a new key handle after 4 successful
attempts, then the user has to clear an already existing key by passing it's key
handle to the clear_key sysfs entry. Once a key handle is cleared, the key cannot
be used for further encryption/decryption of data.

--------------------------------------------------------------------------------

TZapp operations

For each platform, TZapp memory has been reserved in the QTI default device
tree and the reference of that reserved memory node should be given in qseecom
node for using the TZ App functionalities. If in case, the reserved memory node
reference is not given, TZAapp cannot be used.

Available APIs in kernel which can be reused/extended:

(1) qti_scm_qseecom_notify       -> to notify the load region of application
(2) qti_scm_qseecom_load         -> to load the libraries and application
(3) qti_scm_qseecom_send_data    -> to send data to perform operation
(4) qti_scm_qseecom_unload       -> to unload the application and libraries
(5) qti_scm_tz_register_log_buf -> to register a log buf for sample app logs

Refer to source code in drivers/misc/qseecom.c for re-using the above APIs. This
can be modified or extended to support vendor applications.

Across any platforms, apps can be loaded and functionalities can be performed
securely from the non-secure world via the scm interface.

Below are the steps to load a sample TZapp(aka sampleapp) to perform
crypto and other miscellaneous operations:

Sampleapp Usage Instructions:
Note: We support only 64 bit sampleapp in ipq platforms.

-----------------------------------------
|Steps to load the library and sampleapp|
-----------------------------------------

Before loading the sample app, the library required by sample app needs to be
loaded.

(1) To load sample app libraries

Concatenate all the seg files into 1 segment file and feed it as
input to sys/firmware/seg_file and feed the mdt file as input to
sys/firmware/mdt_file as below:

cat cmnlib.b00 > cmnlib.b0x
cat cmnlib.b01 >> cmnlib.b0x
cat cmnlib.b02 >> cmnlib.b0x
cat cmnlib.b03 >> cmnlib.b0x
cat cmnlib.b04 >> cmnlib.b0x
cat cmnlib.b05 >> cmnlib.b0x

Now cat the mdt and combined binary files to sysfs entries as below:

cat cmnlib.mdt > /sys/firmware/mdt_file
cat cmnlib.b0x > /sys/firmware/seg_file

echo 0 > /sys/firmware/tzapp/load_start

You will get a print saying you have successfully loaded app libraries.

(2) To load sample app

Concatenate all the seg files into 1 segment file and feed it as
input to sys/firmware/seg_file and feed the mdt file as input to
sys/firmware/mdt_file as below:

cat sampleapp.b00 > sampleapp.b0x
cat sampleapp.b01 >> sampleapp.b0x
cat sampleapp.b02 >> sampleapp.b0x
cat sampleapp.b03 >> sampleapp.b0x
cat sampleapp.b04 >> sampleapp.b0x
cat sampleapp.b05 >> sampleapp.b0x
cat sampleapp.b06 >> sampleapp.b0x
cat sampleapp.b07 >> sampleapp.b0x

Now cat the mdt and combined binary files to sysfs entries as below:

cat sampleapp.mdt > /sys/firmware/mdt_file
cat sampleapp.b0x > /sys/firmware/seg_file

echo 1 > /sys/firmware/tzapp/load_start

You will get a print saying you have Successfully loaded TZApp and services.

Note: The number of segment files in lib/app can change between
platforms and all the segment files as available should be
concatenated using above/similar commands accordingly.

Please refer the qseecom_props structure in qseecom driver to know the list of TZapp API's
supported by each platform.
Note: IPQ53xx platform uses the same qseecom_props structure of IPQ95xx platform.

Note: sampleapp logging has been enabled for QSEE sample app.
The default size of the log buffer is 4k bytes. However it can be increased by
changing the QSEE_LOG_BUF_SIZE macro in qseecom.h file.

To view the log at any point after loading the sample app from kernel, please use below command:
cat /sys/kernel/debug/tzapp_log

The sampleapp supports below operations:
(1) Basic multiplication test
(2) Sample crypto test
(3) RSA crypto
(4) AESv2 crypto
(5) Fuse read
(6) Fuse write
(7) Logbitmask
(8) Misc

Description and steps for each of these operations are mentioned below.

-------------------------------------------------------------------
|Steps for triggerring basic multiplication operation in sampleapp|
-------------------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

The following multiplication operation can be tested in all the platforms: (qseecom_props function = MUL)
It multiplies the provided input by 10.

To give input to Multiplication op:
echo 100 > /sys/firmware/tzapp/basic_data

To view Secure Multiplication output:
cat /sys/firmware/tzapp/basic_data

----------------------------------------------------
|Steps for triggering crypto operation in sampleapp|
----------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

The "crypto" sysfs entry triggers the sample test encryption and decryption routines
inside secure app and displays the result if the test has passed or failed.

To test Crypto functionality: (qseecom_props function = CRYPTO)
echo 1 > /sys/firmware/tzapp/crypto

Results can be viewed in /sys/kernel/debug/tzapp_log

--------------------------------------------------------
|Steps for triggering RSA crypto operation in sampleapp|
--------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

RSA TZAPP API: (qseecom_props function = RSA_TZAPP)
It is used for encrypting/decrypting data based on RSA algorithm in TZapp.

The input plain-text size must match the RSA key size.
Example for RSA 2048:
(1) dd if=input.txt of=256.txt bs=256 count=1

Input the keys
Note: Max size of each key is 528 bytes
(2) echo "056b04216fe5f354ac77250a4b6b0c8525a85c59b0bd80c56450a22d5f438e596a333aa875e291dd43f48cb88b9d5fc0d499f9fcd1c397f9afc070cd9e398c8d19e61db7c7410a6b2675dfbf5d345b804d201add502d5ce2dfcb091ce9997bbebe57306f383e4d588103f036f7e85d1934d152a323e4a8db451d6f4a5b1b0f102cc150e02feee2b88dea4ad4c1baccb24d84072d14e1d24a6771f7408ee30564fb86d4393a34bcf0b788501d193303f13a2284b001f0f649eaf79328d4ac5c430ab4414920a9460ed1b7bc40ec653e876d09abc509ae45b525190116a0c26101848298509c1c3bf3a483e7274054e15e97075036e989f60932807b5257751e79" > /sys/firmware/tzapp/rsa/private_exponent_key
(3) echo "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010001" > /sys/firmware/tzapp/rsa/public_exponent_key
(4) echo "ae45ed5601cec6b8cc05f803935c674ddbe0d75c4c09fd7951fc6b0caec313a8df39970c518bffba5ed68f3f0d7f22a4029d413f1ae07e4ebe9e4177ce23e7f5404b569e4ee1bdcf3c1fb03ef113802d4f855eb9b5134b5a7c8085adcae6fa2fa1417ec3763be171b0c62b760ede23c12ad92b980884c641f5a8fac26bdad4a03381a22fe1b754885094c82506d4019a535a286afeb271bb9ba592de18dcf600c2aeeae56e02f7cf79fc14cf3bdc7cd84febbbf950ca90304b2219a7aa063aefa2c3c1980e560cd64afe779585b6107657b957857efde6010988ab7de417fc88d8f384c4e6e72c3f943e0c31c0c4a5cc36f879d8a3ac9d7d59860eaada6b83bb" > /sys/firmware/tzapp/rsa/modulus_key

Provide required RSA parameters
Specify the key bit length (Number of bits in modulus)
(5) Eg: echo 2048 > /sys/firmware/tzapp/rsa/nbits_key
Specify the hashid to be used
(Refer qti_storage_service_qsee_hash_id data type in qseecom.h for supported values)
(6) Eg: echo 2 > /sys/firmware/tzapp/rsa/hashidx
Specify RSA padding type (2-> No padding)
Note: Currently only no padding is supported
(7) Eg: echo 2 > /sys/firmware/tzapp/rsa/padding_type

Encrypt RSA:
(8) cat 256.txt > /sys/firmware/tzapp/rsa/encrypt_rsa
(9) cat /sys/firmware/tzapp/rsa/encrypt_rsa > sam.txt
(10) cat /sys/kernel/debug/tzapp_log

Decrypt RSA:
(11) cat sam.txt > /sys/firmware/tzapp/rsa/decrypt_rsa
(12) cat /sys/firmware/tzapp/rsa/decrypt_rsa > sam1.txt
(13) cat sam1.txt

----------------------------------------------------------
|Steps for triggering AESv2 crypto operation in sampleapp|
----------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

AES 256 v2 TZAPP API's supported in TME-L based platform can be used as below:
(qseecom_props function = AES_TZAPP aes_v2 = true)

Context data is 64 bytes which can be fed as below:
(1) echo -n "34613132613738396434316363323738656166343132363635613831643530313461313261373839643431636332373865616634313236363561383164353031" > /sys/firmware/tzapp/aes/context_data_aes

source_data determines which base key to be used for derivation.
It can be either 1 (OEM product seed) or 2 (CRBK)
(2) echo 1 > /sys/firmware/tzapp/aes/source_data_aes

bindings data has device and software state bindings for key:
(3) echo 32 > /sys/firmware/tzapp/aes/bindings_data_aes

Derive key handle
(4) cat /sys/firmware/tzapp/aes/derive_key_aes > key_handle.txt
(5) cat key_handle.txt

Note:
The user cannot derive more than 3 keys. Trying to derive a 4th key would result
in an error saying "key handle out of slot". If the user wants to derive a new key
after 3 successful attempts, then the user has to clear an already existing key
by passing it's key handle to the clear_key sysfs entry. Once a derived key handle
is cleared, the key cannot be used for further encryption/decryption of data.

To clear a derived key from qtiapp:
eg: cat key_handle.txt > /sys/firmware/tzapp/aes/clear_key_qtiapp

Giving the required aes parameters:
In encrypt/decrypt SCM call, TZ will send distribute IPC to TMEL to distribute
the derived Key to destination slots in (CE5 for IPQ95xx / TCSR Regs for
IPQ53xx and IPQ54xx). There are 2 destination slots available & depending on the
destination index passed via type_aes entry, the keys will be distributed to
the respective slots and will be used for encrypt/decrypt operations.
Either of these slots can be specified before encrypt/decrypt calls.
1 -> destination slot 1
2 -> destination slot 2
Example:
(6) echo 1 > /sys/firmware/tzapp/aes/type_aes
mode_aes can be either 0 (ECB) or 1 (CBC)
(7) echo 1 > /sys/firmware/tzapp/aes/mode_aes
(8) echo -n -e \\x69\\x01\\x50\\x05\\x26\\x35\\x27\\x2c\\xf4\\xe0\\x19\\x1c\\xa9\\x74\\x36\\x45 > /sys/firmware/tzapp/aes/ivdata_aes

Specify the key handle to be used for encrypt/decrypt:
(9) cat key_handle.txt > /sys/firmware/tzapp/aes/derive_key_aes

Encrypt AES:
(10) echo "Aes Encryption!" > /sys/firmware/tzapp/aes/encrypt_aes
Note: Input plain text must be less than 2K bytes and a multiple of AES
block size which is 16 bytes.
(11) cat /sys/firmware/tzapp/aes/encrypt_aes > /tmp/enc.txt

Decrypt AES:
(12) cat /tmp/enc.txt > /sys/firmware/tzapp/aes/decrypt_aes
(13) cat /sys/firmware/tzapp/aes/decrypt_aes > /tmp/pt.txt
(14) cat /tmp/pt.txt

--------------------------------------------------
|Steps for triggering fuse operation in sampleapp|
--------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

It tests if it can read fuses for the allowed regions from TA (Trusted APPS).
For example the allowed regions for IPQ53xx platform are shown below.

QFPROM_RAW_OEM_CONFIG_REGION:
QFPROM_RAW_OEM_SECURE_BOOT_REGION:
QFPROM_RAW_OEM_SPARE_REGION_31_REGION:
QFPROM_RAW_FEC_ENABLES_REGION:

(1) echo 1 > /sys/firmware/tzapp/fuse
(2) cat /sys/kernel/debug/tzapp_log

-------------------------------------------------------
|Steps for triggering fusewrite operation in sampleapp|
-------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

Fusewrite: (qseecom_props function = FUSE_WRITE)

To write into fuses from TA (Trusted APPS)

Input the fuse address according to target
(1) echo <fuse addr> > /sys/firmware/tzapp/fuse_write/addr

(2) echo 0x1 > /sys/firmware/tzapp/fuse_write/value
(3) echo 0 > /sys/firmware/tzapp/fuse_write/fec_enable (fec - forward error correction. Set this entry to enable error correction in fuse)
(4) echo 1 > /sys/firmware/tzapp/fuse_write/blow
(5) cat /sys/kernel/debug/tzapp_log

--------------------------------------------------------
|Steps for triggering Logbitmask operation in sampleapp|
--------------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

TZapp supports different logging levels. This API will set mask for different log levels and checks if only expected logs are present.
If expected logs are present then success is returned.
User should check the /sys/kernel/debug/tzapp_log to see the result.

If the below print is seen in tzapp_log, then it means the logbitmask test has encountered some error while testing the different log levels.
-- ALERT: Should Not see this - run_log_bitmask_test----

(1) echo 1 > /sys/firmware/tzapp/log_bitmask
(2) cat /sys/kernel/debug/tzapp_log

--------------------------------------------------
|Steps for triggering misc operation in sampleapp|
--------------------------------------------------
Supported targets: IPQ95xx/IPQ53xx/IPQ54xx

Misc API: (qseecom_props function = MISC)

This API runs some miscellaneous tests to test the QSEE API's for malloc, free and some other string manipulation functions.

(1) echo 1 > /sys/firmware/tzapp/misc
(2) cat /sys/kernel/debug/tzapp_log

---------------------------
|Steps to unload sampleapp|
---------------------------

To unload the sampleapp

echo 2 > /sys/firmware/tzapp/load_start

The libraries used by sample app are automatically unloaded when the device
driver is removed (i.e. during rmmod to remove the qseecom module).

If the user doesn't unload the app, then the app is unloaded when the
device driver is removed.
