Hi,
I’m new to FreeRTOS, when I first use it I found that it seems only can flash a prewritten program into the kernel. So I’m wondering if it can load an arbitrary binary program into the kernel and executed or can it directly execute some syscall like a Linux kernel?
Best,
You have a fundamental misunderstanding about what FreeRTOS is. FreeRTOS is not like an OS that controls a system and lets you run independent programs with it, it is a control library that is PART of a program to provide it with resources to handle multiple threads of execution within it.
FreeRTOS itself (or at least the kernel part of it) doesn’t really do ANY I/O, so can’t do things like ‘loading’ a program. It would likely be possible to write for yourself something like that functionality, but it isn’t part of FreeRTOS natively.
I see what you mean. But is there any relatively elegant way to make FreeRTOS accept any input (i.e., network, pipline or shared memory) so that it can perform some operations or trigger some functionality?
That isn’t the kernel’s job. You would need an app that is FreeRTOS based that does the loading, and probably work out some system so the loaded program can access the FreeRTOS in the loader app.
I see…, so basicly we cannot call any arbitrary syscall API when we run a FreeRTOS image except those we have already written. Am I understanding right?
well, a FreeRTOS “image” is a complete standalone software into which you statically link everything needed for your system, including OS, BSP, middleware and everything else. As Richard pointed out earlier, there is no concept of “dynamically loadable” applications (I leave complex boot loaders out of the discussion for now). Of corse you’re free to design such an architecture yourself on top of FreeRTOS and/or other RTOSs if your target has sufficient resources.
The big problem is the loadable modules, when being built, won’t know where the various pieces of code will be, so it is hard to ‘load’ them. And if the ‘core’ module didn’t need to use them, they might not even be included in the core image.
If I was to build such a system, I would add an API module to the core code that generates a jump table to the routines I want the loadable modules to be able to use, and a matching module that the loadable modules link with that provide the addresses of the entries in the table. You also need to leave ram space open in the linker definitions to have room to load into.
Be aware that unloading a module may tricky, as you need to make sure that nothing is still referencing the module, and it has freed all the resources that it has acquired.
This will NOT give you a shell like interface, just a run time system configuration ability.
Hi, My intention is to port fuzzing into FreeRTOS testing. Please let me know if this is possible.
Using qemu to start the kernel, then write an application that can read a specific memory in the system, and this memory can be used as shared memory between qemu and the kernel, which in turn can pass some other programs (like syscall sequences) to the OS ane execute.
One BIG question on that, what are you looking at as a ‘threat model’. FreeRTOS does not really have a ‘security’ layer, it basically trusts the application, and it is up to the application to provide what ever protection is needed from ‘outside’ threats.
If I want to right an application that crashes the system, FreeRTOS won’t do anything to prevent it, so the fact that I might be able to crash some part of the kernel isn’t really a significant threat.
Sort of like it doesn’t matter how good the locks are on a convertible if the top and windows are down and the key is in the ignition.
I believe there is a misunderstanding here. it is one thing that FreeRTOS does not have a security layer, it is like doing rm -r /* in the Linux kernel, which in older versions of Linux would undoubtedly crash the system. However, what I’m trying to find is some bug from inside the system, like an application being expected to return A and due to some code error it returns B.
sorry… my intention is to support full system simulation, rather than unit test
If your intention is testing of freeRTOS application under linux, you can follow different strategy. It requires certain preparations and maintenance efforts.
You can compile freeRTOS application and emulate freeRTOS system calls with Linux system calls (Linux must have pre-emptive patch), in theory you can even run it on similar hardware like ARM/x86/else and with the same version of compiler.
I think that there are commercial packages that Emulate freeRTOS with Linux calls and vice versa, but if usage of freeRTOS API is limited you can write such layer by your own.
My intention is to try to test the FreeRTOS kernel itself rather than the application. Currently, my thought is to test it in a pre-written application by dynamically loading some syscalls or instructions through shared memory. I would like to know if such an approach is feasible?
Despite my intention is to test the kernel itself, I believe it worth a try, and will look into it!
As someone mentioned before. There is fundamental difference between Linux and FreeRTOS.
FreeRTOS is service layer linked together with application. Unlike Linux, there is standalone FreeRTOS and you cannot (easily) download modules. Running FreeRTOS binaries natively (unmodified) on Linux is also not that simple.
If we talk about x86 or CortexA port that is a remote chance to run it unmodified under VM, but you would need to supply para-virtualization layer, emulate somehow all hardware that freeRTOS needs (timer, UART, some i/o).
If your goal is to be able to, at program compile time, just add the file.c to your program and compile it in, we basically have that already, there isn’t much need for an intermediate function (unless there are other requirements not yet stated). I regularly have programs that to add features I add a new source file, and than add a call to an init function in main() to set up the task and any queues it needs.
Hi, Kathleen
There may be some ambiguity about my descriptions. Everything within FreeRTOS is statically linked during compile time, however, what I want to do is make this static program capable of loading some instructions or some variables from somewhere else dynamically (for instance, using qemu to boot a FreeRTOS, and pass some variables from the host machine).
My current idea is statically to assign a variable with a fixed address then mapping to a corresponding address on the host machine, make a sort of “pipeline” between two machines, using such pipeline to connect two machines thereby passing values or instructions. I wonder if such an approach is feasible?
Best regards.
Yes, having a program get some ‘input’ from a program that loads it can be done with an assigned block of ram that the loader fills with the info, and the receiver looks at. One key is you need to make that block of memory not get initialized by the startup code in the loaded program, but this isn’t that hard.
Have you checked with other attempts to run FreeRTOS in a qemu environment? Querying this forum yields a number of hits such as this one:
Regards
Hi,
Yes! I did some research on how to emulate FreeRTOS on the qemu environment, and some other attempts using shared memory like:
Discussions like these give me lots of instructions and ideas, thanks for your generous helping and efforts!
I don’t see why FreeRTOS should not be able to run in QEMU. In case you want some more “flexibility” you could do the following with the Yocto Project:
QEMU use case:
Here[1] are various examples (not for FreeRTOS, but it should be quite easy to build FreeRTOS instead of Zephyr) including: qemu-cortex-m3, qemu-nios2, qemu-x86
[1] machine « conf - meta-zephyr - Layer to support building of Zephyr images
Heterogenous hardware use case (one chip with Cortex-A cores running Linux and one or more Cortex-M cores) or different Cortex-A and Cortex-M chips:
Here[2] is an example how to build FreeRTOS and a custom Embedded Linux distro.
[2] meta-st-stm32mp/recipes-extended/m4projects at dunfell · STMicroelectronics/meta-st-stm32mp · GitHub