Stack Guard and MPU

RE: Stack Guard and MPU

wpaul — Thu, 04 Jun 2020 17:12:07 GMT

[quote userid="14232" url="~/f/nordic-q-a/58813/stack-guard-and-mpu/253195"]I actually had a look at the peripheral/cli example first, but I couldn't see that it was including or initializing the Stack Guard / MPU at all. [/quote]

If you look in examples/peripheral/cli/main.c, you should see this:

static inline void stack_guard_init(void)
{
    APP_ERROR_CHECK(nrf_mpu_init());
    APP_ERROR_CHECK(nrf_stack_guard_init());
}

When I searched the whole SDK for references to that function, that's what popped up.

Also I realized I forgot to say that you also need to add #include "nrf_mpu.h" in addition to adding the call to nrf_mpu_init(). Sorry about that. (But you obviously must have figured that out already. :) )

[quote userid="14232" url="~/f/nordic-q-a/58813/stack-guard-and-mpu/253195"]I would have thought it to be the nrf_stack_guard module's responsibility to make sure the MPU is enabled?[/quote]

I would have thought so too. It's not entirely unreasonable though, if you consider that the MPU can be used for various other things besides just stack protection. In that case you might want to initialize the MPU separately for some other purpose (and having nrf_stack_guard_init() potentially do it again might therefore be redundant). But that's just a guess.

One of the other things I like to do with the MPU is to put a guard block at address 0x0. On many Cortex-M cores, this is the start of flash, where the vector table is, and as such doing a read on it will always succeed. It turns out that a write will also succeed, in the sense that it won't trigger a trap (though obviously it won't have any effect since the flash is normally read-only). This means if you have a bug in your program where you're using a NULL pointer by mistake, you might not notice it right away. If you define a small MPU region right at address 0 with the user/supervisor mode access rights set to NA/NA, then the CPU will throw a memory fault if you attempt any access there, which will alert you to the problem right away. (I was worried at one point that this might have some negative effects on on the CPU accessing the vector table when handling a trap, but apparently it doesn't.)

Note that the enable bit in the control register is the master enable for the whole MPU module. There's also an enable bit for each region, but the master enable also has to be set in order for any of the region definitions to have any effect.

I suppose this might be easy to overlook given that the example is not expected to force a crash, so normally you would not see a fault.

Also, I just noticed that in the "mpu info" output, the word "available" is spelled wrong.

Anyway I'm glad it works for you now.

-Bill

RE: Stack Guard and MPU

dingari — Thu, 04 Jun 2020 08:27:36 GMT

Thank you!

Finally, this all makes sense. I actually had a look at the peripheral/cli example first, but I couldn't see that it was including or initializing the Stack Guard / MPU at all. Maybe that's been updated in the latest SDK release.

But anyway, it's hardfaulting now when I try to write to the bottom of the stack.

I would have thought it to be the nrf_stack_guard module's responsibility to make sure the MPU is enabled?

RE: Stack Guard and MPU

Einar Thorsrud — Thu, 04 Jun 2020 07:15:12 GMT

Hi Bill,

Thank you for investigating and reporting this. I have reported the issue with the missing call to nrf_mpu_init() in ble_app_cli() to the SDK developers.

RE: Stack Guard and MPU

wpaul — Thu, 04 Jun 2020 00:44:31 GMT

You made me curious enough that I actually hauled out my nRF52840 DK reference board and re-flashed it to run the SDK demos.

The problem here is not that there's something wrong with you, the problem is there's something wrong with the universe:

this example is buggy.

Note that this is not the only example that uses the stack guard feature. The examples/peripheral/cli/main.c code also uses it, and that code does it right.

What's not immediately obvious is that being a CLI example, there's actually an MPU command built into the CLI. If you run it, the problem becomes clear. Here's what I get:

uart_cli:~$ mpu info
MPU State: Disabled, 8 unified regions aviable.

Region 0: Enabled
        - Location:     0x2003E000-0x2003E07F (size: 128 bytes)
        - Access:       RO/RO
        - Type:         Normal
        - Caching:      WBWA/WBWA
        - Flags:        XN

Region 1: Enabled
        - Location:     0x20004301-0x20004400 (size: 256 bytes)
        - Access:       RO/RO
        - Type:         Normal
        - Caching:      WBWA/WBWA
        - Flags:        XN

Region 2: Disabled
Region 3: Disabled
Region 4: Disabled
Region 5: Disabled
Region 6: Disabled
Region 7: Disabled
[00:02:38.000,213] <info> app: Battery level update: 97
uart_cli:~$ mpu dump
MPU_TYPE:       0x00000800
MPU_CTRL:       0x00000000

MPU_RBAR[0]:    0x2003E000
MPU_RASR[0]:    0x1729000D

MPU_RBAR[1]:    0x20004301
MPU_RASR[1]:    0x1729000F

MPU_RBAR[2]:    0x00000002
MPU_RASR[2]:    0x00000000

