SHA3 Final appears to write outside of bounds

[xes-pbrodnick]

When executing a SHA3 Final IPI operation the DMA appears to corrupt bytes outside the 384 bit (48 byte) output buffer.

I believe this is due to calls to XPlmi_DmaXfr with the length specified in bytes rather than words

From sw_services/xilsecure/src/common/versal_common/server/xsecure_sha_ipihandler.c

			/* Initiate and complete the DMA to DMA transfer */
			Status = XPlmi_DmaXfr((u64)(UINTPTR)(Hash.Hash), DstAddr,
				XSECURE_HASH_SIZE_IN_BYTES, XPLMI_PMCDMA_0);

Here XSECURE_HASH_SIZE_IN_BYTES is 48, but the XPlmi_DmaXfr() routine states that it takes words (I verified this by reviewing the XPlmi_MemCpy64 routine which shifts the byte length by the XPLMI_WORD_LEN_SHIFT macro.)

/*****************************************************************************/
/**
 * @brief	This function is used to initiate and complete the DMA to DMA transfer.
 *
 * @param	SrcAddr for SRC channel to fetch data from
 * @param	DestAddr for DST channel to store the data
 * @param	Len of the data in words
 * @param	Flags to select PMC DMA and DMA Burst type
 *
 * @return
 * 			- XST_SUCCESS on success.
 * 			- XPLMI_ERR_DMA_XFER_WAIT_SRC if Dma Xfer failed in Src Channel
 * 			wait for done.
 * 			- XPLMI_ERR_DMA_XFER_WAIT_DEST if Dma Xfer failed in Dest Channel
 * 			wait for done.
 *
 *****************************************************************************/
int XPlmi_DmaXfr(u64 SrcAddr, u64 DestAddr, u32 Len, u32 Flags)

[praveent-amd]

Thanks @xes-pbrodnick for reporting. your analysis is correct, and this will be fixed in the upcoming (2024.1) release.