SBSFU | Why do we need to build SeCoreBin separately and Why is call gate needed using MPU

[aco990]

Hello folks,

i am exploring the x-cube-sbsfu project and have 2 questions:

Question 1:
why is the SeCoreBin built separately and then later integrated to SBSFU? What is the motivation behind that?
I was thinking about putting SeCoreBin and SBSFU in one project and building it once.

Question 2:
When using MPU protection instead of the firewall protection why do we need a single entry call gate?
if i understand it right, the call gate is only used to prevent calling secure engine functions directly. But when protecting secure engine funtions using the mpu what would be the security issue if an unprivileged code part first acquires privileges and then calls secure engine functions directly without passing by the single entry call gate

@Jocelyn RICARD, @Fred 

[Fred · Accepted solution]

Hi,

Basically we started to develop the X-CUBE-SBSFU package for NUCLEO-L476RG.

Then, we generalized it.

1) Why SE_CoreBin?

On Nucleo-L476RG, the protected code runs in the Firewall enclave. 

We must respect the following constraints:

• All required code must be contained in the firewall
• no instruction fetch outside the FWALL

Besides, the Secure Engine code requires some HAL functions (ex: CRC, FLASH) and HAL is also used by SBSFU.

To avoid code duplication/renaming and to have clear boundaries we have decided to instantiate Secure Engine as a separate binary: this is SECoreBin.

This is only a design choice.

Then, this concept is enforced regardless of the security mechanism used to isolate Secure Engine from the rest of the code.

2) Why a call gate with the MPU isolation ?

The call gate concept is kept for all platforms, even when no firewall is used, because it is a common way to have single entry and exit points for the privileged code.

Besides, the SE_CoreBin project is also kept to avoid differences in the examples.

So, this is only a way to limit the changes when porting X-CUBE-SBSFU from one platform to another.

This way, the "software architecture" remains the same, though the underlying hardware IPs used to implement the securities (like the isolation) are different.

In turn, the way to perform the isolation follows the same "philosophy" with a clear split between the 2 worlds and a single place to manage the transitions (and control the parameters...):