this question could be borderline off-topic here, but I dare asking it still here for academic purposes. If it is off-topic, send me an email to basile@starynkevitch.net mentioning the URL of this question, even when it becomes closed
context: static source code whole program analysis of IoT firmware
As a demo example for Bismon (a still unreleased GPLv3+ framework and research project, funded thru CHARIOT, for static source code analysis thru GCC plugins, whose draft documentation is here and continuously improved) I am seeking a complete system IoT source code with the following characteristics:
small firmware source code wanted which is....
- open source licensed, entirely. The actual license is not important (I'll just compile the code a lot of times; I don't have the hardware)
- understandable by static source code analysis experts (those developing Frama-C or having developed GCC MELT and Unisim simulator, or partners of Vessedia) who are not IoT experts. So English (or French) looking code and comments please! (no comments only in Chinese or Bulgarian for example)
- cross-compilable on Debian/Linux/x86-64 with GCC 9 (or perhaps GCC 8), preferably with a cross compiler already packaged in Debian. However, having contributed to GCC, I am able to compile it from its source code.
- full source code is easily and completely available in a single
gitrepository, mostly C or C++ (and some assembler lines) - preferably with some emulator or simulator available for Linux.
- C or C++ code mostly, with as few assembler lines as possible (e.g. 300 lines of assembler is good, but 30KLOC is not good).
- the firmware binary should be in ELF format
- about four thousands to two hundred thousand lines of total source code (4KLOC - 200KLOC), as measured by sloccount. The limit is not strict, but cross-build time should be less than 10 or 20 seconds on a powerful Debian laptop.
- providing over-the-air device firmware updates
- nearly single-tasked with some event loop. We could deal with a few fixed number of tasks (e.g. interrupts driven), but not with a generic scheduler and dynamic multi-tasking with dozens or hundreds of tasks. Only one runtime IoT call stack if possible (yes, we know about kernel schedulers, green threads, continuations, etc..., we want to avoid them if possible; interrupt handlers are acceptable but would be ignored by us) or at least very few of them. Intuitively we expect the entire IoT device software to use one "major" main call stack, plus a few of smaller ones (e.g. for interrupts).
- few indirect function pointers calls, that is less than 20 to 60 static code occurrences of GIMPLE instructions doing an indirect function call. I am over-approximating the whole program call stack size, and indirect function calls are painful to handle (but will be handled "manually", in some ad-hoc way, perhaps some
#pragmabefore them).
I do have a hello world kernel source code (too small) and a GCC plugin to extract call frame sizes in it, but I want something bigger and communicating to statically analyze.
My Linux desktop runs some Debian/x86-64 system and I have root access to it and I am building then running Bismon (it is the GPLv3+ software I am working on) on it. From time to time I also build (from GNU source tree repositories) a cross binutils and a cross GCC on it.
BTW I don't want or need to port or run the IoT device code (i.e. the analyzed firmware source code) on my Linux desktop. I might want to emulate it, just to understand it better (so emulation is not really required, but could be useful to humans like me). Obviously all the IoT device source code should be cross-compilable and cross-linkable on my Linux desktop. But the static analysis framework (above GCC cross-compilation techniques) is running on a powerful Linux/x86-64/Debian desktop.
TRL issues and work context
Ths is in the context of H2020 "research and innovation action" projects with low TRL (so TRL 3 at most in 2020, and TRL 2 in 2019). I can and am willing to spend some time (e.g. to manually annotate every indirect function call site, or abstract away most threads or continuations), I just want to avoid spending too much time to make that demo and understand the IoT code. It is just for a single throw-away demo (at an official research project review in Brusells, for the European Commission, which happens to 100% fund that project), and I am aware of the demo effect.
NB: FWIW, we all are static analysis experts with PhD and more than ten years of work experience. I Basile am retiring in a few years.
BTW, coreboot is too big for us. https://mongoose-os.com/ could be nice. https://github.com/intel-iot-devkit/how-to-code-samples seems good, but slightly too small code.
