2205293_en-US

[#1]

HSE reserved memory size increase from BSP32 -> BSP43?

Customer is Ford, s32g2, HSE FW 1.0.16.

They are wondering if there is a way to determine how much HSE reserved memory their system will need, as there is a rather large discrepancy between the amount used BSP32 vs. BSP43:

BSP43:

    hse_reserved: shm@84000000 {
      compatible = "nxp,s32cc-hse-rmem";
      reg = <0x0 0x84000000 0x0 0x1000000>;  /* 16 MB */
      no-map;
    };

BSP32:

    hse_reserved: shm@0x84000000 {
      reg = <0x0 0x84000000 0x0 0x80000>;  /* 512k */
      no-map;
    };

@bogdan-folea 

-Randy Krakora

Board: S32G274Linux BSPPriority: HIGHSW Variant: STANDARDType: INQUIRYRe: HSE reserved memory size increase from BSP32 -> BSP43?

Hello @RandyKrakora ,

I moved this ticket to the AP-Software-Support community because it is a topic related to Linux BSP.

BR,
Marian Vilau

Re: HSE reserved memory size increase from BSP32 -> BSP43?

Hello @RandyKrakora ,

The amount of memory needed depends on the how the application is going to use libpkcs, this should be configured by the customer in their own device tree to reflect the actual use case. Without having these details from the customer, it's not possible to come up with a specific number for size.

This being said, I can give you some guidelines: for the memory allocator internals, session contexts and PKCS#11 object meta-data, something less than 100k should be enough, since we don't store the actual key material in DDR - not even the modulus and exponent of public keys (which can get rather large), instead the implementation of C_GetAttributeValue() gets them from HSE itself (any other key material is non-exportable). For cryptographic operations, the payload buffers must be also taken into account, since all of it must fit inside the non-cacheable memory that is accessible to HSE.

For example, if you want to use libpkcs for hashing or to compute/verify a digital signature over a large amout of data (such as a entire kernel or hypervisor image during OTA), you are probably going to need at least 10M of buffer to fit all that (or even more if the HV comes with a rootfs attached). If needed, the amount of space required can be reduced by splitting the payload into multiple chunks and using multi-part operations.

So, in the vast majority of cases, 16M is overkill and a more appropriate number can be set for RMEM size, depending on the actual use case and how many applications the customer has running on top of libpkcs and/or libhse. We've set a high limit to accommodate a wide range of use cases by default, but this doesn't mean it has to go into production like that - we expect the customer to adjust the base address and the offset during development. The only hard restriction is that the RMEM in its entirety should reside in the 0x80000000--0xDFFFFFFF address range.

Best Regrards,
Marian Vilau

Re: HSE reserved memory size increase from BSP32 -> BSP43?

Hello @RandyKrakora  ,

If your query/issue has been resolved and there are no follow-up questions, please mark the post as a solution so that the case can be closed.

Please note: If there are no follow-up questions on the case and we do not receive a response, we will be closing the case in 7 business days from the most recent update. Exceptions apply during holidays.

Thanks,

Marian Vilau