Skip to content

G3P-22238: honor osThreadZone() in osThreadNew (FreeRTOS shim)#16

Draft
nickfritz33 wants to merge 1 commit into
mainfrom
nick/G3P-22238/zone-shim
Draft

G3P-22238: honor osThreadZone() in osThreadNew (FreeRTOS shim)#16
nickfritz33 wants to merge 1 commit into
mainfrom
nick/G3P-22238/zone-shim

Conversation

@nickfritz33

Copy link
Copy Markdown

Summary

  • Patches osThreadNew() in cmsis_os2.c to honor osThreadZone(N) bits in osThreadAttr_t.attr_bits. When the valid bit is set, the wrapper extracts the 6-bit zone ID, calls the application-provided ZoneGetTaskRegions(zone) to fetch a pointer to the zone's per-task MPU regions (rows 5–7 of the application's global zone table), translates each ARM_MPU_Region_t (RBAR/RLAR) into FreeRTOS's MemoryRegion_t (base/length/parameter flags), builds TaskParameters_t, and routes through xTaskCreateRestrictedStatic instead of xTaskCreateStatic.
  • Strictly opt-in: tasks without osThreadZone() in their attr_bits fall through the existing xTaskCreateStatic path unchanged. No behavior change for any existing task.
  • Mirrors the existing PATCH REQUIRED comment style used for the opt-in privilege patch — if cmsis_os2.c is regenerated or the middleware package is upgraded, the block (and the matching code path in osThreadNew) must be re-applied.
  • Designed to be FuSa-RTS migration-clean: application code, zone table, and osZoneSetup_Callback() are unchanged across runtimes; only this shim disappears at migration when FuSa's runtime implements zone enforcement natively.

The companion change in the Gen3-Panel main repo lives on nick/G3P-22238/create-unprivileged-task — it introduces zones.{h,c} (providing ZoneGetTaskRegions) and converts CounterTask to use osThreadZone(ZONE_UNPRIVILEGED_STUB). That branch is not slated for merge in its current form.

JIRA: G3P-22238

Test plan

Verified on Branch-Production hardware (STM32H573):

  • Build is clean (configENABLE_MPU=1, configSUPPORT_STATIC_ALLOCATION=1).
  • Boot is clean with no zone-using tasks (zone branch dormant; every task still hits the xTaskCreateStatic path).
  • Boot is clean with CounterTask opted into osThreadZone(ZONE_UNPRIVILEGED_STUB) | osThreadUnprivileged.
  • Breakpoint at CounterTaskFunc halts with CONTROL = 0x3 (nPRIV=1 unprivileged, SPSEL=1 PSP).
  • MPU regions 0–3 set by FreeRTOS prvSetupMPU from linker symbols (privileged code, app code, syscalls, kernel SRAM).
  • MPU region 4 set by port at the task's stack base; any-RW, no-exec.
  • MPU regions 5–7 are zero, matching the empty zone-table rows for the stub zone.

Reviewer notes:

  • Verify the PATCH REQUIRED comment style and placement match the convention used for the existing opt-in privilege patch (lines ~590).
  • Confirm the RBAR/RLAR → MemoryRegion_t translation (AP, XN, ATTR_INDEX) round-trips correctly through vPortStoreTaskMPUSettings in port.c.
  • Confirm the cast (const uint32_t (*)[2])ZoneGetTaskRegions(zone) is acceptable for avoiding a CMSIS-Core MPU header dependency in cmsis_os2.c.

🤖 Generated with Claude Code

Stock CMSIS-RTOS2 v2.1.x for FreeRTOS does not read osThreadZone() bits
from osThreadAttr_t.attr_bits, so application code written against the
FuSa-shape zone API has zero effect at task creation. Tasks created
with osThreadZone(N) silently get no MPU isolation beyond defaults.

Patch osThreadNew to, when osThreadZone_Valid is set:
  - extract the 6-bit zone ID from attr_bits
  - call ZoneGetTaskRegions(zone) -- provided by the application's
    zones.c -- to get a pointer to the zone's per-task MPU regions
    (rows 5-7 of the global zone table)
  - translate each ARM_MPU_Region_t (RBAR/RLAR) into FreeRTOS's
    MemoryRegion_t (base/length/parameter flags), decoding AP/XN bits
    and ATTR_INDEX
  - build TaskParameters_t and call xTaskCreateRestrictedStatic instead
    of xTaskCreateStatic

Tasks without osThreadZone() in attr_bits fall through to the existing
xTaskCreateStatic call unchanged -- the patch is strictly opt-in.

ZoneGetTaskRegions is declared extern; the application's zones.c
provides the definition. The shim treats the returned pointer as
uint32_t[][2] (RBAR/RLAR pairs) to avoid pulling CMSIS Core MPU
headers into cmsis_os2.c.

At FuSa-RTS migration this block is removed entirely. FuSa's runtime
implements zone enforcement natively via osZoneSetup_Callback on every
zone change; application code, zone table, and callback are unchanged.

PATCH REQUIRED comment block added matching the existing one for the
opt-in privilege patch -- if cmsis_os2.c is regenerated or the
middleware package is upgraded, this block (and the matching code
path in osThreadNew) must be re-applied.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@nickfritz33 nickfritz33 self-assigned this May 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant