Hi Jiri, On 11/10/2017 02:43 PM, Jiri Svoboda wrote: > what is the benefit of call_t being based on kobject? Isn't that making > thins unnecessarily complicated? Why would you want to, e.g. pass around > a call like a capability?
call_t structures are kernel objects that are meant to be visible to userspace. Currently the userspace knows them by the so called hashes, which are in fact their kernel addresses. Now, there are several problems with this. Leaking kernel pointers to userspace is not optimal from the security perspective. Moreover, it is impossible to resume a snapshotted task which uses kernel addresses as hashes [1]. Their globaliness makes capability-based virtualization problematic too. Lastly, my long-term goal is to provide only one type of task-local userspace handles for all types of kernel objects - capabilities. My future targets will be answerboxes, tasks and threads. Also note that currently, call_t implement their own reference counting. This would go away as kobject_t does that too, so I think that things will get more unified in this sense. Why would I want to pass around a call using a capability? This is indeed a truly interesting question. Even though I am not going to do that (yet), passing around call_t using capabilities is basically IPC. So theoretically it would be possible to drop the current explicit IPC code and only have code which passes around capabilities, including call_t capabilities. For some objects, for example the already existing irq_t it does not make much sense to be able to pass their capabilities to someone else. Maybe only if we want to allow someone else to unregister the irq. So I think it is okay to use capabilities also for objects that are not primarily meant to be passed to someone else (or already use another mechanism). Jakub [1] http://www.helenos.org/doc/theses/tb-thesis.pdf _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
