Memory sharing between user and kernel
Adam Lackorzynski
adam at os.inf.tu-dresden.de
Wed Feb 15 11:35:23 CET 2012
Hi,
On Tue Feb 14, 2012 at 23:11:00 +0900, 안영호 wrote:
> I’m trying to apply an asynchronous batch processing of IPC into l4/fiasco
> to increase the bandwidth of IPC.
>
> I think the main problem is the performance of IPC when virtualization is
> applied to mobile system.
>
> To increase the performance of IPC, I try to use the memory sharing between
> the address space of user library and that of kernel memory.
I assume you want bandwidth for data transfer between address spaces.
For that use shared memory between tasks. IPC is not meant for that.
> There is a way to access user memory from kernel, but I couldn’t find any
> way to read kernel memory in user space.
>
> At first, I want to know whether it is meaningful to use an asynchronous
> batch processing of IPC, or not.
Shared memory can be used to store requests or chunks of data for access
in other protection domains. IPC can be used for notification.
> Second, when my user library tries to use the virtual address of a kernel
> global variable by passing it to user address space, “unhandled exception:
> pc=xxxx” occurs.
>
> I think that region mapper makes that exception while it’s checking the
> range of virtual address.
And before that the CPU issues an exception because of an access of
memory that is not available for the currently running code. That's how
it should be.
> If I want to access kernel memory in user address space, what can I do?
Nothing, you don't.
> Maybe it causes security problems and it’s not proper for virtualization.
This is unrelated to virtualization. And it does cause problems in that
regard. If it would be allowed to write kernel memory for anyone, why
have a protecting kernel at all?
> However, in my opinion, some compromise will be needed for the future
> mobile virtualization system.
A compromise for security?
Adam
--
Adam adam at os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
More information about the l4-hackers
mailing list