The ChameleonMini is a versatile contactless smartcard emulator compliant to NFC. The ChameleonMini was developed by https://kasper-oswald.de. The device is available at https://shop.kasper.it. For further information see the Getting Started Page https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__getting_started.html or the Wiki tab above.
Other
1.74k
stars
392
forks
source link
Fixes to LiveLogTick function, memory bounds checking, and optimizations to save memory space requirements in the firmware #285
After some discussion with @ceres-c summarized in #284 (with possible build configuration solutions in #283), the standard firmware binary that resulted before used too much memory. This seems to be the cause of several recent issues and unpredictable crashes running the firmware. I looked at this today and found some fixes that help. Note that with these changes the newly compiled binary yields:
$ avr-size -t Chameleon-Mini.elf
text data bss dec hex filename
56424 1288 4716 62428 f3dc Chameleon-Mini.elf
56424 1288 4716 62428 f3dc (TOTALS)
The last numeric column is noted to not exceed 0x10000.
A complete summary of all the changes contained in this pull request are given below:
Change in the implementation of LiveLogTick: In #279, this functionality was merged. It included small numbers of dynamic allocation of memory space via malloc/free. This is typically not good practice on memory constrained devices, and pulls in extra memory requirements. I rewrote the core of the LiveLogTick.h sources to store the linked list node structures in the LogMem buffer (along with the temporary contents of logs). The solution removes the need for the dynamic memory alloc/dealloc functions from GLibC. It also seems to fix some oversights in the original code based on testing. Notice that every position for the structure pointer addresses needs to be an even multiple of four.
A couple of new FRAM memory R/W functions: Added MemoryReadBlockInSetting and MemoryWriteBlockInSetting that tag implementations can call to safely write to the FRAM space for their slot. These check an upper bound on the size of the block address, and add an offset into FRAM based on the slot index. In contrast, the original two functions do not ignore unintentional memory boundary errors and do not shift the block address by the slot index offset.
Makefile changes: The added flags, and the change of value of the FLASH_DATA_SIZE option reflects the noise and discussion from yesterday. Nothing fancy, just compiler optimizations to make the memory imposed on the AVR less bloated.
After some discussion with @ceres-c summarized in #284 (with possible build configuration solutions in #283), the standard firmware binary that resulted before used too much memory. This seems to be the cause of several recent issues and unpredictable crashes running the firmware. I looked at this today and found some fixes that help. Note that with these changes the newly compiled binary yields:
The last numeric column is noted to not exceed
0x10000.A complete summary of all the changes contained in this pull request are given below:
malloc/free. This is typically not good practice on memory constrained devices, and pulls in extra memory requirements. I rewrote the core of theLiveLogTick.hsources to store the linked list node structures in theLogMembuffer (along with the temporary contents of logs). The solution removes the need for the dynamic memory alloc/dealloc functions from GLibC. It also seems to fix some oversights in the original code based on testing. Notice that every position for the structure pointer addresses needs to be an even multiple of four.MemoryReadBlockInSettingandMemoryWriteBlockInSettingthat tag implementations can call to safely write to the FRAM space for their slot. These check an upper bound on the size of the block address, and add an offset into FRAM based on the slot index. In contrast, the original two functions do not ignore unintentional memory boundary errors and do not shift the block address by the slot index offset.FLASH_DATA_SIZEoption reflects the noise and discussion from yesterday. Nothing fancy, just compiler optimizations to make the memory imposed on the AVR less bloated.