Hi Martin,
I am not sure about the "dynamic part". I would either set the stack
from outside (as discussed above), or allow some kind of memconfig
call, which can be executed only once after application startup.
Alternatively you could provide munmap and munmap_done. Dynamic people
would just never call munmap_done...
I thought a bit more about this idea of adding a munmap call and I don't
really like it.
Maybe the goal should be extended to allow multiple different memory
areas, randomly distributed in the address space to leverage ASLR. One
of those memory areas is the stack then. This could work either by
configuring the memory areas statically from outside or dynamically
inside the application. The application should start with a fixed small
stack size. To allocate heap areas or a larger stack, solo5 should
simplify offer solo5_mem_alloc, which allows to allocate page sized heap
blocks until the available heap memory is exhausted.
struct solo5_start_info {
const char *cmdline;
size_t stack_size;
};
int solo5_app_main(const struct solo5_start_info *info);
void* solo5_mem_alloc(size_t);
size_t solo5_mem_avail(void);
On very primitive backends solo5_mem_alloc would just do a pointer bump.
On better backends, full randomization could be done. Maybe this
proposal is similar to what the IncludeOS people requested before?
What are the downsides of this approach?
Daniel
