LPC55S69 : AHB misc control register

[EugeneHiihtaja]

Hello !

It is not so clear how 2nd and 3rd parameters have effect for security checking.

I mean "Enable secure privilege check  .."and  Enable non-secure privilege check ...".

What AHB check in this case. If privileged code is not access nonprivileged or vise versa.?

Could you provide more info about those checks ?

Regards,Eugene

[Sabina_Bruce]

Hello Eugene,

Hope you are doing well.

Here is a high level description of what is seen in the tables of the config tools.

The orange blocks are the extension of the security features apart from the blue, which is ARM's security features.

When the secure AHB check is enabled it allows programming security attributes
for all PPCs(Peripheral Protection Checker), MPCs(Memory Protection Checker), or MSWs(Master Security Wrapper). Secure AHB controller provides a second protection layer for safe, trusted execution at system-level. With secure AHB each peripheral is capable of configuring individual access rules. These can be configured in the same config tool  on the previous tabs before miscellaneous. 

Consequently when you use secure check and secure privileged check you are doing a combination of ARM's features and the ones implemented mentioned above.

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

----------------------------------------------------------------------------------------------------------------------- 

[EugeneHiihtaja]

Hi Sabina !

Where is IDAU configuration ? "User memory regions" ?

In any case  "Memory attribution map" and "Access overview " show final access right for entire memory and peripherals.

But MPU S/NS is not part of this picture and overall is not so clear how MPU configuration effect situation when those AHB privilege check bits are in use.

Basically if bits are not set, AHB matrix controls secure/nonsecure division and after that MPU resize privilege and nonprivilege accesses to code and data.

But if AHB checks enforced , what kind of effect we can have if MPU configure privileged area on top of user ones and vice versa ?

Does MPU have priority on top of other units ?

I think it have sense to add extra MPU_s configuration table in IDE ( in any case MPU_s configuration is almost hardcoded).

It can help to exterminate final access right to memory/peripherals.

As usually MPU_NS configuration if floating due RTOS task switching, but MPU_S - hardcoded.

But in any case, User can input some configuration values to MPU and see final access right.

But options enable/disable MPU can opt in/out it to Memory attribution map configuration. Also it can stay in mex file if need.

So MPU configuration can be use for estimation but not active in code where real MPU config based on linker files are in use.

But really MPU priority when AHB privilege/nonprivilege checks enforced is not so clear for me. All trials to enforce those bits together with MPU generate faults even code looks partitioned between privileged and nonprivileged as it should.

Could you clarify this issue a bit ?

Regards,

Eugene

[EugeneHiihtaja]

Hi sabinabruce‌ !

 I try to say that is really not so clear what logic should be used if MPU is active on top of all other AHB check mechanisms.

Regards,

Eugene

[pavelgrasblum]

Hi Eugene,

if you enable secure/non-secure privilege check, the AHB secure controller performs additional check for privilege/non-privilege access. In this case privilege/non-privilege access (defined by either secure on non-secure MPU) has to be aligned with AHB secure controller settings. The privilege/non-privilege check can be separately enabled for secure and non-secure bus transactions. The security of transaction is defined by SAU+IDAU.

The AHB secure controller distinguishes between instruction fetch access and data access. In case of instruction fetch, the strict checking is applied. It means that code has to be executed from the same security level. It means that if CPU is in secure-privilege mode, the code memory has to be configured as secure-privilege in AHB secure controller as well. (This is probably reason for your HardFault). In case of data accesses, the privilege code has access to both privilege and non-privilege (user) memory, the non-privilege code has access to non-privilege (user) memory only.

Please note that if CPU is in secure mode, the secure MPU takes effect. In non-secure/normal mode the non-secure MPU takes effect.

Please also note, that if privilege check is enabled, you cannot simply switch to user mode by writing into CONTROL register in thread mode. This is because of strict check of AHB secure controller for instruction fetch. Once you write into CONTROL register in thread mode, the CPU switches immediately into user mode and this causes HardFault. This is because your code memory is configured as privilege. You need to switch to user mode via interrupt (for example SVC). The interrupt is executed always in privilege mode. Now you can set user mode in CONTROL register (because change to user mode will happen during interrupt exit) and modify return address to the new location, which is configured to user access in AHB secure controller. At the end of this interrupt, the CPU change from privilege to user mode and jump to the new location. So code execution continues in  user mode from memory, which configured to the same level in AHB secure controller. The secure/non-secure value is selected based actual secure mode of CPU. You cannot switch from secure-privilege to non-secure-user.

Best regards

Pavel

[EugeneHiihtaja]

Hi pavelgrasblum‌ !

Thank you for answer in details !

About MPU.

You mean IDAU/SAU/MPC can be set area as privileged or nonprivileged but MPU is "overwrite" their settings

and area follow MPU one. The same is applicable for PPC area. Is this so ? Or this is valid only when extra privileges checks are disabled ?

Also if MPU sections are not cover whole memory e,g. portMPU_PRIV_BACKGROUND_ENABLE is not set.

What attributes are set for remain areas ? Completely invisible or areas follow IDAU/SAU/MPC/PPC ?

Basically due limited amount of MPU sections, PPC peripherals should be accessed via SVC calls in privileged mode, because default settings of MPU ( FreeRTOS for example), set all this area as privileged.

I have face one more phenomena in case if both MPU_S and NS are active. No glue if this the feature or side effect.

On secure side , I have check for buffer what given by API from nonsecure side :

int *p = cmse_check_address_range(data, size, CMSE_NONSECURE | CMSE_MPU_UNPRIV | CMSE_MPU_READWRITE);

Looks like area what covered by data+size should be provisioned in Secure MPU by using nonsecure address range,

secure address alias is not enough.

Buffer allocated on nonsecure side at address 0x20000000 and Secure MPU cover this area with start address 0x30000000 and cmse check cause memalign secure fault !

It means that Secure MPU should have 2 sections for those 2 SRAM areas if I would like to copy data from secure side to nonsecure. Even physically memory is the same. Is this OK ?

How I should handle callback when secure side call some function on nonsecure side ? If extra privileges check is enabled ? Callback called from ISR and looks like both code should be in privileged mode.

Looks like I should rearrange some code/data a lot if i would like to have both privileged/nonprivileged bit enabled.

On nonsecure side I have FreeRTOS and it cause some problems as well.

But I think to have both bits in misc enabled and it give extra security.

I should design SVC call what can be called from nonprivileged code and access privilege peripherals and return in correct way back.

Regards,

Eugene

[nxa16617]

Hi Eugene,

IDAU regions are not configurable, however, you can disable the IDAU using the "Disable IDAU" option inside of the Miscellaneous tab.

It is possible to see the IDAU configuration in the Memory Attribution Map view when you uncheck the "Merged SAU+IDAU" filter.

Regarding the MPU support, it is planned for the next version also with ability to turn S_MPU and NS_MPU on/off individually

Regarding the MPU + AHB privilege checks, I am trying to get this information for you.

Best Regards,

Juraj

[Sabina_Bruce]

Hello Eugene,

Hope you are doing well.

I am working on getting you this information. I will update you as soon as I can.

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct A

nswer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------