First trouble with core

[Norman Feske]

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.

-- 
Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org