"Monolithic" kernel

Kernel
11

TZ-M secure configuration in misc register “Enable secure privilege check for AHB matrix” and “Enable non-secure privilege check for AHB matrix” enforce privilege check and non-privileged code can’t be executed as privileged.
I think this is quite important feature what can help with better separation/isolation of code.

It seems that you are talking about the “47.3.3: Secure AHB bus and secure AHB Controller” section of LPC55S6x user manual (UM11126). This layer of protection ensures correct security domain (secure vs non-secure) and not privilege level. All access to all the AHB slaves are checked for security violations. To quote from the User Manual:

The secure AHB Controller provides access policies for all the bus slaves via checker
functions. All masters on LPC55S6x outputs security side-band signals HPRIV
(privileged) and HNONSEC (Secure access) as indication of security attributes for a given
access. Secure AHB Bus processes this signals and compares them against security
attributes set for slaves in secure AHB Controller. Access is granted if security attribute of requested access is not violating the security attribute of the slave being accessed.
Security violation interrupt is raised if violation occurs on data or instruction access.

To your second point, the code segment is organized as follows:

                  +-----------------+
                  |                 |
                  |                 |
                  |   Privileged    |
                  |                 |
                  |                 |
                  +-----------------+
                  |                 |
				  |    Sys Calls    |
				  |                 |
				  +-----------------+
                  |                 |
                  |                 |
                  |                 |
                  |                 |
                  |  Unprivileged   |
                  |                 |
                  |                 |
                  |                 |
                  |                 |
                  +-----------------+
  • Privileged - This section contains FreeRTOS kernel code.
  • Sys Calls - This section contains all the system calls i.e. the FreeRTOS APIs which are made available to an unprivileged task.
  • Unprivileged - Everything else.

You are pointing out that standard library functions (memset etc.) live in the unprivileged segment and the FreeRTOS kernel calls them which is correct. If the standard library functions are to move to the privileged segment, there are two possible options:

  1. Make them unavailable to the unprivileged tasks.
  2. Provide MPU wrappers (System calls) for all of them.

The first is undesirable and the second does not provide any benefit. As Richard pointed out, any unprivileged task wont be able to corrupt privileged RAM just by calling memset.

Did I understand your point correctly or did I miss anything?

Thanks.