This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bit 0 of PC on ARMv8-M unset in non-secure code?

The document

http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.…

on page 8 says the least significant bit of the PC is used to distinguish between secure and non-secure state - and as far as I can make out non-secure state has the bit unset and secure state has it set. Surely that is rather  incompatible with the current use where it always has to be 1 and I would say most of the code would be counted as insecure? Why is the bit required anyway?

Parents
  • In ARMv8-M, there are only a limited number of cases where the least-significant-bit of the address is used to determine the target Security state; primarily these are when the address is passed to the new BXNS and BLXNS instructions.

    The existing BX and BLX instructions retain their existing behaviour, and thus retain compatibility with existing code, i.e. ARMv7-M code run on ARMv8-M won't suddenly be jumping between Security states.

    As illustrated in Figure.2 of the document you reference, the new BXNS, BLXNS and SG instructions, combined with a special return address (FNC_RETURN), provide the mechanics for calling and returning in both directions between Non-secure and Secure code. The combination of SG and BXNS form one of the many tools ARMv8-M offers to enable easier and more robust creation of secure software; the SG sets the least-significant bit of the link-register to match the calling Security state; the subsequent return via BXNS effectively ensures that the return address and calling Security state are consistent, thus providing a hardware mechanism to avoid the Secure code accidentally providing access to other Secure code via its function return (had the Non-secure code provided a bogus link-register value).

    Simon.

Reply
  • In ARMv8-M, there are only a limited number of cases where the least-significant-bit of the address is used to determine the target Security state; primarily these are when the address is passed to the new BXNS and BLXNS instructions.

    The existing BX and BLX instructions retain their existing behaviour, and thus retain compatibility with existing code, i.e. ARMv7-M code run on ARMv8-M won't suddenly be jumping between Security states.

    As illustrated in Figure.2 of the document you reference, the new BXNS, BLXNS and SG instructions, combined with a special return address (FNC_RETURN), provide the mechanics for calling and returning in both directions between Non-secure and Secure code. The combination of SG and BXNS form one of the many tools ARMv8-M offers to enable easier and more robust creation of secure software; the SG sets the least-significant bit of the link-register to match the calling Security state; the subsequent return via BXNS effectively ensures that the return address and calling Security state are consistent, thus providing a hardware mechanism to avoid the Secure code accidentally providing access to other Secure code via its function return (had the Non-secure code provided a bogus link-register value).

    Simon.

Children