ARM: Cortex-M: IRQ lock/unlock() API non-functional but accessible from user mode

[ioannisg]

Describe the bug

IRQ API is a kernel API, so, normally it shall not be accessible from user mode. This is the case for most of the API functions; an attempt to use them leads to a CPU fault.

This is not the case, however, for irq_lock(), irq_unlock() for ARM Cortex-M Mainline architecture (both ARMv7-M and ARMv8-M): these functions do not cause a fault if called from user mode, although, they (correctly) do not lock or unlock interrupts. Since we do not explicitly document that the IRQ API shall only be used from supervisor mode, this might end up very confusing for user threads calling irq_lock/unlock API.

To Reproduce
Steps to reproduce the behavior:
Simply call irq_lock() from user mode on ARM Cortex-M Mainline. The call does not fail and does not lock the IRQs.

Expected behavior
It should be clear for user mode threads that irq lock /unlock cannot be used.

I would see two options here

• either add an assert on irq_lock, unlock when called from user mode
• or simply document explicitly that the API shall not be used from user mode, otherwise we might have undefined behavior.

[ioannisg]

CC @andrewboie

[jhedberg]

Discussed in the release meeting: The documentation update needs to be done either way, however an assert is probably nice too since otherwise this risks hard-to-catch bugs with critical regions seemingly working but actually not.

[pderwin]

I'll echo the 'hard-to-catch bugs' commentary. I have been actively pursuing a problem on Cortex-R in user mode that turned out to be this exact issue. Our user-mode code believed it was locking a critical section, but in reality was not.

Now investigating how to re-factor the code to rely on semaphore instead of interrupt disable.