Re: User-level objects
teclis High Elf <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <CAN4o2gN5D-6j25+JB_Hqc7XMf9+xhGQ8iwbvX5wnB86swTb1kg@mail.gmail.com> |
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 <[email protected] > 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 [email protected] > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > _______________________________________________ > l4-hackers mailing list > [email protected] > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > _______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers