[Kartikey1306]

eos_mpu_validate() returns an error count, and its two hardware-constraint checks did not contribute to it:

if (reg->size > 0 && (reg->size & (reg->size - 1)) != 0)
    printf("  WARN: ... size 0x%x not power-of-2\n", ...);
if (reg->base_addr % reg->size != 0 && reg->size > 0)
    printf("  WARN: ... base 0x%x not aligned to size 0x%x\n", ...);

Neither touches errors, so a configuration the hardware cannot program is reported clean — and eos_mpu_generate_config() writes it out.

These are not warnings

ARMv7-M encodes a region's extent as a power-of-two exponent in RASR.SIZE, and RBAR requires the base to be aligned to that extent. A region violating either cannot be expressed — what actually gets programmed covers different memory than was asked for.

For a task-isolation service, "isolated, but not over the range you specified" is precisely the failure this validation exists to catch. Both now count against the return value, along with the 32-byte floor RASR.SIZE implies, which nothing checked at all.

Second: the guard is on the wrong side of &&

reg->base_addr % reg->size != 0 && reg->size > 0

&& only guards what is to its right, so the modulo runs first and a zero-sized region divides by zero. eos_mpu_add_region() never validates size, so this is reachable from any caller:

services/rtos/src/rtos_security.c:80:32: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior

Worth knowing why it went unnoticed: on x86 a zero divisor raises SIGFPE and the process dies; AArch64's udiv quietly yields 0. The same input crashes on the CI host and returns silently on an Apple-silicon dev machine — I hit exactly that, and only UBSan settled it.

Size 0 is now rejected first, and the check continues past everything that divides by or masks with size.

Tests

tests/test_mpu_validate.c is new — this service had no tests. It covers a programmable region validating clean, then each rejection: non-power-of-two, misaligned base, zero size, below the 32-byte minimum, and an unprogrammable region inside a satisfied region budget (so one error cannot mask another).

Against the unpatched validate() it fails on the non-power-of-two case:

[FAIL] test_mpu_validate.c:54: validate_one_region(0x20000000, 0x1800) > 0
  WARN: Task 'worker' region 'r' size 0x1800 not power-of-2

— the WARN prints, and the function still returns 0.

Verification

ctest --no-tests=error	27/29
new suite	6/6

The two Not Run are test_os_adapter and test_os_services, which need services/compat — that does not build on macOS (pthread_mutex_timedlock / sem_timedwait), #96's subject, not this one.

Stacked on #102, which repairs the macOS HAL link.