Hello!
I try to understand how capabilities are enforced by the Fiasco.OC kernel. From what I think I understood, capabilities are created in the kernel space area of an address space (which is the same in every address space) at Config::Caps_start. Each cap is identified by an index in this area and holds a reference to an object of type kobject_iface in its _obj attribute. This is the object this cap is controlling access to. Now I've got a few questions about further details.
Where does the translation from address space local to kernel global cap id happen?
How does the kernel know threads of which space are allowed to access which cap (mapdb?)?
When a thread sends IPC, in which place of the kernel code do these caps get enforced / checked?
BR,
Christoph
Hi,
On Thu Feb 03, 2011 at 09:54:10 +0100, Christoph Szeppek wrote:
I try to understand how capabilities are enforced by the Fiasco.OC kernel. From what I think I understood, capabilities are created in the kernel space area of an address space (which is the same in every address space) at Config::Caps_start. Each cap is identified by an
I think that's the mistake. While the kernel itself (e.g. code) is tagged globally, the cap space itself is local for each task.
index in this area and holds a reference to an object of type kobject_iface in its _obj attribute. This is the object this cap is controlling access to. Now I've got a few questions about further details.
Where does the translation from address space local to kernel global cap id happen?
How does the kernel know threads of which space are allowed to access which cap (mapdb?)?
With the above those questions should be clear?
When a thread sends IPC, in which place of the kernel code do these caps get enforced / checked?
Enforced or checked is actually the wrong term here. The cap is used to talk to an object, if there's no cap there's no pointer to an object, which means there's nothing to talk to. See src/kern/syscalls.cpp.
Adam
l4-hackers@os.inf.tu-dresden.de