Clarification on memory requirements for DCP functions (non-cached?)

[karl_fraasch]

I am using the DCP AES nonblocking API. Based on what I can tell from the sample app, I have declared all inputs 

- plaintext

-ciphertext

-iv

with the macro AT_NONCACHEABLE_SECTION_ALIGN_INIT (16 byte alignment). However, I would like to understand if this is necessary or not. My assumption is inputs to this function must be stored in a "non-cached" memory. Therefore this is why I used the compiler macro above. Below is the specific API I am using.

/*!
 * @brief Encrypts AES using CBC block mode.
 *
 * Puts AES CBC encrypt dcpPacket to DCP input job ring.
 *
 * @param base DCP peripheral base address
 * @param handle Handle used for this request. Specifies jobRing.
 * @param[out] dcpPacket Memory for the DCP work packet.
 * @param plaintext Input plain text to encrypt
 * @param[out] ciphertext Output cipher text
 * @param size Size of input and output data in bytes. Must be multiple of 16 bytes.
 * @param iv Input initial vector to combine with the first input block.
 * @return kStatus_Success The work packet has been scheduled at DCP channel.
 * @return kStatus_DCP_Again The DCP channel is busy processing previous request.
 */
status_t DCP_AES_EncryptCbcNonBlocking(DCP_Type *base,
                                       dcp_handle_t *handle,
                                       dcp_work_packet_t *dcpPacket,
                                       const uint8_t *plaintext,
                                       uint8_t *ciphertext,
                                       size_t size,
                                       const uint8_t *iv);

[Alexis_A]

hello @karl_fraasch 

The problem here is that xTCM memories are not cached, OCRAM and SDRAM are cached memories. Likely in the code, core as well as DCP access memories. If core use cached (especially write-back) access and DCP not then potentially some data in-coherency can occur.

Best Regards,

Alexis Andalon

[ffm]

Having recently studied the SDK examles i can say that alignment constraints exist only on optionally used software key and on the IV. This is due to the used copy method for those parameters which is implemented by means of word transfers. The API could allow even IV and software key to be given without aligment constraints, if the sub-words to be stored to the related registers where created driver intern. Another constraint plaintext and ciphertext is that size is an even multiple of 16 bytes / 4 words sue to the nature of the cipher algorithm which has a block size of 16 bytes. And of course even due to the algorithm, key and IV must be exactly 16 bytes.

So for plaintext and ciphertext there is no alignmet constraint. Key and IV don't need 16-byte alignment. Alignmet to 4 byte is enough.

I cannot say anything about the cacheability contraints.

[Alexis_A]

Hello @karl_fraasch,

As the example in the SDK shows, input data for DCP should be stored in non-cached memory.

Best Regards,
Alexis Andalon