{"id":842,"date":"2024-11-14T14:59:05","date_gmt":"2024-11-14T22:59:05","guid":{"rendered":"https:\/\/omniteck.com\/?p=842"},"modified":"2025-10-26T02:24:47","modified_gmt":"2025-10-26T09:24:47","slug":"secure-partition-manager-spm","status":"publish","type":"post","link":"https:\/\/xn--y9aq2bc.com\/?p=842","title":{"rendered":"Secure Partition Manager (SPM)"},"content":{"rendered":"
Category: <\/span>LLM Chats<\/a>\u2192<\/span>Technical Solutions<\/a><\/div>\n\n\n

# Explain the SPM in TF-A<\/h1>\n\n\n\n

This document outlines the architecture and implementation details of the Secure Partition Manager (SPM) within the context of Trusted Firmware-A (TF-A) and Secure Partitions (SPs) in Arm-based systems. Here\u2019s a summary of the key points.<\/p>\n\n\n\n

Overview<\/p>\n\n\n\n

Secure Partition Manager (SPM) operates at Exception Level 3 (EL3) and manages Secure Partitions at Secure Exception Level 0 (S-EL0).<\/p>\n\n\n\n

Secure Partitions provide isolated execution environments for trusted applications, enabling secure services like DRM, secure payments, and authentication.<\/p>\n\n\n\n

Architecture<\/p>\n\n\n\n

The SPM is responsible for resource allocation, architectural setup, and service management for Secure Partitions.
A Secure Partition is a software sandbox that relies on the SPM for access to system resources and is designed to run services to completion without preemption.<\/p>\n\n\n\n

Building and Configuration<\/p>\n\n\n\n

The SPM is currently supported on the Arm Fixed Virtual Platform (FVP).
To enable SPM support, specific build flags must be set, and the Secure Partition image must be included in the Firmware Image Package (FIP).<\/p>\n\n\n\n

Resource Management<\/p>\n\n\n\n

The SPM provides a porting interface for platforms to specify resources required by Secure Partitions.
Memory management for Secure Partitions is handled through defined memory map regions and boot information.
Service Access<\/p>\n\n\n\n

Services in Secure Partitions are accessed via the SMC (Secure Monitor Call) calling convention, specifically using the MM_COMMUNICATE interface.<\/p>\n\n\n\n

Data exchange between the Non-secure world and Secure Partitions occurs through a shared memory region, with data structures defined in the Management Mode Interface Specification.<\/p>\n\n\n\n

Runtime Model<\/p>\n\n\n\n

The SPM defines interfaces for Secure Partitions to initialize and export services.
Communication between the SPM and Secure Partitions is facilitated through Supervisor Call (SVC) instructions, which allow Secure Partitions to request privileged operations.<\/p>\n\n\n\n

Event Management<\/p>\n\n\n\n

The Secure Partition includes an Event Management interface for service registration and completion indication, allowing the SPM to delegate service requests effectively.<\/p>\n\n\n\n

Conclusion<\/p>\n\n\n\n

The Secure Partition Manager and Secure Partitions provide a structured approach to implementing secure services in Arm-based systems, ensuring isolation and management of security functions while facilitating communication between secure and non-secure environments. Future revisions of the implementation are expected to enhance flexibility and feature sets.<\/p>\n\n\n\n

# Im trying to implementing this but need to define PLAT_SP_IMAGE_MMAP_REGIONS, and PLAT_SP_IMAGE_MAX_XLAT_TABLES with the rockchip mem map for the rk3399<\/h1>\n\n\n\n

To define PLAT_SP_IMAGE_MMAP_REGIONS and PLAT_SP_IMAGE_MAX_XLAT_TABLES for the Rockchip RK3399 platform, you will need to refer to the memory map specific to the RK3399 SoC.<\/p>\n\n\n\n

Below is a general guideline on how to define these constants based on typical memory regions found in the RK3399 architecture. You may need to adjust the values based on your specific requirements and the memory layout of your system.<\/p>\n\n\n\n

Step 1: Define Memory Regions<\/p>\n\n\n\n

The RK3399 typically has several memory regions that you may want to include in your memory map. Here\u2019s an example of how you might define these regions:<\/p>\n\n\n\n

Copy Code<\/p>\n\n\n\n

\/\/ Define the memory regions for the Secure Partition<\/p>\n\n\n\n

define PLAT_SP_IMAGE_MMAP_REGIONS \\\n{                               \\\n    {                           \\\n        .base = 0x80000000,   \/* Base address of the Secure Partition *\/ \\\n        .size = 0x1000000,    \/* Size of the Secure Partition memory *\/ \\\n        .attr = MT_MEMORY | MT_RW | MT_SECURE, \\\n    },                          \\\n    {                           \\\n        .base = 0x0,          \/* Base address for other secure memory regions *\/ \\\n        .size = 0x40000000,   \/* Size of the other secure memory *\/ \\\n        .attr = MT_MEMORY | MT_RW | MT_SECURE, \\\n    },                          \\\n    \/* Add more regions as needed *\/ \\\n}<\/code><\/pre>\n\n\n\n
Step 2: Define Maximum Translation Tables<\/p>\n\n\n\n
The PLAT_SP_IMAGE_MAX_XLAT_TABLES constant defines the maximum number of translation tables that can be used by the Secure Partition. This value depends on the memory layout and the number of regions you have defined. A common value for many platforms is 4 or 8, but you should adjust it based on your needs.<\/p>\n\n\n\n
Copy Code<\/p>\n\n\n\n
define PLAT_SP_IMAGE_MAX_XLAT_TABLES 4 \/\/ Adjust based on your memory map requirements<\/code><\/pre>\n\n\n\n
Step 3: Integrate with the Platform Code<\/p>\n\n\n\n
Make sure to integrate these definitions into the appropriate platform-specific files in your TF-A implementation. Typically, you would place these definitions in a header file specific to the RK3399 platform, such as plat\/rockchip\/rk3399\/rk3399_def.h.<\/p>\n\n\n\n
Example Integration
Here\u2019s how you might integrate these definitions into your platform code:<\/p>\n\n\n\n
Copy Code<\/p>\n\n\n\n
\/\/ In rk3399_def.h or a similar header file\n\nifndef RK3399_DEF_H\ndefine RK3399_DEF_H\n\ndefine PLAT_SP_IMAGE_MMAP_REGIONS \\\n{                               \\\n    {                           \\\n        .base = 0x80000000,   \\\n        .size = 0x1000000,    \\\n        .attr = MT_MEMORY | MT_RW | MT_SECURE, \\\n    },                          \\\n    {                           \\\n        .base = 0x0,          \\\n        .size = 0x40000000,   \\\n        .attr = MT_MEMORY | MT_RW | MT_SECURE, \\\n    },                          \\\n}\ndefine PLAT_SP_IMAGE_MAX_XLAT_TABLES 4\nendif \/\/ RK3399_DEF_H<\/code><\/pre>\n\n\n\n
Final Notes<\/p>\n\n\n\n
Memory Addresses: Ensure that the base addresses and sizes you define do not overlap with other critical memory regions in your system.<\/p>\n\n\n\n
Attributes: The attributes (MT_MEMORY, MT_RW, MT_SECURE) should be defined according to your security and access requirements.<\/p>\n\n\n\n
Testing: After implementing these definitions, thoroughly test the Secure Partition functionality to ensure that memory access and service requests are handled correctly.<\/p>\n\n\n\n
Make sure to consult the RK3399 technical reference manual and any relevant documentation for specific details about the memory map and configuration options.<\/p>\n\n\n\n
# Help me fill in the dots here I also need to include these structs and functions; but again adjusted for the rk3399 instead of the fvp platform:<\/h1>\n\n\n\n
static spm_mm_mp_info_t sp_mp_info[] = {\n[0] = {0x80000000, 0},\n[1] = {0x80000001, 0},\n[2] = {0x80000002, 0},\n[3] = {0x80000003, 0},\n[4] = {0x80000100, 0},\n[5] = {0x80000101, 0},\n[6] = {0x80000102, 0},\n[7] = {0x80000103, 0},\n};\nconst spm_mm_boot_info_t plat_arm_secure_partition_boot_info = {\n.h.type = PARAM_SP_IMAGE_BOOT_INFO,\n.h.version = VERSION_1,\n.h.size = sizeof(spm_mm_boot_info_t),\n.h.attr = 0,\n.sp_mem_base = ARM_SP_IMAGE_BASE,\n.sp_mem_limit = ARM_SP_IMAGE_LIMIT,\n.sp_image_base = ARM_SP_IMAGE_BASE,\n.sp_stack_base = PLAT_SP_IMAGE_STACK_BASE,\n.sp_heap_base = ARM_SP_IMAGE_HEAP_BASE,\n.sp_ns_comm_buf_base = PLAT_SP_IMAGE_NS_BUF_BASE,\n.sp_shared_buf_base = PLAT_SPM_BUF_BASE,\n.sp_image_size = ARM_SP_IMAGE_SIZE,\n.sp_pcpu_stack_size = PLAT_SP_IMAGE_STACK_PCPU_SIZE,\n.sp_heap_size = ARM_SP_IMAGE_HEAP_SIZE,\n.sp_ns_comm_buf_size = PLAT_SP_IMAGE_NS_BUF_SIZE,\n.sp_shared_buf_size = PLAT_SPM_BUF_SIZE,\n.num_sp_mem_regions = ARM_SP_IMAGE_NUM_MEM_REGIONS,\n.num_cpus = PLATFORM_CORE_COUNT,\n.mp_info = &sp_mp_info[0],\n};\n\nconst struct mmap_region *plat_get_secure_partition_mmap(void *cookie)\n{\nreturn plat_arm_secure_partition_mmap;\n}\n\nconst struct spm_mm_boot_info *plat_get_secure_partition_boot_info(\nvoid *cookie)\n{\nreturn &plat_arm_secure_partition_boot_info;\n}<\/code><\/pre>\n\n\n\n
To adapt the provided structures and functions for the RK3399 platform, you will need to define the memory regions and other parameters specific to the RK3399 architecture. Below is an example of how you might fill in the details for the spm_mm_mp_info_t array, the plat_arm_secure_partition_boot_info structure, and the associated functions.<\/p>\n\n\n\n
Step 1: Define Memory Regions<\/p>\n\n\n\n
You will need to define the memory regions that are relevant for the RK3399. Here\u2019s an example of how you might set up the spm_mm_mp_info_t array:<\/p>\n\n\n\n
Copy Code<\/p>\n\n\n\n
static spm_mm_mp_info_t sp_mp_info[] = {\n[0] = {0x80000000, 0}, \/\/ Example memory region 1\n[1] = {0x80001000, 0}, \/\/ Example memory region 2\n[2] = {0x80002000, 0}, \/\/ Example memory region 3\n[3] = {0x80003000, 0}, \/\/ Example memory region 4\n[4] = {0x80010000, 0}, \/\/ Example memory region 5\n[5] = {0x80011000, 0}, \/\/ Example memory region 6\n[6] = {0x80012000, 0}, \/\/ Example memory region 7\n[7] = {0x80013000, 0}, \/\/ Example memory region 8\n};<\/code><\/pre>\n\n\n\n
Step 2: Define Boot Info Structure<\/p>\n\n\n\n
Next, you will define the plat_arm_secure_partition_boot_info structure. You will need to replace the placeholders with actual values based on your RK3399 memory layout:<\/p>\n\n\n\n
Copy Code<\/p>\n\n\n\n
const spm_mm_boot_info_t plat_arm_secure_partition_boot_info = {\n.h.type = PARAM_SP_IMAGE_BOOT_INFO,\n.h.version = VERSION_1,\n.h.size = sizeof(spm_mm_boot_info_t),\n.h.attr = 0,\n.sp_mem_base = 0x80000000, \/\/ Base address for Secure Partition memory\n.sp_mem_limit = 0x80010000, \/\/ Limit address for Secure Partition memory\n.sp_image_base = 0x80000000, \/\/ Base address for the Secure Partition image\n.sp_stack_base = 0x8000F000, \/\/ Base address for the Secure Partition stack\n.sp_heap_base = 0x8000E000, \/\/ Base address for the Secure Partition heap\n.sp_ns_comm_buf_base = 0x8000D000, \/\/ Base address for Non-secure communication buffer\n.sp_shared_buf_base = 0x8000C000, \/\/ Base address for shared buffer\n.sp_image_size = 0x00010000, \/\/ Size of the Secure Partition image\n.sp_pcpu_stack_size = 0x00002000, \/\/ Per-CPU stack size\n.sp_heap_size = 0x00002000, \/\/ Size of the Secure Partition heap\n.sp_ns_comm_buf_size = 0x00001000, \/\/ Size of Non-secure communication buffer\n.sp_shared_buf_size = 0x00001000, \/\/ Size of shared buffer\n.num_sp_mem_regions = ARRAY_SIZE(sp_mp_info), \/\/ Number of memory regions defined\n.num_cpus = PLATFORM_CORE_COUNT, \/\/ Number of CPU cores\n.mp_info = &sp_mp_info[0], \/\/ Pointer to memory region info\n};<\/code><\/pre>\n\n\n\n
Step 3: Implement the Functions<\/p>\n\n\n\n
Finally, implement the functions to return the memory map and boot info:<\/p>\n\n\n\n
Copy Code<\/p>\n\n\n\n
const struct mmap_region *plat_get_secure_partition_mmap(void *cookie)\n{\nreturn plat_arm_secure_partition_mmap; \/\/ Ensure this variable is defined elsewhere\n}\nconst struct spm_mm_boot_info *plat_get_secure_partition_boot_info(void *cookie)\n{\nreturn &plat_arm_secure_partition_boot_info;\n}<\/code><\/pre>\n\n\n\n
Final Notes<\/p>\n\n\n\n
Memory Addresses: Ensure that the base addresses and sizes you define do not overlap with other critical memory regions in your system. Adjust the addresses based on the actual memory map of the RK3399.
Attributes: The attributes for the memory regions should be defined according to your security and access requirements.<\/p>\n\n\n\n
Testing: After implementing these definitions, thoroughly test the Secure Partition functionality to ensure that memory access and service requests are handled correctly.
Make sure to consult the RK3399 technical reference manual and any relevant documentation for specific details about the memory map and configuration options.<\/p>\n\n\n\n
I think this portion is also necessary, help me work this in as well converting from the fvp params to expected for the rk3399 platform:<\/p>\n\n\n\n
const mmap_region_t plat_arm_secure_partition_mmap[] = {\nV2M_MAP_IOFPGA_EL0, \/* for the UART \/ V2M_MAP_SECURE_SYSTEMREG_EL0, \/ for initializing flash *\/\nif PSA_FWU_SUPPORT\nV2M_MAP_FLASH0_RW_EL0, \/* for firmware update service in standalone mm *\/\nendif\nV2M_MAP_FLASH1_RW_EL0, \/* for secure variable service in standalone mm *\/\nMAP_REGION_FLAT(DEVICE0_BASE,\n        DEVICE0_SIZE,\n        MT_DEVICE | MT_RO | MT_SECURE | MT_USER),\nARM_SP_IMAGE_MMAP,\nARM_SP_IMAGE_NS_BUF_MMAP,\nARM_SP_IMAGE_RW_MMAP,\nARM_SPM_BUF_EL0_MMAP,\n{0}\n};<\/code><\/pre>\n\n\n\n
To adapt the plat_arm_secure_partition_mmap array for the RK3399 platform, you will need to replace the existing mappings with the appropriate memory regions and attributes specific to the RK3399 architecture. Below is an example of how you might define this array, including the necessary mappings for the RK3399.<\/p>\n\n\n\n
Step 1: Define Memory Regions
You will need to define the memory regions based on the RK3399’s memory map. Here\u2019s an example of how you might set up the plat_arm_secure_partition_mmap array:<\/p>\n\n\n\n
Copy Code<\/p>\n\n\n\n
\/\/ Define the memory regions for the RK3399 platform\nconst mmap_region_t plat_arm_secure_partition_mmap[] = {\nV2M_MAP_IOFPGA_EL0, \/* for the UART \/ V2M_MAP_SECURE_SYSTEMREG_EL0, \/ for initializing flash *\/\n\nif PSA_FWU_SUPPORT\n\nV2M_MAP_FLASH0_RW_EL0, \/* for firmware update service in standalone mm *\/\n\nendif\n\nV2M_MAP_FLASH1_RW_EL0, \/* for secure variable service in standalone mm *\/\n\n\/\/ Map device memory for RK3399\nMAP_REGION_FLAT(DEVICE0_BASE,\n                DEVICE0_SIZE,\n                MT_DEVICE | MT_RW | MT_SECURE | MT_USER), \/\/ Adjust permissions as needed\n\n\/\/ Add the Secure Partition image memory mapping\nMAP_REGION_FLAT(0x80000000,  \/\/ Base address for the Secure Partition\n                0x00010000,  \/\/ Size of the Secure Partition image\n                MT_MEMORY | MT_RW | MT_SECURE), \/\/ Adjust attributes as needed\n\n\/\/ Add Non-secure buffer mapping\nMAP_REGION_FLAT(0x8000D000,  \/\/ Base address for Non-secure communication buffer\n                0x00001000,  \/\/ Size of Non-secure communication buffer\n                MT_MEMORY | MT_RW | MT_NON_SECURE), \/\/ Non-secure access\n\n\/\/ Add Read-Write mapping for Secure Partition\nMAP_REGION_FLAT(0x8000E000,  \/\/ Base address for Secure Partition heap\n                0x00002000,  \/\/ Size of the Secure Partition heap\n                MT_MEMORY | MT_RW | MT_SECURE), \/\/ Secure access\n\n\/\/ Add SPM buffer mapping\nMAP_REGION_FLAT(0x8000C000,  \/\/ Base address for SPM buffer\n                0x00001000,  \/\/ Size of SPM buffer\n                MT_MEMORY | MT_RW | MT_SECURE), \/\/ Secure access\n\n{0} \/\/ End of the mapping\n\n};<\/code><\/pre>\n\n\n\n
Step 2: Ensure Correct Definitions<\/p>\n\n\n\n
Make sure that the following constants are defined appropriately in your platform-specific header files:<\/p>\n\n\n\n
DEVICE0_BASE and DEVICE0_SIZE: These should correspond to the base address and size of the device memory region you want to map.<\/p>\n\n\n\n
Adjust the base addresses and sizes according to your specific memory layout and requirements for the RK3399.
Final Notes<\/p>\n\n\n\n
Memory Addresses: Ensure that the base addresses and sizes you define do not overlap with other critical memory regions in your system.<\/p>\n\n\n\n
Attributes: The attributes for the memory regions should be defined according to your security and access requirements. For example, MT_DEVICE for device memory, MT_MEMORY for normal memory, and appropriate read\/write permissions.<\/p>\n\n\n\n
Testing: After implementing these definitions, thoroughly test the Secure Partition functionality to ensure that memory access and service requests are handled correctly.<\/p>\n\n\n\n
By following these steps, you should be able to successfully adapt the memory mapping for the RK3399 platform. Make sure to consult the RK3399 technical reference manual and any relevant documentation for specific details about the memory map and configuration options.<\/p>\n\n\n\n
REMOVED<\/p>\n\n\n\n
define PLAT_SP_IMAGE_MMAP_REGIONS \\\n{                    \\\n    {                \\\n        .base = 0x80000000,        \\\n        .size = 0x1000000,        \\\n        .attr = MT_MEMORY | MT_RW | MT_SECURE,    \\\n    },                \\\n    {                \\\n        .base = 0x0,        \\\n        .size = 0x40000000,        \\\n        .attr = MT_MEMORY | MT_RW | MT_SECURE,    \\\n    },                \\\n}<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
# Explain the SPM in TF-A This document outlines the architecture and implementation details of the Secure Partition Manager (SPM) within the context of Trusted Firmware-A (TF-A) and Secure Partitions (SPs) in Arm-based systems. Here\u2019s a summary of the key points. Overview Secure Partition Manager (SPM) operates at Exception Level 3 (EL3) and manages Secure … <\/p>\n
Continue reading “Secure Partition Manager (SPM)”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[223,224],"tags":[],"class_list":["post-842","post","type-post","status-publish","format-standard","hentry","category-llms","category-technical-solutions"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=\/wp\/v2\/posts\/842","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=842"}],"version-history":[{"count":9,"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=\/wp\/v2\/posts\/842\/revisions"}],"predecessor-version":[{"id":1110,"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=\/wp\/v2\/posts\/842\/revisions\/1110"}],"wp:attachment":[{"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=842"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=842"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xn--y9aq2bc.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=842"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}