GDB / Child VSpace

[midnightveil]

From Krishnan.

[cazb2]

These thoughts relate to the Vspace/Frame handling rather than the GDB logic. It would be great if we could implement a more general solution to accessing frame capabilities, both one's own and another PD's.

Another approach that I have experimented with is the idea that you can share frames on a per memory region basis i.e. if PD A wants the frames that PD B has for memory region X it could unambiguously specify this in the SDF. Some potential caveats being the stack, maybe also the IPC buffer frame and intermediate page table caps....

This would then give PD A essentially an array of frame caps ordered on the corresponding virtual addresses that PD B has them mapped at. Then by providing the base frame capability (slot in PD A's CNode), base virtual address, maybe the base physical address if needed, memory region size and frame type (small, large, huge) etc PD A can do a constant time lookup to any frame based on the virtual address PD B has mapped it at. This would also assume a memory region only uses one type of frame.

Then based on the user application e.g. GDB a PD could allocate itself an appropriately sized memory region to build any application specific data structures such as page tables or hash map or trees etc.

[midnightveil]

Yes, this is one of the improvements I want to make with #520. It should be possible to ask for capabilities at a more fine grained level than current.

This would then give PD A essentially an array of frame caps ordered on the corresponding virtual addresses that PD B has them mapped at.

This also relates to #422. setvar has limitations that have become apparent, especially on x86 where many physical addresses are determined at runtime.

We should handle this generically and in a uniform manner, rather than various adhoc mechanisms for specific usecases.

[midnightveil]

We need to make sure this change only gives extra caps in the case where we actually want this feature to be active, and not unconditionally.

[midnightveil]

Idle thought: I'm wondering if this actually ever needs to give capabilities. Mentioned by @joep here, one can simulate the current necessary behaviour by just converting a program image into a bunch of memory regions and mapping them in.

So in essence what we could actually do is have the ability to do <map mr using some autogenerated regions based on the section names of the <program_image>. And this can map in at mostly arbitrary vaddr in the "parent" and then some metadata tracking mechanism. Do we actually need the caps - and if we did, surely this should be a generic mechanism for memory regions.

This wouldn't be changing any capability features; however, we would lose the guarantee that nobody can touch program code, which is an assumption in many of our proofs.

[joep]

Idle thought: I'm wondering if this actually ever needs to give capabilities. Mentioned by @joep here, one can simulate the current necessary behaviour by just converting a program image into a bunch of memory regions and mapping them in.

So in essence what we could actually do is have the ability to do <map mr using some autogenerated regions based on the section names of the <program_image>. And this can map in at mostly arbitrary vaddr in the "parent" and then some metadata tracking mechanism. Do we actually need the caps - and if we did, surely this should be a generic mechanism for memory regions.

This wouldn't be changing any capability features; however, we would lose the guarantee that nobody can touch program code, which is an assumption in many of our proofs.

I would argue against this approach (yes it is what we did but we didn't really want to). It is simpler than cap sharing but it is also more costly. Every debuggee PD needs its own disjoint VA range in the debugger's address space and the page-table objects created and populated by the CapDL initializer at boot. Always mapped, whether or not anyone ever inspects it because access is entirely driven by unpredictable user requests. Debug support becomes a cost that grows linearly with the whole system's memory.

I think cap frame sharing is a much better and lighter weight alternative. Debugger can hold cheap cap table slots and map/unmap on demand into one reusable scratch VA. Boot-time work and static kernel-object count stays flat regardless of how many PDs or how much memory the system has and page table entries are created only when the debugger chooses to look at something and can then be torn back down after. It only has access to other PDs during the brief peek/poke mapping window.