Thread-level Memory Protection Support

[zephyrbot]

Reported by Anas Nashif:

Run trusted software in privileged mode and run all less-trusted software in unprivileged mode. Examples of trusted code are RTOSs, ISRs, handlers, and low-level drivers. Examples of less-trusted code are untested code third party software, and code that is vulnerable to malware such as protocol stacks and high-level drivers.

• qemu_cortex_m3: enable MPU #4015: qemu_cortex_m3: enable MPU
• memory protection: implicit kernel object permissions #4014: memory protection: implict kernel object permissions
• x86: scope SMAP support in Zephyr #3943: x86: scope SMAP support in Zephyr
• x86: scope SMEP support in Zephyr #3942: x86: scope SMEP support in Zephyr
• x86: implement option for PAE-formatted page tables with NX bit #3941: x86: implement option for PAE-formatted page tables with NX bit
• x86: implement memory domain interface #3852: x86: implement memory domain interface
• design mechanism for kernel object sharing policy #3840: design mechanism for kernel object sharing policy
• ARM: implement API to validate user buffer #3832: ARM: implement API to validate user buffer
• application/kernel rodata split #3810: application/kernel rodata split
• x86: QEMU: enable MMU at boot by default #3801: x86: QEMU: enable MMU at boot by default
• implement __kernel attribute #3799: implement __kernel attribute
• reconsider k_mem_pool APIs #3767: reconsider k_mem_pool APIs
• x86: API to validate user buffer #3760: x86: API to validate user buffer
• reconsider k_mbox APIs #3759: reconsider k_mbox APIs
• linker: implement MMU alignment constraints #3740: linker: implement MMU alignment constraints
• linker: implement MPU alignment constraints #3739: linker: implement MPU alignment constraints
• define / implement application-facing memory domain APIs #3716: define / implement application-facing memory domain APIs
• xtensa: scope MPU enabling #3701: xtensa: scope MPU enabling
• stack declaration macros for ARM MPU #3700: stack declaration macros for ARM MPU
• reconsider k_queue APIs #3673: reconsider k_queue APIs
• define kernel system calls #3641: define kernel system calls
• define network stack system calls #3639: define network stack system calls
• Define region data structures exposed by linker script #3636: Define region data structures exposed by linker script
• Device Driver Access Control #3635: Device Driver Access Control
• ARM: implement NULL pointer protection #3634: ARM: implement NULL pointer protection
• define set of architecture-specific memory protection APIs #3632: define set of architecture-specific memory protection APIs
• program text should be in its own memory region #3631: program text should be in its own memory region
• use API to validate user-supplied kernel buffers #3630: use API to validate user-supplied kernel buffers
• implement APIs for dropping threads to unprivileged mode #3628: implement APIs for dropping threads to unprivileged mode
• x86: implement system calls #3627: x86: implement system calls
• x86: Implement simple stack memory protection #3626: x86: Implement simple stack memory protection
• Validation mechanism for user-supplied kernel object pointers #3625: Validation mechanism for user-supplied kernel object pointers
• Memory protection: define allocators for kernel objects #3624: Memory protection: define allocators for kernel objects
• Stack declarations for memory protection #3623: Stack declarations for memory protection
• Split data, bss, noinit sections into application and kernel areas #3622: Split data, bss, noinit sections into application and kernel areas
• Design system call interface for drivers #3621: Design system call interface for drivers
• x86 MMU: implement build-time tool to create boot page table #3531: x86 MMU: implement build-time tool to create boot page table
• Work up linker-based system call prototype for MPU enabling #3383: Work up linker-based system call prototype for MPU enabling
• nios2: MPU support #2074: nios2: MPU support

(Imported from Jira ZEP-1466)

[zephyrbot]

by Marcus Shawcroft:

We should give some consideration to using mpu support to fault null pointer accesses.

There is a post on devel The recent post on devel https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-March/007426.html that touches on some of the developer experience issues that arise from the the C standards treatment of null pointers and various related compiler optimizations.

[zephyrbot]

by Andrew Boie:

The scope of this JIRA is way too broad and needs to be decomposed into deliverables.
See GH-3531 for one such deliverable.

[zephyrbot]

by Mark Linkmeyer:

Andrew to break up in to stories.

[zephyrbot]

by Andrew Boie:

Survey from Linaro of MPU capabilities across a variety of arches/CPUs

https://wiki.linaro.org/Memory%20Protection%20Device%20Survey

[zephyrbot]

by Andrew Boie:

Notes from Andy on high-level requirements:

So going through the JIRA and through our own documentation, you have all of the major tasks identified. That said, I do agree that a specific list of deliverables that are assigned to separate stories/arcs should be done.

Major tasks:

• privileged/unprivileged section isolation
  • Static tables derived from sections. These would give code and data regions for kernel and apps
  • Define structures to describe regions and implement that
  • Define dynamic region definition for transient regions
    • How does this hook in to k_thread
• Region management
  • APIs
• Stack guard
  • Hardware support. MMU vs MPU
  • API convergence?
• Null ptr protection
• Peripheral device isolation
  • Recognizing device access and proper configuration of peripheral ranges
  • system calls to access device?
• Privileged access escalation / system calls

These are general placeholders and cover a number of your specific cases outlined in the JIRA. When we were divvying up the work between Vincenzo and myself, my thought was to get the isolation of privileged and unprivileged working. Once we got the separation we could then explore the system calls and escalation mechanisms. I see the region management to be the primary thing to do first. Then the isolation, which brings in the section definitions and API work.

We can talk more on this in the morning, but I wanted to get this out tonight to at least condense some of the stuff we've been talking about internally.

Regards,

Andy

[zephyrbot]

by Andrew Boie:

Marcus Shawcroft NULL pointer protection will be tracked in GH-3634, thanks!

[carlescufi]

• PR Add ARM userspace infrastructure #4974 for ARM
• ARC PR missing