[BUG] Calls to non-secure function from secure code shouldn't automatically clear the LSB

[696GrocuttT]

Describe the bug
The example code for a non-secure function call in section 8.3.1 contains this:

    @ perform the call to the non-secure function 
    bic     r1, r1, #1
    blxns   r1

The LSB of the function pointer is supposed to be used as a cross check that the pointer is targeting the correct security state. Always clearing it therefore misses the whole point of having this bit. The original intention was that when an NS function pointer is passed to the secure state it would have its LSB cleared using cmse_nsfptr_create(). This marks it as an untrusted NS pointer and means that:

• Any use of that pointer from a valid S->NS call site will result in a transition to the non-secure state
• Any use of that pointer by a normal BLX will fault

This approach also enable the BLXNS to be used on both S->NS and S->S calls, without any manual handling by the developer. At the moment a developer would have to do this:

    int __attribute__((cmse_nonsecure_call)) (*foo)(int) = <some value>;
    if cmse_is_nsfptr(foo) {
        foo(0);
    } else {
        ((int (*)(int)) foo)(0);
    }

Suggested solution
Just removing the BIC will break backwards compatibility and cause existing code that isn't using cmse_nsfptr_create() to fault when the S->NS call is attempted. To get around this I suggest a new attribute is added (eg cmse_either_call, although a better name would be nice) that behaves in a similar way to cmse_nonsecure_call except that it doesn't clear the LSB of the function pointer. This attribute can then be used in cases where either security state can be called, as was the original intention behind the BLXNS instruction.

[vhscampos]

Hi, thanks for your issue report.

If possible, we encourage you to contribute with a Pull Request that addresses this issue. We will be happy to review it.