Hi Julian,
Julian Stecklina wrote:
Is it possible to use a guard page to detect stack overflow? Having a way to implement guard pages using Bastei primitives would be nice for some other projects I have in mind.
Our current plan is to use a dedicated area of the virtual address space to locate the stacks, for example each stack would reside within an 1MB area. Of this 1M range, only a few pages would actually be backed by RAM dataspaces. Therefore, we would have plenty of guard pages in-between the stacks. The current Genode mechanisms are already sufficient to implement such an allocation scheme (using a Range_allocator for managing the virtual stack area, and calling rm_session->attach() with specifying the 'local_addr' argument). This alone would certainly be an improvement over co- locating stacks with the heap.
However, once having such an allocation scheme in place, it would be useful to reflect (RM-session-) faults to the process (right now, faults are only indicated by a debug message from Core). I am thinking of adding a signalling mechanism to the RM-session. An RM-fault handler could then receive fault signals (analogous to an exception handler that gets invoked by page fault), request the cause of the fault (analogously to looking at an exception- stack frame), and attach a dataspace to the faulted address (analogously to setting a page-table entry). So functionality-wise, an RM-session would pretty much correspond to a page table, only that it is using dataspaces rather of physical pages. This would not just enable us to detect stack overflows and invalid memory accesses but it would make the implementation of dynamically growing stacks straight-forward.