SPI glash write protection

[Melab]

Does the M1 come with any mechanisms for write protecting the on-board SPI flash?

[mad_ady]

I don't think so. You'd need to decouple the Write Enable pin from the existing circuitry. (though I haven't looked at the schematic and I could be wrong)

[mctom]

You were close though.
The write enable pin is wired to SoC, because it doubles as one of the four data pins in quad SPI mode. So as far as I can tell it cannot be used for write protection.

[Melab]

I don't think so. You'd need to decouple the Write Enable pin from the existing circuitry. (though I haven't looked at the schematic and I could be wrong)

Are you referring to a write protection pin?

[Melab]

You were close though.
The write enable pin is wired to SoC, because it doubles as one of the four data pins in quad SPI mode. So as far as I can tell it cannot be used for write protection.

I do not see pin titled "write enable" in the
datasheet for the Macronix MX25U12832F. I see a "write protection" pin.

[mctom]

Yeah, that's the same thing. You either let someone write on it, or not.

[Melab]

Yeah, that's the same thing. You either let someone write on it, or not.

Is the SPI flash chip used in QSPI mode? Is the system wired to be able to change the mode?

[mctom]

I assume it is used in QSPI mode, given all the hints in the schematics of the board.

Look, the short answer is: if you want to keep secrets on SPI this is not going to work - the chip can be desoldered and read by any high school electronics hacker.

[Melab]

I assume it is used in QSPI mode, given all the hints in the schematics of the board.

Look, the short answer is: if you want to keep secrets on SPI this is not going to work - the chip can be desoldered and read by any high school electronics hacker.

It's not about keeping secrets. Where do you get that idea from? It's to protect the firmware from modification by the system.

[mctom]

Well then, I guess root privileges are enough protection against overwriting SPI Flash.

[tobetter]

In the schematic, in my understanding, the Write Protection in SPI flash memory is wired to GPIO1_C7 in SoC and this pin can be functional as one of EMMC_RSTn or FSPI_D2 or FLASH_WPn. Currently ODROID-M1 uses the pin is doing its job for EMMC_RSTn for generic system. Which can be simply commented Wirte Protection is fully disabled.

Based on this, my considerable options in order to prevent unexpected writing to SPI are:

• Put low GPIO1_C7 by modifying the device tree so WPn in SPI flash memory is in low state, but disadvantage of this methos is that eMMC could not work since it looses one signal EMMC_RSTn which is necessary when eMMC is initiated on booting.

• Similarly putting GPIO1_D2 to high or high-impedance state, this will makes the SPI flash is not accessible. Also switching to another pins to GPIO could help preventing to access the SPI flash memory

• Hiding the SPI flash by removing SPI flash node in device tree won't allow you to access the SPI flash memory by a software. SPI flash memory is presented as /dev/mtd* when it's discovered in device tree, a device cannot be accessed without a device node.

• Obviously the SPI flash can be accessed without /dev/mtd* only when you are privileged to access CPU registers, and this can be possible if Linux kernel provide a method through a device driver that opens a specific memory addresses but in security perspective it's a bad idea.

.

[Melab]

Well then, I guess root privileges are enough protection against overwriting SPI Flash.

Incorrect. I want to use the SPI flash chip's write protection mechanisms. It’s to create a root of trust WITHOUT using the boot ROM's digital signature check functionality. Then, the one of the Raspberry Pi-compatible TPMs will be used to for anti-rollback counters.

[Melab]

In the schematic, in my understanding, the Write Protection in SPI flash memory is wired to GPIO1_C7 in SoC and this pin can be functional as one of EMMC_RSTn or FSPI_D2 or FLASH_WPn. Currently ODROID-M1 uses the pin is doing its job for EMMC_RSTn for generic system. Which can be simply commented Wirte Protection is fully disabled.

Based on this, my considerable options in order to prevent unexpected writing to SPI are:

• Put low GPIO1_C7 by modifying the device tree so WPn in SPI flash memory is in low state, but disadvantage of this methos is that eMMC could not work since it looses one signal EMMC_RSTn which is necessary when eMMC is initiated on booting.

• Similarly putting GPIO1_D2 to high or high-impedance state, this will makes the SPI flash is not accessible. Also switching to another pins to GPIO could help preventing to access the SPI flash memory

• Hiding the SPI flash by removing SPI flash node in device tree won't allow you to access the SPI flash memory by a software. SPI flash memory is presented as /dev/mtd* when it's discovered in device tree, a device cannot be accessed without a device node.

• Obviously the SPI flash can be accessed without /dev/mtd* only when you are privileged to access CPU registers, and this can be possible if Linux kernel provide a method through a device driver that opens a specific memory addresses but in security perspective it's a bad idea.

.

1. So is the ODROID-M1's SPI flash made to function in quad mode?
2. If the value of the WP pin can be toggled by software, then the write protection doesn't work in the way I want it to. It must not be modifiable by the software running on the device.
3. I am aiming for a protection model like what exists on Chromebooks wherein the software cannot change the overall write protection status.
4. What is left is that I might have to use the SPI flash chip's power cycle write protection.