SLAU723A October 2017 – October 2018 MSP432E401Y , MSP432E411Y
An application designer can use the execute-only protection to help protect the integrity and confidentiality of software stored in these protected regions, helping prevent, for example, unauthorized software updates or software reverse-engineering. If, however, the attacker has debug access or has malicious code running, the confidentiality of the code in the execute-only region during runtime could be compromised, for example by observing the effect of each instruction on CPU registers. Therefore, an application designer should consider implementing additional security measures such as debug lock, carefully written software update mechanisms, use of the memory protection unit (MPU), and other appropriate security measures to protect valuable software.
Literal data introduces a complication to the protection mechanism. When C code is compiled and linked, literal data (constants, and so on) is typically placed in the text section, between functions, by the compiler. The literal data is accessed at run time through the use of the LDR instruction, which loads the data from memory using a PC-relative memory address. The execution of the LDR instruction generates a read transaction across the DCode bus of the Cortex-M4, which is subject to the execute-only protection mechanism. If the accessed block is marked as execute only, the transaction is blocked, and the processor is prevented from loading the constant data and, therefore, inhibiting correct execution. Therefore, using execute-only protection requires that literal data be handled differently. There are three ways to address this: