Hi， As I know, we can set access permissions for the kernel objects, and access to user-level objects is through IPC_Gate. So, can I set access permissions for user-level objects through the IPC_Gate? Another question is that If multiple clients need to access a particular service object, do they use different IPC_Gate or the same?
Hi,
On Sat Dec 06, 2014 at 22:24:20 +0800, li94575 wrote:
As I know, we can set access permissions for the kernel objects, and access to user-level objects is through IPC_Gate. So, can I set access permissions for user-level objects through the IPC_Gate?
Yes. This is done by giving the appropriate rights flags on mapping. In Ned's scripting, there are those ':mode("...")' statements (typically abbreviated with just ':m("...")' or just 'svr()' that define those permissions. However, bits to be used by user-level implementations are just the write bit.
Another question is that If multiple clients need to access a particular service object, do they use different IPC_Gate or the same?
Mostly the same IPC-gate but actually both is possible. The purpose of the IPC-gate is not only to identify the server object but also to identify the client, or at the least the group of clients. So if you want to identify a specific client (or a specific group of clients) you hand them a separate IPC gate. If the server does not care a single IPC-gate will just be fine.
Adam
At 2014-12-07 07:36:38, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
Hi,
On Sat Dec 06, 2014 at 22:24:20 +0800, li94575 wrote:
As I know, we can set access permissions for the kernel objects, and access to user-level objects is through IPC_Gate. So, can I set access permissions for user-level objects through the IPC_Gate?
Yes. This is done by giving the appropriate rights flags on mapping. In Ned's scripting, there are those ':mode("...")' statements (typically abbreviated with just ':m("...")' or just 'svr()' that define those permissions. However, bits to be used by user-level implementations are just the write bit.
If I only map a capability with reading permission for server object, but I actually perform a writing operation on the object with the capability, can you tell me where the kernel do the permission checking?and for the objects, how to define the reading and writing operation?
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Mon Dec 08, 2014 at 22:10:40 +0800, li94575 wrote:
At 2014-12-07 07:36:38, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
Hi,
On Sat Dec 06, 2014 at 22:24:20 +0800, li94575 wrote:
As I know, we can set access permissions for the kernel objects, and access to user-level objects is through IPC_Gate. So, can I set access permissions for user-level objects through the IPC_Gate?
Yes. This is done by giving the appropriate rights flags on mapping. In Ned's scripting, there are those ':mode("...")' statements (typically abbreviated with just ':m("...")' or just 'svr()' that define those permissions. However, bits to be used by user-level implementations are just the write bit.
If I only map a capability with reading permission for server object, but I actually perform a writing operation on the object with the capability, can you tell me where the kernel do the permission checking?and for the objects, how to define the reading and writing operation?
For caps, the kernel does not care about the write bit, however, it's visible on the server side and can be used there. The first parameter for the typical dispatch function is that 'l4_umword_t obj', which is actually the label. The lower bits of that obj also encode the 'W' bit. So by testing 'obj & L4_CAP_FPAGE_W' you see whether the caller (client) has the cap with or without the W bit mapped.
Adam
Hi, would someone be able to point me to example code for setting access control on a kernel object? Say I am brining up Fiasco on new hardware that has certain instructions that can only be executed when running in kernel privilege level but I want to control which tasks can use them. Could I create a new class of kernel object for my hardware instruction and then set access control on this class of kernel object so only my task can make the syscall. No other tasks i.e. Moe, Ned etc. would be able to instantiate my new kernel object and make the protected syscall. Or alternatively if some one could recommend a mechanism for controlling which tasks could make a new syscall in Fiasco L4Re that would be very helpful to.
thanks
On Mon, Dec 8, 2014 at 7:00 PM, Adam Lackorzynski <adam@os.inf.tu-dresden.de
wrote:
On Mon Dec 08, 2014 at 22:10:40 +0800, li94575 wrote:
At 2014-12-07 07:36:38, "Adam Lackorzynski" adam@os.inf.tu-dresden.de
wrote:
Hi,
On Sat Dec 06, 2014 at 22:24:20 +0800, li94575 wrote:
As I know, we can set access permissions for the kernel objects, and access to user-level objects is through IPC_Gate. So, can I set access permissions for user-level objects through the IPC_Gate?
Yes. This is done by giving the appropriate rights flags on mapping. In Ned's scripting, there are those ':mode("...")' statements (typically abbreviated with just ':m("...")' or just 'svr()' that define those permissions. However, bits to be used by user-level implementations are just the write bit.
If I only map a capability with reading permission for server object,
but I actually perform a writing operation on the object with the capability, can you tell me where the kernel do the permission checking?and for the objects, how to define the reading and writing operation?
For caps, the kernel does not care about the write bit, however, it's visible on the server side and can be used there. The first parameter for the typical dispatch function is that 'l4_umword_t obj', which is actually the label. The lower bits of that obj also encode the 'W' bit. So by testing 'obj & L4_CAP_FPAGE_W' you see whether the caller (client) has the cap with or without the W bit mapped.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Tue Dec 09, 2014 at 10:32:09 -0500, teclis High Elf wrote:
Hi, would someone be able to point me to example code for setting access control on a kernel object? Say I am brining up Fiasco on new hardware that has certain instructions that can only be executed when running in kernel privilege level but I want to control which tasks can use them. Could I create a new class of kernel object for my hardware instruction and then set access control on this class of kernel object so only my task can make the syscall. No other tasks i.e. Moe, Ned etc. would be able to instantiate my new kernel object and make the protected syscall. Or alternatively if some one could recommend a mechanism for controlling which tasks could make a new syscall in Fiasco L4Re that would be very helpful to.
Sounds like the easy and straightforward way is to have a singleton kernel object. This one is then used to execute the instructions. Filtering etc. can be implemented in user-space. Now there's no example code on how to get the cap through to your program, it's nothing standard to do usually. Further, giving it just to your task is difficult as there's no way to identify a 'random' task in the kernel that is dynamically created. What happens at boot time is that both sigma0 and moe are equipped with their set of caps. This can be done because the kernel creates both tasks so it can map something in there. Other tasks are not known at this point as they do not exist yet. Further, e.g. sigma0 and moe have control over your app's memory so they could make your app do what they want. Thus I do not think that it is reasonable to guard against those services. Now a plan could be roughly like this: In the kernel, look at another singleton, e.g. Vlog, then write your class, create a static object, use initial_kobjects.register_obj(this, 10) in the constructor. With that it will appear in moe under cap-idx 10. In moe, you add root_name_space()->register_obj("xyz", Obj(Obj::F_rw, 10 << 12)); in main.cc so it will be accessible in your ned script via L4.Env.xyz. Then pass it on as usual to your program.
HTH, Adam
Thanks Adam. I took a look at Vlog. Where is the logic that prevents a second instance of a Vlog kernel object from being created? I wasn't able to find it.
thanks
On Tue, Dec 9, 2014 at 6:17 PM, Adam Lackorzynski <adam@os.inf.tu-dresden.de
wrote:
On Tue Dec 09, 2014 at 10:32:09 -0500, teclis High Elf wrote:
Hi, would someone be able to point me to example code for setting access control on a kernel object? Say I am brining up Fiasco on new hardware
that
has certain instructions that can only be executed when running in kernel privilege level but I want to control which tasks can use them. Could I create a new class of kernel object for my hardware instruction and then set access control on this class of kernel object so only my task can
make
the syscall. No other tasks i.e. Moe, Ned etc. would be able to
instantiate
my new kernel object and make the protected syscall. Or alternatively if some one could recommend a mechanism for controlling which tasks could
make
a new syscall in Fiasco L4Re that would be very helpful to.
Sounds like the easy and straightforward way is to have a singleton kernel object. This one is then used to execute the instructions. Filtering etc. can be implemented in user-space. Now there's no example code on how to get the cap through to your program, it's nothing standard to do usually. Further, giving it just to your task is difficult as there's no way to identify a 'random' task in the kernel that is dynamically created. What happens at boot time is that both sigma0 and moe are equipped with their set of caps. This can be done because the kernel creates both tasks so it can map something in there. Other tasks are not known at this point as they do not exist yet. Further, e.g. sigma0 and moe have control over your app's memory so they could make your app do what they want. Thus I do not think that it is reasonable to guard against those services. Now a plan could be roughly like this: In the kernel, look at another singleton, e.g. Vlog, then write your class, create a static object, use initial_kobjects.register_obj(this, 10) in the constructor. With that it will appear in moe under cap-idx 10. In moe, you add root_name_space()->register_obj("xyz", Obj(Obj::F_rw, 10 << 12)); in main.cc so it will be accessible in your ned script via L4.Env.xyz. Then pass it on as usual to your program.
HTH, Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
li94575 -
teclis High Elf