Hello Roman,

 

This topic is very useful, there are TF-M specific extensions supported in the code base already, such as ‘conditional’. There was an idea to let the platform overrides the variable for stack size to provide platform-specific stack sizes, which should be similar to what you are introducing:

 

    platform.yaml:

        “CRYPTO_STACK_SIZE”: 0x800,    # On current platform, assign 0x800 as the crypto stack size.

 

It is allowed to expand these extensions if we could provide compatibility for those manifests that are strictly following the FF-M specification.

 

There was an idea to unite the platform-specific configurations by YAML – but as it conflicts with the existing configuration system hence it is not been decided.

 

As it may affect the platform integration, hence other platform integrators please provide your input.

 

Thanks.

 

/Ken

 

From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, November 18, 2022 11:49 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Platform/Application specific service extension

 

Hi,

 

Partition is described through configuration in YAML files (manifests). This configuration includes following properties (see Adding Secure Partition - Add manifest):

 

Each platform should provide implementation of HAL which is specific to standard partitions like Crypto, ITS, etc. It’s mandatory to provide proper isolation of memory/peripheral that are used by platform specific code that provides HAL implementation or add a custom dependency for standard partition.

 

Currently platform can use following approaches to resolve the problem of extending YAML of standard TF-M partition:

These both solution are not flexible enough. It requires to modify platform independent code or maintain own copy of partition YAML file with needed changes.

 

I think it make sense to integrate partition YAML extension tool in TF-M. Platform/application should be able to provide manifest-extension file(s). Such manifest-extension file may provide additional properties which should be joined with properties provided by standard partition manifest files.

 

For example to solve problem for https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 ARM RSS platform may provide following manifest-extension file with structure like this:

{

  "extensions": [

    {

      "name": "TFM_SP_INITIAL_ATTESTATION",

      "dependencies": [

        "TFM_MEASURED_BOOT"

      ]

    }

  ]

}

 

Tool which parses manifests should add a new dependency on "TFM_MEASURED_BOOT" to list of dependencies for "TFM_SP_INITIAL_ATTESTATION" partition.

 

Please, share your opinion on this topic.

 

Best regards,

Roman.