EEPROM write protection

[rtfmoz2]

Security: The Boot Process -- Forum Discussion

".. it is possible to physically write-protect both EEPROMs via a simple resistor change on the board. Details will be published in the schematics." -- Documentation

Not yet indicated in the schematics. Please add this information.

[meeDamian]

Note that supply chain attacks exist, meaning EEPROM can already be compromised upon delivery.

Obviously, the HW itself can be compromised as well, but EEPROM is a particularly easy way to do it, as it's software only, and compromising it could take literal seconds.

[JamesH65]

@jimbojr Can we add this resistor mod to the schematics?

[mAPBhlJ]

Note that supply chain attacks exist, meaning EEPROM can already be compromised upon delivery.

By that logic the Broadcom chip on the Raspberry Pi could be compromised as well and have a coprocessor that does whatever. If you feel it is required; you can re-write the EEPROM yourself upon arrival of your Raspberry Pi (if you trust the Broadcom unit).

Obviously, the HW itself can be compromised as well, but EEPROM is a particularly easy way to do it, as it's software only, and compromising it could take literal seconds.

Yes, the EEPROM can even be overwritten by software, altering your bootcode.
The point is; this resistor modification should make this impossible in software.

In this case; someone can still walk up to your Raspberry Pi and put the resistor back on, or solder a completely different EEPROM on it, but that's not the point.

Anyways.

The documentation states SPI EEPROM, which would mean an external EEPROM module.

These modules often have an "write enable" input pin, by cutting the trace to this input pin (or removing the resistor that's on this line), you can make this EEPROM essentially a (EE?)ROM ;)

I would say it's the black chip on the back labeled "SKUK" since it's close to the SD Card interface (which commonly uses SPI). The label "SKUK" doesn't help me on this and I'm not going to try cutting those traces one-by-one to identify the pins, nor do I have the time to reverse engineer them using an oscilloscope, but be my guest.

You may try to reverse engineer the recovery .bin files to see what it does to write to it; but I'm not even sure if that's viable.

Long story short:
We'll have to wait for the Raspberry Pi org to release the EEPROM part of the schematics or simply tell us which trace/resistor to cut/remove.

[JamesH65]

@jimbojr @mike-stimson Is this still on the cards for improvement?

[JamesH65]

@Roger-Thornton Added to CC.

[stiell]

Decided to look a little into this myself.

According to https://hackaday.io/page/6372-raspberry-pi-4-boot-sequence, talking about the boot EEPROM:

This is a standard Winbond W25X40 chip, access through SPI0 on GPIO 4043.

Datasheet: https://www.winbond.com/resource-files/w25x40cl_e01.pdf

It's an 8-pin chip. There are two 8-pin chips on the board, both on the front near the A/V jack. Size is 2x3mm. This corresponds to the UX package type of the W25X40 chip. Top side marking according to datasheet is:

4Hxxx
0Gxxx

This matches the marking on the chip closest to the A/V jack.

The other chip near the A/V jack is a Winbond W25X10 EEPROM chip connected to the VL805 (USB controller) chip, so I presume the W25X10 contains the USB controller firmware.

"/WP" (Write Protect Input, active low) is on pin 3 according to the datasheet. Both chips' "/WP" pins are connected together and to TP5 on the back of the board, as well as a 1k8 resistor next to TP5. The resistor goes to 3V3. Next to it is a pair of unpopulated pads that allow for a resistor between TP5 and GND.

Moving the resistor to these unpopulated pads, or placing a 0-ohm resistor there, should pull "/WP" down and activate the pin. However, the BP2/BP1 (Block Protect) and SRP (Status Register Protect) bits in the chip's status register must also be set to 1 (factory default is 0) for write protection to be enabled. I don't know if BP2/BP1 and SRP already gets set to 1 in either chip.

(Edited to mention BP2/BP1.)

[stiell]

I played around a little with spidev and strace + vl805 (is there any source code for the vl805 binary?), and found that neither EEPROM chip has its protection bits set.

So for write protection to work, something has to be done on the software side as well. This should be reasonably simple to do for the boot EEPROM. Not sure about the VL805 EEPROM, but the vl805 binary is at least able to talk SPI to the EEPROM in a slightly more convoluted way (confirmed using strace), so it should be possible.

[lurch]

is there any source code for the vl805 binary?

raspberrypi/rpi-eeprom@e35f0c7 (in combination with https://github.com/raspberrypi/rpi-eeprom/blob/master/LICENSE ) suggests not 😉

[ejolson2005]

Is there any progress on this issue? I have a use case at

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=275911&p=1672167#p1672167

where being able to write-protect the EEPROMs is almost essential. Thanks in advance for everyone who has looked into this and is presently working on it.

[cleverca22]

(assuming OTP66 isnt modified*)

you can just put an uSD card with recovery.bin to reflash the eeprom at any time, even if the firmware is malicious

the mask rom gives recovery.bin priority, and will never even look at the eeprom

*: OTP66 lets you configure a gpio to be able to disable SD or SPI boot, so you could hold a button to skip one of them

[lurch]

Yeah, but inserting a uSD card requires physical access, and having physical access (nearly) always trumps any security measures?

[rtfmoz2]

That's right, you can't protect the security of a device if they have physical access. We are trying to protect against remote attempts at compromising the device and reprogramming it for alternative purposes.

…

On Thu, 4 Jun 2020 at 21:29, Andrew Scheller ***@***.***> wrote: Yeah, but inserting a uSD card requires physical access, and having physical access (nearly) always trumps any security measures? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1302 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJYYSIVEY72KEQUKD7YOIV3RU6AS5ANCNFSM4I6YVWGA> .