User-level objects

teclis High Elf teclis.high.elf at gmail.com
Fri Jan 23 16:00:37 CET 2015


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 at 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 at os.inf.tu-dresden.de
>   Lackorzynski         http://os.inf.tu-dresden.de/~adam/
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150123/368ff87d/attachment.html>


More information about the l4-hackers mailing list