On 17-12-14 10:10, Anton Lundin wrote:
On 16 December, 2014 - Anton Lundin wrote:
On 15 December, 2014 - Jef Driesen wrote:
On 21-11-14 21:28, Anton Lundin wrote:
This imports Tiny AES128 from https://github.com/kokke/tiny-AES128-C for use in the decoding of OSTC3 firmwares.
There are two problems with this aes implementation.
The first one is the stdint.h header, which is not available when compiling with msvc. This can be fixed easily by replacing uint8_t and uint32_t with unsigned char and unsigned int. (This is also the main reason why libdivecomputer doesn't use those C99 integer types anywhere.)
Wouldn't it actually be better if you either typedef'ed all the needed types yourself in a stdint-for-msvc.h ?
Or even, started using <cstdint> ?
This is what I did as a quick hack in aes.h:
#ifdef _MSC_VER typedef unsigned char uint8_t; typedef unsigned int uint32_t; #else #include <stdint.h> #endif
That was enough to get msvc to compile the aes code.
The second one are the global variables. This is not thread-safe, so this will need to be refactored to move those global variables into some aes_ctx_t structure, and pass that to the helper functions instead. The alternative is to link against some crypto library (e.g. openssl). But that might be overkill for what we need.
Its a simpe thing to switch to openssl/aes.h and AES_encrypt()/AES_decrypt() but then Debian and co will go mental about linking gpl software to openssl...
Yea, i know its a bridge to pass, but do firmware code _really_ need to be thread safe?
Late last night i took a stab at, and did a quite quick'n'dirty change to tiny-AES128-C to move the static state varables to a state struct and allocate that one on the stack instead.
I suggested the idea to upstream and we will se what they say, but they aren't completely against the idea:
https://github.com/kokke/tiny-AES128-C/pull/9
Or we could always carry such code as a local patch.
If this gets accepted, then great. If not, we can indeed carry a local patch.
Thread safety is important to me. I'm aware that it's very unlikely that someone will be doing two firmware updates in parallel. But for other use-cases using multiple threads is not uncommon. For example a typical scenario is to download the dives in a worker thread, and parse them on the main (GUI) thread. To make that work, things need to be thread-safe.
If some parts are thread-safe but others are not, that's just asking for trouble. That's why I insist on using only thread-safe code in libdivecomputer.
Jef