Decide whether to enable HW_STACK_PROTECTION by default

[ioannisg]

Introduction

Decide whether to enable HW STACK PROTECTION by default in builds.

Problem description

It has been identified that the root-cause in many of issues reported by users, while trying out Zephyr applications, is thread stack corruption. Therefore, turning HW_STACK_PROTECTION on by default in Board definition is a valuable feature during application development.

Proposed change

Turn HW_STACK_PROTECTION ON by default in Zephyr builds, where the platform supports it.
This is currently done in Nordic official DK Boards, but it could be extended to a wider list of Boards (if not allover the place).

Concerns and Unresolved Questions

The feature comes with some increase in code footprint, RAM, and runtime performance (e.g. in ARMv7-M it increases the time required for context-switch). This should be documented.

The feature needs to be explicitly disable in tests that require HW stack protection to be OFF (e.g. for benchmark or profiling)

If we agree to do this everywhere, we should add this in the Board porting guidelines.

[ioannisg]

FYI @andrewboie @carlescufi @ruuddw

[ruuddw]

I'd be ok, stack overflows are indeed a major but simple to catch source of application problems. Or, make it default enabled when DEBUG is enabled?
Another thought: we already have the 'hardenconfig' option to suggest recommended features for security which includes stack protection. Make a 'debugconfig' that enables recommended settings for debugging?

[JordanYates]

HW_STACK_PROTECTION requires ARCH_HAS_STACK_PROTECTION, which for ARM CPU's at least requires ARM_MPU.
Are there any downsides to requiring the MPU to be enabled?

[ioannisg]

HW_STACK_PROTECTION requires ARCH_HAS_STACK_PROTECTION, which for ARM CPU's at least requires ARM_MPU.
Are there any downsides to requiring the MPU to be enabled?

Nope, other than the fact that it increases code and ram footprint. ARM_MPU is enabled by default in the majority of Cortex-M boards that support it.

[carlescufi]

My vote goes for enabling this by default for all SoCs that support it.

[ioannisg]

I think this has already been an adopted policy, at least for Cortex-M platforms in the tree, including, among others, Atmel, Nordic, NXP and STm32. It has been documented as well in the board porting guidelines:

https://docs.zephyrproject.org/latest/guides/porting/board_porting.html?highlight=board%20porting

so, I am going to close this ticket.