clean up Kconfig ontology for memory management capabilities

[andrewboie]

Is your enhancement proposal related to a problem? Please describe.
We've accumulated a number of Kconfigs related to memory protection and memory management over the years, often added ad hoc to solve a particular problem, and it would be good to clean this up into a coherent, documented ontology.

This is a first-pass list of configs which affects memory management, memory protection, and thread stacks.

So far we have (at least):

generic arch code:

ARCH_HAS_STACK_PROTECTION
ARCH_HAS_USERSPACE
CPU_HAS_MPU
ARCH_HAS_EXECUTABLE_PAGE_BIT
MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT
MPU_REQUIRES_NON_OVERLAPPING_REGIONS
MEMORY_PROTECTION
MPU_GAP_FILLING
HW_STACK_PROTECTION
USERSPACE
GEN_PRIV_STACKS
DYNAMIC_OBJECTS
MAX_THREAD_BYTES
NO_UNUSED_STACK_INSPECTION
STACK_GROWS_UP
KOBJECT_TEXT_AREA
PRIVILEGED_STACK_SIZE

Under arch/x86:

X86_MMU
X86_MMU_PAGE_POOL_PAGES
X86_USERSPACE

plus an assortment of configs to mitigate or state vulnerability to various Spectre vulnerabilities

Under arch/arm:

ARM_STACK_PROTECTION
ARM_MPU
ARM_MPU_REGION_MIN_ALIGN_AND_SIZE
MPU_STACK_GUARD
MPU_STACK_GUARD_MIN_SIZE_FLOAT
MPU_ALLOW_FLASH_WRITE
BUILTIN_STACK_GUARD
ARM_MMU
MAX_XLAT_TABLES
ARM64_VA_BITS_32
ARM64_VA_BITS_36
ARM64_VA_BITS_42
ARM64_VA_BITS_48
ARM64_VA_BITS
ARM64_PA_BITS_32
ARM64_PA_BITS_36
ARM64_PA_BITS_42
ARM64_PA_BITS_48
ARM64_PA_BITS

Under soc/arm:

CPU_HAS_ARM_MPU
CPU_HAS_NXP_MPU
CPU_HAS_CUSTOM_FIXED_SOC_MPU_REGIONS
HAS_HW_NRF_MPU

Under ARC:

ARC_MPU_VER
ARC_CORE_MPU
ARC_MPU
MPU_STACK_GUARD
ARC_MPU_ENABLE

core kernel:

THREAD_STACK_INFO
THREAD_USERSPACE_LOCAL_DATA
THREAD_USERSPACE_LOCAL_DATA_ARCH_DEFER_SETUP
INIT_STACKS
EXECUTE_XOR_WRITE
BOUNDS_CHECK_BYPASS_MITIGATION
MAX_DOMAIN_PARTITIONS

debug subsystem:

STACK_SENTINEL

Describe the solution you'd like
A lot of these are probably fine.

But I'd like to consider addressing the following:

• Arch Kconfigs all need to be namespaced to clearly reflect their arch-specific nature; ARM stuff should be prefixed with ARM_, x86 with X86_, etc
• Generic capability Kconfigs all expressed with ARCH_HAS_ namespace, which indicates that the arch supports something (but doesn't necessarily have it turned on). In some cases we use CPU_HAS_ and I don't think there's much of a distinction
• There's no generic definition related to the presence of an enabled MMU
• No generic definition for the presence of CPU stack overflow features (BUILTIN_STACK_GUARD probably needs to be made generic)
• Related to the previous point, some configs currently defined for specific arches ought to be generic, like MPU_STACK_GUARD
• USERSPACE might be better renamed to USERMODE, the eventual integration of virtual memory spaces will require a different Kconfig
• MEMORY_PROTECTION could be merged with other configurations or removed
• Better organization under Kconfig, a lot of stuff is scattered around
• Some configs like ARCH_HAS_EXECUTABLE_PAGE_BIT have no documentation
• Configs like X86_MMU or ARM_MPU could be up-leveled or mirrored by generic configs indicating that the MMU or MPU has been switched on. (CPU_HAS_MPU for example just indicates that there is an MPU, not that it is enabled). The arch-specific ones may still need to exist to select necessary options
• CONFIG_X86_MMU isn't well defined: it means that not only is the MMU turned on, but runtime page tables are installed subdivided into different regions for text/rodata/data. Need to split this up; X86_64 has the MMU always enabled (due to long mode requirements) but this is not captured. In addition, some applications will need an MMU for things like demand paging but will not want to split up RAM into page-aligned regions with different permissions due to the gaps involved

In general, it would be good to have some holistic attention paid to this, it's grown like a fungus.

[andrewboie]

@ioannisg @ruuddw @vonhust FYI

[ruuddw]

Makes sense to me (e.g. not sure why we have ARC_CORE_MPU and ARC_MPU).

[andrewboie]

As noted in #26942 we need a generic CONFIG_MPU and a generic CONFIG_MPU_MIN_REGION_SIZE for arch-independent code to know how to properly align memory partitions.