4.1.1.4.1 Mutable Data in Flash: Access Control

Access control for non-critical mutable data in Flash is essential to prevent unauthorized code execution and to minimize the risk of exploitation. For regions such as calibration data or emulated EEPROM, which must be updatable during a normal application operation, dsPIC33A devices support fine-grained access control through Flash protection regions.

To secure these regions, configure a dedicated Flash protection region with write permissions enabled to allow legitimate data updates, but with execute permissions disabled to prevent any code from being run from this area. Read permissions can be set according to application requirements but should be restricted if the data are sensitive. Additionally, the region should be locked until Reset, preventing reconfiguration of permissions during run time and ensuring that execution cannot be enabled by malicious code. See Region 2 in Figure 4-7.

Configuring a Mutable Data Region is an example of how to configure such a region:

Configuring a Mutable Data Region

// FPR2CTRL
#pragma config FPR2CTRL_RDIS = OFF  //Region protection enabled
#pragma config FPR2CTRL_EX = OFF    //Execute permission disabled
#pragma config FPR2CTRL_RD = ON     //Read permission enabled (if needed)
#pragma config FPR2CTRL_WR = ON     //Write permission enabled (mutable data)
#pragma config FPR2CTRL_RTYPE = FIRMWARE //Region type: Firmware configurable
#pragma config FPR2CTRL_PSEL = BOTH //Partition Select: Both Panels

// FPR2ST
#pragma config FPR2ST_START = 0x47  //Region start address bits 

// FPR2END
#pragma config FPR2END_END = 0x47   //Region end address bits

By applying these access controls, the application can update non-critical data in Flash while preventing the region from being used to execute code or being reconfigured during runtime. This approach helps mitigate the risk of code injection attacks.

An important item to note is that this data region is locked with writes enabled. This will allow any self-writing code to make modifications to this region, including accidental writes. A benefit of the Flash protection regions is that the regions of Flash can be protected against accidental/invalid writes by leaving regions write-protected only unlocked by the code that is allowed to modify them. By locking the region until Reset to prevent allowing execution permissions to be enabled, the mutable data region cannot selectively enable/disable write permissions.

Using a second overlapping Flash protection region can restore that capability, if required. How overlapping regions work is discussed in more detail in Overlapping Regions.

Figure 4-8. Overlapping Flash Protection
???

In Figure 4-8, Region 3 is added to overlap Region 2 in order to control the run time write permissions and help reduce risk of accidental writes.

Key Considerations:

  • Disable write permissions mutable data regions on Reset to reduce the risk of image corruption
  • Disable execution permissions to mutable data regions on Reset to help prevent invalid execution
  • Consider locking until Reset mutable data regions with execution permissions disabled to help prevent code being loaded into the data region and execution permission being enabled
  • Consider adding a second protection region to more strictly restrict write permissions of the mutable data section