is ACTIVE SLOT Header protected ??

[SPati.7]

From SBSFU examples, with default SECUSER memory setting except reading from OB registers, it is only protecting SBSFU area alone.

Are we need to protect SBSFU + ACT_SLOT HEADER (1024 Bytes for H7) area as well right ??

So what is your recommendation on protection of HEADER ??

[Fred]

It protects also the active slot header:

[Fred]

When this is called:

SFU_MPU_SysCall((uint32_t)SB_SYSCALL_LAUNCH_APP, SlotStartAdd[SlotNumber] + SFU_IMG_IMAGE_OFFSET);

Can you still access the active slot header ?

[Fred]

Reading the code, I have a doubt too...let me check further.

[SPati.7]

@Fred​  To launch the application, we are giving right address by passing SlotStartAdd[SlotNumber] + SFU_IMG_IMAGE_OFFSET. But question is on configuring the secure user memory protection.

From examples, i didn't see that we are applying secure user memory protection to ACT_SLOT Header part.

So, as you mentioned, we should protect ACT SLOT HEADER as well, while configuring through OB, right ??

[Fred]

Yes, the active slot header is a sensitive piece of information, it must be protected otherwise we cannot trust the authenticity and integrity checks.

So, from a design perspective, it is clear that it must be protected.

Now, when looking at the latest implementation, I think the size we protect is too short.

I'm trying to clarify it with my colleagues.

[SPati.7]

Also, Can you please share any details on X-CUBE-SBSFU maturity details & Reliability of SBSFU as well??

[Fred]

Well, the license terms define it it I guess.

This is software provided "as example".

We try our best to provide "best-in-class" and reliable software, but it remains examples provided "as is".

So, as you do, you need to assess it and determine to which extent you can (re)use it to implement your own solution.

This being said, the X-CUBE-SBSFU package has passed security audits.

All information can be found here:

STM32Trust - STMicroelectronics

And specifically for X-CUBE-SBSFU:

https://www.st.com/resource/en/certification_document/psa-certificate_stm32l4.pdf

And:

https://www.st.com/resource/en/technical_note/tn1387-xcubesbsfu-security-evaluation-method-description-stmicroelectronics.pdf

We also have internal tests we run before delivering a package.

But, no process is perfect, so bugs might still find their way...

Here I want to cross-check with my colleagues if I misunderstood something for the H7 about the active slot header protection.

The package is still evolving and I am not working on it any more so it may be a valid update compared to what I knew.

I'll keep you posted.

[Fred · Accepted solution]

Ok, there is indeed a bug.

A change made for H7 devices with non-contiguous headers has been propagated erroneously to all H7 devices.

Will be better with:

#define SFU_SEC_MEM_AREA_ADDR_END ((uint32_t) (SlotHeaderAdd[SLOT_ACTIVE_1] + SFU_IMG_IMAGE_OFFSET - 1U))

in:

Firmware/Projects/NUCLEO-H753ZI/Applications/2_Images/2_Images_SBSFU/SBSFU/Target/sfu_low_level_security.h

Sorry for any inconvenience.

[SPati.7]

@Fred​  Thanks for your prompt replies.

I want to give appreciation for your help, we are getting, May i know the channel to do the same.