At multiple places in the SPM subsystem code incorrect assumptions regarding the SRAM memory layout are hard-coded:
At line ~35:
#else #include <storage/flash_map.h> #define NON_SECURE_APP_ADDRESS FLASH_AREA_OFFSET(image_0_nonsecure) /* This reflects the configuration in DTS. */ #define NON_SECURE_RAM_OFFSET 0x10000 #endif /* USE_PARTITION_MANAGER */
This code is enabled when USE_PARTITION_MANAGER is false, as is the case when building a secure partition image independently (aka not as a child image). However, in such circumstances, the layout of RAM in devicetree is whatever the user specified, at may or may not correspond to the hardcoded `0x10000` value shown. To fix the defect in this code the value for NON_SECURE_RAM_OFFSET needs to be calculated from devicetree settings.
At line ~221:
/* Configuration for Secure RAM Regions (0 - 64 kB) */
config_regions(true, 0, NON_SECURE_RAM_REGION_INDEX,
secure_ram_perm);
/* Configuration for Non-Secure RAM Regions (64 kb - end) */
config_regions(true, NON_SECURE_RAM_REGION_INDEX,
NUM_RAM_SECURE_ATTRIBUTION_REGIONS,
nonsecure_ram_perm);
PRINT("\n");
Here it appears that the comments contain invalid assumptions but that the code might actually be correct (if the correct value for `NON_SECURE_RAM_REGION_INDEX` is computed from devicetree). That said, given the comments shown, it seems possible that there are other locations in the code where these invalid assumptions might be introducing other defects.
The presence of this defect is concerning because this code is explicitly intended to run within the secure region of the processor. This defects potentially exposes secure RAM to the non-secure code, creating an exploitation path.
