SBSFU Code that MUST be revisited?

[jrgert]

I am trying to modify the way secure boot handles the reset cause. In the code, I find CHECK STATUS ON RESET function and a comment that reads; "Hence this piece of code must systematically be revisited and tuned for the targeted system."

List of all code sections that "must systematically be revisited" anyone?

John G

[Imen.D]

Hello @jrgert​ ,

If I understand is that you want to know every parts of the SBSFU code where a ‘revisit’ of the code is needed.

I don’t have a clear answer to this question, and I'm not sure that such kind of list is available.

In fact, SBSFU is working in the state of delivery.

Tuning may be needed to adapt behavior to targeted product, and you can refer to SBSFU documentation (UM & AN) for possible tuning.

Imen

[Bubbles]

Hello John,

any user should definitely check at least memory mapping and settings in app_sfu.h

Everything else is usually platform-dependent and depending on the level of customization necessary for the targeted application. For example STM32L4 user may need to deal with firewall, while the STM32G4 series has other means.

I believe the User Manual and the Integration Guide Application Note are listing all the parts that need to be reviewed when adapting the SBSFU.

Then again, perhaps adding some sort of "checklist" summary to one these documents is not a bad idea.

I'll bring that up.

Rgds,

Jarda

[jrgert]

For clarity, it appears that a consistent method of indicating "Customer code here" doesn't exist. I was simply asking the community if anyone had a list to share. For example; ///@todo, //TODO, "Add code here" all seem like commonly used references that can be searched for, or a list autogenerated from.

Agreed, tuning a template is the end user's responsibility. (kinda why I was digging into the reset cause handler ;-P) FWIW, neither document currently has the word "revisit" in it.

Keep up the good work SBSFU team. I appreciate it.

[jrgert]

My original question was more of a community question than an ST question.

Guessing at how company standard templates like these are built, I'm OK with it. (massive architectural project, many contributors, international)

[Imen.D]

Thanks @jrgert​ for your contribution and all your feedback are welcome :)

Imen

[Ggfdg.1]

I am working on a similar task and facing some issues regarding it please guide me the right path from where I can do it easily.

[alister]

>List of all code sections that "must systematically be revisited" anyone?

It is that function you'd revisit.

The intention is, if a reason would not normally occur and may be an effect of an attack, e.g. some type of side-channel attack, you may code a defense to reduce possibility of it learning anything.

Possible defenses include rebooting, waiting some random time and rebooting, qualifying your defense by consecutive-errors per reason, mass-erasing, etc.

The X-CUBE_SBSFU is example code. Everything needs checking, possibly fixing, possibly replacing.