Hi,
We have moved to IDF 4.3 and faced problems during OTA with some old devices.
Those devices do not have md5 checksum in the partition table since we were using CMake build system since IDF 3.3.
And for some time it was not generated. (https://github.com/espressif/esp-idf/co ... 14703eab52)
So we disabled generation of MD5 and updated those devices (set CONFIG_PARTITION_TABLE_MD5=n)
Which drawbacks can we get? And what is the function of this checksum?
Purpose of the partition table md5 checksum
-
- Posts: 1
- Joined: Thu Oct 21, 2021 8:05 am
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: Purpose of the partition table md5 checksum
The downside would be that some types of corruption in the partition table could not be detected anymore. This means that in case of flash corruption, a device could boot with a corrupted partition table, leading to strange errors later on that may not indicate that the partition table is at fault; with a MD5 checksum, these errors would be detected immediately. Note that in general, corruption like this does not occur frequently, so in practice there should not be much difference.
(There's one other purpose, and that is if you have flash encryption and secureboot turned on. In that case, someone could corrupt a random 16-byte area of the partition table by messing with the flash in that area. With an MD5sum, the ESP32 halts immediately; without it, whatever problems result from this corruption may play a part in someone compromising the device. It'd be non-trivial to exploit this, if it even is possible, though.)
(There's one other purpose, and that is if you have flash encryption and secureboot turned on. In that case, someone could corrupt a random 16-byte area of the partition table by messing with the flash in that area. With an MD5sum, the ESP32 halts immediately; without it, whatever problems result from this corruption may play a part in someone compromising the device. It'd be non-trivial to exploit this, if it even is possible, though.)
Re: Purpose of the partition table md5 checksum
Very old thread but maybe ESP_Sprite {https://esp32.com/memberlist.php?mode=viewprofile&u=169} is still listening...
We have the same situation and needed the ability to change the partition table on the fly (as part of a firmware update) for adding coredump and SPIFFS partitions to very old firmware.
We are now at a situation where we would like to add the MD5 functionality to firmware in the field but simply enabling it now causes a crash.
Can an API be made available that will recalculate the MD5 checksum in flash so that a future (next?) version of OTA firmware, with the MD5 functionality enabled, will function correctly?
Thanks
We have the same situation and needed the ability to change the partition table on the fly (as part of a firmware update) for adding coredump and SPIFFS partitions to very old firmware.
We are now at a situation where we would like to add the MD5 functionality to firmware in the field but simply enabling it now causes a crash.
Can an API be made available that will recalculate the MD5 checksum in flash so that a future (next?) version of OTA firmware, with the MD5 functionality enabled, will function correctly?
Thanks
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: Purpose of the partition table md5 checksum
I'd be more interested in knowing why the firmware crashes if you add a MD5; from what I know, that should be backwards compatible with bootloaders that don't check MD5sums. Can you explain a bit more about the exact situation in which you see the crash?
Re: Purpose of the partition table md5 checksum
HI @ESP_Sprite thanks for the response, I think my initial thoughts were wrong.
The initial checking was done on a new bootloader+firmware combo to check out the logic first.
In order to better understand the situation we now did 2 builds of the exact same firmware, the only difference being CONFIG_PARTITION_TABLE_MD5 set to false in the first and true in the second.
We then looked at bootloader.bin and firmware.bin with respect to size and content.
Boot-loaders:
Exactly the same size with minimal content differences, being the build time (3 bytes in the "header") and 32 bytes right at the end, assuming this a checksum of the boot loader
Firmwares:
Different in size and in content. LOTS of 1 and 2 bytes difference but ultimately the version with CONFIG_PARTITION_TABLE_MD5=y is 208 bytes bigger. Both firmwares appear to have a checksum at the end.
Q: Does both boot-loader and firmware have a checksum at the end?
Q: Does the partition table checksum get stored in the partition table as a "special" entry with flags 0xEBEB in the last 16 bytes?
Q: Are all the checksums MD5 based, or something else?
Q: Does the consistent size of the boot-loaders indicate that the checksum verification of the partition table does NOT happen in the boot-loader?
Q: Does the additional 208 bytes in the firmware with MD5 enabled indicate that the checksum support is here and not in the boot-loader?
Q: Is there any way to reasonably safely upgrade a boot-loader in the field?
All help and advice appreciated...
The initial checking was done on a new bootloader+firmware combo to check out the logic first.
In order to better understand the situation we now did 2 builds of the exact same firmware, the only difference being CONFIG_PARTITION_TABLE_MD5 set to false in the first and true in the second.
We then looked at bootloader.bin and firmware.bin with respect to size and content.
Boot-loaders:
Exactly the same size with minimal content differences, being the build time (3 bytes in the "header") and 32 bytes right at the end, assuming this a checksum of the boot loader
Firmwares:
Different in size and in content. LOTS of 1 and 2 bytes difference but ultimately the version with CONFIG_PARTITION_TABLE_MD5=y is 208 bytes bigger. Both firmwares appear to have a checksum at the end.
Q: Does both boot-loader and firmware have a checksum at the end?
Q: Does the partition table checksum get stored in the partition table as a "special" entry with flags 0xEBEB in the last 16 bytes?
Q: Are all the checksums MD5 based, or something else?
Q: Does the consistent size of the boot-loaders indicate that the checksum verification of the partition table does NOT happen in the boot-loader?
Q: Does the additional 208 bytes in the firmware with MD5 enabled indicate that the checksum support is here and not in the boot-loader?
Q: Is there any way to reasonably safely upgrade a boot-loader in the field?
All help and advice appreciated...
Re: Purpose of the partition table md5 checksum
Sorry another question.
Q: Will overwriting the xAA x50 + 16x checksum bytes with all xFF effectively disable checksum tests?
Q: Will overwriting the xAA x50 + 16x checksum bytes with all xFF effectively disable checksum tests?
Re: Purpose of the partition table md5 checksum
Sorry to bother @ESP_Sprite https://esp32.com/memberlist.php?mode=viewprofile&u=169
Any chance you can help with some of the questions above?
Any chance you can help with some of the questions above?
Who is online
Users browsing this forum: No registered users and 255 guests