Writing to userspace memory in kernel mode
197 views
Skip to first unread message
Andreas Bock
May 16, 2012, 1:48:49 AM5/16/12
to min...@googlegroups.com
Dear community,
We are implementing a user library for event-based profiling in MINIX 3.2.0, and are having problems buffering of profiling data between the kernel and the library.
We allocate our profiling data buffers in userland so both user- and kernelspace may access them. We implemented a new system call that passes the buffer pointers to the kernel (through the PM server) so the probes know where to write.
We get an unhandled kernel exception when attempting to dereference these addresses in the kernel to actually write to them.
We have tried to invoke a kernel call directly from our library to avoid passing control to a server process, but this has not helped.
Our question is: Why can the process implementing our library (and, through it, invoking the kernel call) not access the memory it has allocated itself when in kernel mode?
Git repository: http://github.com/andreasbock/minix
Yours Sincerely,
Andreas Bock & Asbjørn Thegler
Tomas Hruby
May 16, 2012, 2:06:37 AM5/16/12
to min...@googlegroups.com
On Wed, May 16, 2012 at 07:48:49AM +0200, Andreas Bock wrote:
> Dear community,
>
> We are implementing a user library for event-based profiling in MINIX
> 3.2.0, and are having problems buffering of profiling data between the
> kernel and the library.
>
> We allocate our profiling data buffers in userland so both user- and
> kernelspace may access them. We implemented a new system call that passes
> the buffer pointers to the kernel (through the PM server) so the probes
> know where to write.
> We get an unhandled kernel exception when attempting to dereference these
> addresses in the kernel to actually write to them.
> We have tried to invoke a kernel call directly from our library to avoid
> passing control to a server process, but this has not helped.
>
> Our question is: Why can the process implementing our library (and, through
> it, invoking the kernel call) not access the memory it has allocated itself
> when in kernel mode?
Why should it be able to? The process is not in kernel mode. The
> Dear community,
>
> We are implementing a user library for event-based profiling in MINIX
> 3.2.0, and are having problems buffering of profiling data between the
> kernel and the library.
>
> We allocate our profiling data buffers in userland so both user- and
> kernelspace may access them. We implemented a new system call that passes
> the buffer pointers to the kernel (through the PM server) so the probes
> know where to write.
> We get an unhandled kernel exception when attempting to dereference these
> addresses in the kernel to actually write to them.
> We have tried to invoke a kernel call directly from our library to avoid
> passing control to a server process, but this has not helped.
>
> Our question is: Why can the process implementing our library (and, through
> it, invoking the kernel call) not access the memory it has allocated itself
> when in kernel mode?
process is suspended and kernel code is running in kernel mode. Kernel
has its own address space so the address passed from userspace are not
valid. Kernel can translate these addresses though and remap them.
Look at, for instance, how is implemented senda() or safe copies.
T.
>
> Git repository:
> http://github.com/andreasbock/minix<https://github.com/andreasbock/minix>
>
>
> Yours Sincerely,
>
> Andreas Bock & Asbj?rn Thegler
>
> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>
prasannatsmkumar
May 16, 2012, 6:15:12 AM5/16/12
to min...@googlegroups.com
Using safe copies will be better. What about memory mapping (I am not sure whether minix supports it but it is found in most of the POSIX compliant systems)?
Antoine LECA
May 16, 2012, 8:26:55 AM5/16/12
to min...@googlegroups.com
prasannatsmkumar wrote:
> Using safe copies will be better. What about memory mapping
Kernel cannot _use_ memory-mapping, really some sort of virtual memory:
> Using safe copies will be better. What about memory mapping
in MINIX virtual memory is _managed_ outside of the micro-kernel, so it
is not an option (unless some strange architecture is used.)
> (I am not sure whether minix supports it but it is found in most
> of the POSIX compliant systems)?
the problem at hand involves kernel, not "just" plain processes...
Antoine
Andreas Bock
May 17, 2012, 1:33:57 PM5/17/12
to min...@googlegroups.com
Wrong button, posting for community
Date: 17 May 2012 11:20
Subject: Re: Writing to userspace memory in kernel mode
To: asbj...@gmail.com
May I ask why this conversation has to be private?
In case it was merely hitting the wrong button, I do not oppose to this
post being public, in fact I would prefer.
> More specifically, what parts of the MINIX architecture causes this limitation?
VM, not kernel, handles the management of mapping of memory; so it is VM
which allocate such memory mappings; but kernel address space is fixed
before VM even starts: this is a chicken-and-egg problem.
The "obvious" solution is to specialize a part of kernel address space
and pretends (in VM) that part is to be available for sharing purpose:
this looks like to me creating a new ad-hoc kind of memory mapping
(MMAP_NEW_KERNEL_HACK); I do not see the difference between such a hack
and the already existing mechanism like /dev/kmem or the statistical
profile buffer, and I fail to see the benefit to adhere to the POSIX or
4BSD models of memory mapping here, particularly when MINIX already has
several missing features in this area already.
> We are slightly puzzled as to how the kernel reads messages from servers if
> virtual memory addresses are not valid within the kernel.
Ok, this is slightly different. Besides having access to any part of the
physical memory using "raw" copy procedures, kernel has its own
organized address space; selected content of this address space can be
"exported" to other processes (using e.g. sys_getinfo, or even the old
/dev/kmem device but it blurs the organization); and fixed-size messages
are "imported" into that address space as part of the IPC mechanism.
Conceptually I cannot consider as equivalent: while kernel might gain
access to any part of the physical memory, it is not supposed to be
aware of what kind of memory (as managed by VM) it is, which virtual
address, whether it is shared or not, code or data, or more importantly
here, present or not.
When you look at the basic message copying, core kernel (proc.c) is not
aware of the details of the virtual memory address of it, nor does it
care (look at copy_msg_from_user in klib.S): it just uses the values in
place. This is quite different when for example in the system "task",
additional data from the sending process are needed to perform the work:
here the code has to resolve the virtual address of the paramter to
fetch, and therefore uses data_copy() hence virtual_copy(), which
emulates the pagination process and has quite more overhead; using a
shared memory mapping would avoid that overhead, but it would be adding
a new feature to the kernel architecture.
Antoine
Subject: Re: Writing to userspace memory in kernel mode
To: asbj...@gmail.com
Asbjørn Thegler wrote:
>
> We found your answer to our question below very helpful. If you have time,
> we would be very grateful if you could elaborate a bit.
>
> We found your answer to our question below very helpful. If you have time,
> we would be very grateful if you could elaborate a bit.
In case it was merely hitting the wrong button, I do not oppose to this
post being public, in fact I would prefer.
> More specifically, what parts of the MINIX architecture causes this limitation?
which allocate such memory mappings; but kernel address space is fixed
before VM even starts: this is a chicken-and-egg problem.
The "obvious" solution is to specialize a part of kernel address space
and pretends (in VM) that part is to be available for sharing purpose:
this looks like to me creating a new ad-hoc kind of memory mapping
(MMAP_NEW_KERNEL_HACK); I do not see the difference between such a hack
and the already existing mechanism like /dev/kmem or the statistical
profile buffer, and I fail to see the benefit to adhere to the POSIX or
4BSD models of memory mapping here, particularly when MINIX already has
several missing features in this area already.
> We are slightly puzzled as to how the kernel reads messages from servers if
> virtual memory addresses are not valid within the kernel.
physical memory using "raw" copy procedures, kernel has its own
organized address space; selected content of this address space can be
"exported" to other processes (using e.g. sys_getinfo, or even the old
/dev/kmem device but it blurs the organization); and fixed-size messages
are "imported" into that address space as part of the IPC mechanism.
Conceptually I cannot consider as equivalent: while kernel might gain
access to any part of the physical memory, it is not supposed to be
aware of what kind of memory (as managed by VM) it is, which virtual
address, whether it is shared or not, code or data, or more importantly
here, present or not.
When you look at the basic message copying, core kernel (proc.c) is not
aware of the details of the virtual memory address of it, nor does it
care (look at copy_msg_from_user in klib.S): it just uses the values in
place. This is quite different when for example in the system "task",
additional data from the sending process are needed to perform the work:
here the code has to resolve the virtual address of the paramter to
fetch, and therefore uses data_copy() hence virtual_copy(), which
emulates the pagination process and has quite more overhead; using a
shared memory mapping would avoid that overhead, but it would be adding
a new feature to the kernel architecture.
Antoine
Reply all
Reply to author
Forward
0 new messages