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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.