Fix Bugs and Secure Firmware with the MPU | Interrupt

Blog
1

On a computer when when an application dereferences a NULL pointer or tries to access kernel memory we can catch it pretty easily thanks to the features provided by the MMU on the chip.

This is a companion discussion topic for the original entry at https://interrupt.memfault.com/blog/fix-bugs-and-secure-firmware-with-the-mpu
3

Hello, I am facing one issue, I am not able to set MPU_RBAR register VALID bit as high. Below is my code. MPU_RBAR ADDR bits are able to store correctly as expected.

mask = 64 - 1;
base_addr1 = ((uint32_t)&_estack + mask) & ~mask;
*mpu_rbar = (base_addr1 | 1 << 4 | 0);
*mpu_rasr = (0b000 << 24) | (0b000110 << 16) | (5 << 1) | 0x1;
volatile uint32_t *mpu_ctrl = (void *)0xE000ED94;
*mpu_ctrl = 0x5;

I m not able to find any issue. Any suggestions?

4

Hi @chandan_bhatia! Good observation! This is expected, the VALID bit will always read as zero. It is only used on writes to control whether or not the REGION programmed in the register is used. You can find a few more details about the behavior in this section of the article.

5

Hi @chrisc Thanks for reply. Using above code I am trying to capture MemManage_Handler before my stack is getting corrupted but I am unable to capture it. I am getting hard fault post stack corruption. Can you find any error in MPU register settings?

6

The blog seems to offer only protection against writes to the NULL pointer (by designating the Flash ROM as a read-only MPU region). But how about reads from the NULL pointer?

I understand that the read protection is tricky because the vector table starts at address 0x0. So, how about relocating the vector table? Is that a part of the solution? I’d really like to see a working setup to effectively catch reads from the NULL pointer and some small offsets from NULL.