enable MPU protect on SBSFU for STM32L1 returns memory fault on accessing eeprom

[jeroenjvdb]

According to the integration guide (an5056) it should be possible to use the flash memory to store user data (chapter 8.2) . However, when turning on the MPU protect define the controller goes into a memory fault when accessing the eeprom for reading (located at position 0x0808 0001) on stm32l151RE

The code used for accessing the eeprom is the following:

#include "sfu_low_level_eeprom.h"
#include <stdbool.h>
#include "sfu_low_level_flash.h"
 
static bool checkBounds(uint16_t address)
{
	return address >= FLASH_EEPROM_END - FLASH_EEPROM_BASE;
}
 
 
uint8_t sfu_ll_eeprom_readByte(uint16_t address, uint8_t * data)
{
	if(checkBounds(address))
	{
		return 0;
	}
	memcpy(data, (uint8_t *) (address + FLASH_EEPROM_BASE), 1);
	return 1;
}
 

I've had the same problem when accessing the eeprom from the user application while using similar code.

Should the eeprom only be accessible through the secure engine callgate ? because this seems like quite an unnecessary workaround for just accessing user data seeing as it's stated that this is possible even is we use the flash memory itself for storing user data.

[Jocelyn RICARD]

Hello @jeroenjvdb​ 

It seems this region was missed in the MPU mapping on the STM32L1.

On first look the change of MPU to get it working does not seem straightforward.

I'm sorry, I have not enough time right now to dig into this. I'll raise the point internally.

Best regards

Jocelyn

[jeroenjvdb]

Hi @Jocelyn RICARD​ 

Am I correct to assume that when we disable this protection, there is a possibility that the software that's running on te device can read out the encryption key for example. but if we trust the software which is running on the device that our sensitive data is still invisible to possible malicious users by using the WDP and RDP protect?

[Jocelyn RICARD]

Hello @jeroenjvdb​ 

Yes, the MPU protection is an internal isolation mechanism only. One of its purposes is to create a privileged area and a non privileged area. Non privileged code cannot access privileged area.

The RDP level2 protects from debugger connection as well as system bootloader connection. So, it is part of the external protection.

WRP in conjunction with RDP level 2 ensures immutability of SBSFU (impossible to write or erase).

The internal isolation has 2 purposes:

1) As you said, isolated untrusted software

2) isolate critical code and data from a "remote" software attack.

Such attacks use the interfaces provided by the firmware such as serial interfaces (UART, USB ...) and network interfaces. Interfaces increase the surface of attack. So, if you don't have internal isolation, you need to address more precisely the software used for these interfaces to prevent from such attack.

You can have a look to the simple stack overflow example we provide in the security MOOC:

In the chapter 05: Adding protection.

Best regards

Jocelyn