MPU_RBAR[3]:    0x00000003
MPU_RASR[3]:    0x00000000

MPU_RBAR[4]:    0x00000004
MPU_RASR[4]:    0x00000000

MPU_RBAR[5]:    0x00000005
MPU_RASR[5]:    0x00000000

MPU_RBAR[6]:    0x00000006
MPU_RASR[6]:    0x00000000

MPU_RBAR[7]:    0x00000007
MPU_RASR[7]:    0x00000000
uart_cli:~$

The most important part is where it says: MPU State: Disabled, 8 unified regions aviable.

Yes, Disabled.

If you download the book that I linked in my first reply, in the MPU section it documents the operation of the MPU control register. You must set bit 0 in that register to actually turn the MPU on. But here we can see that hasn't been done:

MPU_CTRL: 0x00000000

You can also inspect the MPU registers from the debugger directly. They start at address 0xe000ed90. You can refer to table 4-38 in the manual above for the complete map.

The reason this is happening is that it's not enough to call nrf_mpu_stack_guard_init(). You *also* have to call nrf_mpu_init(). This example _DOESN'T_ do that, which is incredibly dumb.

Go to main.c in the example and do this:

    APP_ERROR_CHECK(nrf_mpu_init());  /* Add me! */
    APP_ERROR_CHECK(nrf_stack_guard_init());

Now re-run your test. When I do it, I get the following endless hard fault cycle:

[00:00:00.000,000] <info> stack_guard: Stack Guard (128 bytes): 0x2003E000-0x2003E07F (total stack size: 8192 bytes, usable stack area: 8064 bytes)
[00:00:00.000,000] <error> hardfault: HARD FAULT at 0x0003460E
[00:00:00.000,000] <error> hardfault:   R0:  0x00000000  R1:  0x0F81B159  R2:  0xBA5EBA11  R3:  0x2003E000
[00:00:00.000,000] <error> hardfault:   R12: 0x2000360C  LR:  0x00027EC9  PSR: 0x61000000
[00:00:00.000,000] <error> hardfault: Cause: The processor attempted a load or store at a location that does not permit the operation.
[00:00:00.000,000] <error> hardfault: MemManage Fault Address: 0x2003E000
[00:00:00.000,000] <info> stack_guard: Stack Guard (128 bytes): 0x2003E000-0x2003E07F (total stack size: 8192 bytes, usable stack area: 8064 bytes)
[00:00:00.000,000] <error> hardfault: HARD FAULT at 0x0003460E
[00:00:00.000,000] <error> hardfault:   R0:  0x00000000  R1:  0x0F81B159  R2:  0xBA5EBA11  R3:  0x2003E000
[00:00:00.000,000] <error> hardfault:   R12: 0x2000360C  LR:  0x00027EC9  PSR: 0x61000000
[00:00:00.000,000] <info> stack_guard: Stack Guard (128 bytes): 0x2003E000-0x2003E07F (total stack size: 8192 bytes, usable stack area: 8064 bytes)
[00:00:00.000,000] <error> hardfault: HARD FAULT at 0x0003460E
[00:00:00.000,000] <error> hardfault:   R0:  0x00000000  R1:  0x0F81B159  R2:  0xBA5EBA11  R3:  0x2003E000
[00:00:00.000,000] <error> hardfault:   R12: 0x2000360C  LR:  0x00027EC9  PSR: 0x61000000
[00:00:00.000,000] <error> hardfault: Cause: The processor attempted a load or store at a location that does not permit the operation.
[00:00:00.000,000] <error> hardfault: MemManage Fault Address: 0x2003E000
[...]

The examples/peripheral/cli/main.c code actually does call nrf_mpu_init() before nrf_stack_guard_init(). I don't know why this one doesn't.

-Bill

RE: Stack Guard and MPU

dingari — Wed, 03 Jun 2020 19:01:34 GMT

Hi all, thank you for your responses. I'm a bit dumbfounded as to why I can't get the Stack Guard / MPU to work. I must me fundamentally misunderstanding something.

In an attempt to isolate the problem, I've taken the ble_app_cli example (SDK 15.2.0), which seems to be the only example utilizing the stack guard) - and added a write to the base of the stack.

