AM263P4: Issues related to the function implementations in `Hsmclient.c` for AM263P4

Hi,

mingzhe dai said:

Question 1:
After receiving the `RespMsg.args` returned from the HSM core, aside from performing cache coherence operations on the entire `getRandomNum` structure (i.e., `RespMsg.args`), is it necessary to perform cache coherence operations on all pointer variables within `args`? To be more specific: should I only perform coherence operations on the `resultPtr` (which holds the RNG output that this function is supposed to output) and not on `seedValue`?

This depends if you are using the seedValue again in the next iteration. The first cache invalidate is done for only the main struct. The subsequent pointers inside this main struct needs to invalidated/writeback based on the data being updated on the same and the usage of the same in the core.

mingzhe dai said:

When sending the SIPC message to the HSM core, aside from performing cache coherence operations on the entire `ReqMsg.args` (i.e., `getRandomNum`), do I also need to perform cache coherence operations on the pointer variables that are input to the HSM core, such as `resultPtr` and `seedValue`? If that's the case, is there an error in the following code 

I do not see the resultptr being used in HSM, thats why this was not invalidated here.

Thanks and Regards,

Nikhil Dasan

**Question 1:**
Is it correct to summarize that, on the Cache RAM, when the master core sends data to the HSM core via SIPC, consistency operations must be performed on the necessary input pointer variables—where "necessary input" refers to the pointer variables that the HSM core needs for processing—to ensure that the data intended to be transmitted to the HSM core is consistent with what the HSM core actually receives? Similarly, after the HSM core finishes processing and sends data back to the master core via SIPC, consistency operations must be performed on the necessary output pointer variables, where "necessary output pointer variables" refer to the data that our master core will subsequently need.

**Question 2:**
Regarding `HsmClient_getRandomNum`, since the HSM core uses both the `seedValue` and `resultPtr` pointer variables, consistency operations are needed on the inputs. So, is there an issue with your answer 2?

**Question 3:**
For the `HsmClient_getRandomNum` function, in our current practice I only need the output `resultPtr`, which is where the RNG is stored. The `seedValue` will be refilled on the next request, so theoretically, is there no need to perform consistency operations on `seedValue`? Of course, I understand that performing consistency operations on pointer variables would not matter either way, right?

**Question 4:**
Regarding many functions in `hsmclient.c`, such as `HsmClient_getUID`, `HsmClient_readOTPRow`, etc., although consistency operations are performed on pointer variables before they are sent to the HSM core, no consistency operations are performed on the pointer variables after receiving data from the HSM core.Is there any consideration for this? Because I see that these pointer variables are also used in the HSM core processing function

Hope to recover as soon as possible, thank you！！

This issue is quite urgent as it affects the release of the program. Could you please take a look urgently? Thank you very much

mingzhe dai said:

**Question 1:**
Is it correct to summarize that, on the Cache RAM, when the master core sends data to the HSM core via SIPC, consistency operations must be performed on the necessary input pointer variables—where "necessary input" refers to the pointer variables that the HSM core needs for processing—to ensure that the data intended to be transmitted to the HSM core is consistent with what the HSM core actually receives? Similarly, after the HSM core finishes processing and sends data back to the master core via SIPC, consistency operations must be performed on the necessary output pointer variables, where "necessary output pointer variables" refer to the data that our master core will subsequently need.

Yes, correct

mingzhe dai said:

**Question 2:**
Regarding `HsmClient_getRandomNum`, since the HSM core uses both the `seedValue` and `resultPtr` pointer variables, consistency operations are needed on the inputs. So, is there an issue with your answer 2?

as you can see in the code, HSM is not reading anything from resultptr. It is only writing into the same. So it need not be cache maintained from R5 before sending.

mingzhe dai said:

For the `HsmClient_getRandomNum` function, in our current practice I only need the output `resultPtr`, which is where the RNG is stored. The `seedValue` will be refilled on the next request, so theoretically, is there no need to perform consistency operations on `seedValue`? Of course, I understand that performing consistency operations on pointer variables would not matter either way, right?

Correct, if R5 is not using it further, then no need for cache maintenance on this

mingzhe dai said:

Regarding many functions in `hsmclient.c`, such as `HsmClient_getUID`, `HsmClient_readOTPRow`, etc., although consistency operations are performed on pointer variables before they are sent to the HSM core, no consistency operations are performed on the pointer variables after receiving data from the HSM core.Is there any consideration for this? Because I see that these pointer variables are also used in the HSM core processing function

Yes, you are correct. There should be Cache maintenance done in this case as well as HSM is filling the data. We are not seeing the issue because we are doing a WB and Inv before, so the content update from HSM is mostly picked by R5 from RAM, rather than cache.
But it is a good practice to invalidate cache before on R5 to access updated content from HSM.

Thanks and Regards, 

Expert, let me summarize my understanding:
For the issues mentioned above, regardless of whether the pointer variable will be used in the next loop iteration or whether the variable is input‑only and does not require an output, performing cache coherence operations on all data (such as structures and pointer variables) exchanged between the R5 core and the HSM core—specifically, issuing a wbinv before the R5 core sends data to the HSM core, and an inv after the R5 core receives data from the HSM core—will make the program more robust and stable, with no adverse side effects. Is my understanding correct?