static void core_init(void)
{
    APP_ERROR_CHECK(NRF_LOG_INIT(app_timer_cnt_get));

    if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)
    {
        APP_ERROR_CHECK(nrf_cli_init(&m_cli, NULL, true, true, NRF_LOG_SEVERITY_INFO));
    }

    nrf_drv_uart_config_t uart_config = NRF_DRV_UART_DEFAULT_CONFIG;
    uart_config.pseltxd = TX_PIN_NUMBER;
    uart_config.pselrxd = RX_PIN_NUMBER;
    uart_config.hwfc    = NRF_UART_HWFC_DISABLED;
    APP_ERROR_CHECK(nrf_cli_init(&m_cli_uart, &uart_config, true, true, NRF_LOG_SEVERITY_INFO));

    APP_ERROR_CHECK(nrf_drv_clock_init());

    nrf_drv_clock_lfclk_request(NULL);

    APP_ERROR_CHECK(app_timer_init());

    APP_ERROR_CHECK(nrf_stack_guard_init());

    *(volatile uint32_t*) STACK_BASE = 0xba5eba11;

    NRF_LOG_INFO("Written to stack base (%p): %x", STACK_BASE, *((uint32_t*)STACK_BASE));

    APP_ERROR_CHECK(nrf_pwr_mgmt_init());

    if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)
    {
        APP_ERROR_CHECK(nrf_cli_task_create(&m_cli));
    }

    APP_ERROR_CHECK(nrf_cli_task_create(&m_cli_uart));
}

This code runs past the "illegal" write and continues normally. From my understanding, this should trigger a HardFault.

Can somebody tell me what I'm missing?

RE: Stack Guard and MPU

wpaul — Wed, 11 Mar 2020 03:13:28 GMT

For information on the MPU, you should consult the ARM Cortex-M4 user's guide:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0553b/DUI0553.pdf

Cortex-M4 core itself (and its optional components) is designed by ARM Ltd. not Nordic, so the in-depth documentation for it won't be in any of the Nordic manuals.

The MPU is basically a cut-down substitute for an MMU, though without the ability to do any virtual to physical mapping. The MPU provides a fixed number of region registers which can be used to define the following things:

- Base address of the region

- Size of the region

- Region attributes

The attributes and size are defined using a single register, called MPU_RASR (Region Attribute and Size Register, see section 4.4.5 in the manual).

The attributes include things like access rights and cache behavior.

The size part is what's important here: it's defined using 5 bits of the MPU_RASR register, and specifies a power of 2. Note that the actual power of 2 is the value of the size field plus 1.

The minimum allowed value is 5, which represents 32 bytes (2^(4+1)), and the maximum value is 31, which represents 4GB (2^(31+1)).

The debug output you included shows exactly what region is being guarded: 0x2000E000 to 0x2000E07F. This means you the stack guard has been set up with a base address of 0x2000E000 and a size of 128 bytes.

What you need to do is make sure your that:

a) Your test case is actually causing a load or store instruction to be executed (i.e. it's not being optimized out by the compiler -- the volatile keyword can help prevent this)

b) The load or store is actually targeting an address _within_ that specific region.

So for example, if your code is triggering a write to address 0x2000E100, then you're writing to memory on the other side of the stack guard instead of inside it, and you won't see any trap. If you have a function that uses a large amount of local variables, the compiler might emit code that adjusts the stack pointer so far beyond the end of the stack that you skip right over the guard.

Note that it's possible to trigger a trap due to something other than an explicit load or store instruction. For example, if an exception occurs, like an interrupt, the CPU will push an exception frame onto the stack. If the stack pointer is at or near the stack guard when this happens, then this will also trigger a hard fault, because the CPU won't have enough room to save everything. This may happen more easily if you're using floating point math since in that case the CPU may also need to save the FPU registers as well.

-Bill

RE: Stack Guard and MPU

Einar Thorsrud — Tue, 10 Mar 2020 08:57:47 GMT

Hi,

I do not immediately see the issue in this case. I suspect Turbo J is onto something.

I did a tiny modification to the Command Line Interface (CLI) Example (which uses stack guard out of the box) but were not able to reproduce the behavior you see.

devzone.nordicsemi.com/.../demo_5F00_cli_5F00_cmds.c.diff

Running the example on a nRF52 DK with the above modification I get the expected hard fault after typing "nordic" in the terminal.

RE: Stack Guard and MPU

dingari — Mon, 09 Mar 2020 09:50:00 GMT

Hi, thank you for the timely reply.

Please see the below C++ snippet. I'm simulating this by allocating too big of a structure on the stack and writing to each element. If I break directly after this snippet, it leaves MSP at 0x2000d388 (beyond the stack limits).

std::array<uint8_t, 8192> tmp{};
NRF_LOG_INFO("MSP: %p", __get_MSP());
for (int i = 0; i < 8192; ++i)
    tmp[i] = i;

NRF_LOG_DEBUG("%p %p", tmp.begin(), tmp.end());
NRF_LOG_INFO("MSP: %p", __get_MSP());
    
illegal_write((void*) 0x2000E000);

Then I tried directly writing to the protected stack area with the `illegal_write`, which is placed in another compilation unit. I'm running a debug build without any optimizations.

void illegal_write(void* addr)
{
    auto* p = (uint32_t*) addr;
    *p = 1;
}

RE: Stack Guard and MPU

Turbo J — Fri, 06 Mar 2020 16:51:49 GMT

I see two possible causes

The C optimizer eliminated the write completely or placed it somewhere else (where it would not be executed).
The write buffer delayed the fault and you were only checking with a breakpoint directly after the write instruction.

In any case we would need to see your source code...