read/write to virtual address

Fri Feb 17 11:39:28 CET 2017

Hi,

are you looking for something process_vm_readv?

http://man7.org/linux/man-pages/man2/process_vm_writev.2.html

Could you give an example what do you actually need?

On 02/17/2017 10:47 AM, Daniel Krefft wrote:
> Hi,
>
> we are well aware that memory access takes place all over the operating
> system. But, comparable to a standard like POSIX, we are searching for a
> standardized function (read/write, load/store, ...) to access virtual
> memory.

You use read and write for accessing objects behind file descriptors 
(mostly files). You do not use read and write to access your own virtual 
memory, mainly because you can access your memory directly without need 
for additional API.

> A simple example in pseudo code could be:
>
> `void access_memory(virtual_adress_pointer, payload);`
>
> Let's say we ask for a functionality comparable to the mentioned
> privileged read/write (see third thread message). Maybe this is all done
> in assembly code and there is no specific C/C++ high level function?
>
>
> Thanks
> Daniel
>
>
> On 16.02.2017 23:54, Adam Lackorzynski wrote:
>> Hi,
>>
>> On Thu Feb 16, 2017 at 13:14:07 +0100, Daniel Krefft wrote:
>>> We want to know, at which place within the operating system/kernel
>>> (l4re/fiasco.oc) memory access takes place. This means, which concrete
>>> functions address the MMU (load/store) or handle the read/write virtual
>>> memory operations?
>>
>> I'm sorry I still have a hard time to make sense out of your question.
>> I'll try to explain where my difficulties come from. In code like
>> "c = a + b;" we have 2 loads and 1 store. Those happen in virtual memory
>> and are generated by the compiler. Thus load and store instructions are
>> everywhere, both in the kernel and in any user-level application and
>> thus the answer to you question could be: memory accesses are all over
>> the place.
>>
>>
>>
>> Adam
>>
>>> On 16.02.2017 00:18, Adam Lackorzynski wrote:
>>>> Hi,
>>>>
>>>> On Wed Feb 15, 2017 at 09:55:19 +0100, Daniel Krefft wrote:
>>>>> Hi,
>>>>>
>>>>> we came across two functions (read/write) that are defined in the l4
>>>>> base API documentation:
>>>>>
>>>>> https://os.inf.tu-dresden.de/L4Re/doc/group__l4__mem__op__api.html
>>>>>
>>>>> 1) What does the description "functionality to access user task memory
>>>>> from the kernel" mean? This could be interpreted as accessing user-space
>>>>> memory from within the kernel?!
>>>>
>>>> As the description says through this functions is it possible to
>>>> read/write from/to device memory in the case the device only allows
>>>> access from privileged processor more. There are some of those devices
>>>> out there where even the switch to allow access from user-mode is
>>>> broken. I guess nobody ever noticed. Those functions are only required
>>>> for those specific devices where it's necessary, i.e. not in any normal
>>>> operation. But yes, they fall under the category you describe.
>>>>
>>>>> 2) Are there any equivalent memory read/write functions inside the l4re
>>>>> that also take a virtual address as a parameter?
>>>>
>>>> Yes, there are, for example, utility functions for accessing device
>>>> memory. However I'm not sure you're looking for something like this as
>>>> this is all within the same address space and any code in there can
>>>> read/write anywhere in that address space (given paging permits).
>>>> There's no functionality to read/write memory in other address spaces
>>>> directly.
>>>>
>>>>
>>>> Adam
>>>>
>>>>> To clarify, all intended operations (read/write) should not modify
>>>>> user-space memory from inside the kernel or vice versa. User-space
>>>>> defined read/write functions should operate in user-space exclusively.
>>>>>
>>>>> Best
>>>>> Daniel
>>>>>
>>>>> On 14.02.2017 23:29, Adam Lackorzynski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tue Feb 14, 2017 at 10:38:26 +0100, Daniel Krefft wrote:
>>>>>>> while working on a checkpoint/restore mechanism for fiasco.oc, we want
>>>>>>> to trace read and write (kernel) calls to (virtual) memory.
>>>>>>>
>>>>>>> 1) Where are these calls defined? We're just able to find ARM specific
>>>>>>> calls inside the kernel, which allow writing and reading to/from a
>>>>>>> virtual address
>>>>>>>
>>>>>>> 2) Are these calls (if existent) platform agnostic (user-space)? Is
>>>>>>> there any kind of interface?
>>>>>>
>>>>>> I do not quite get the question. The kernel (Fiasco) is running in
>>>>>> virtual memory, also when running in the kernel, i.e. any load/store
>>>>>> operation that is in the code is through virtual memory.
>>>>>> Do you want to trace any read/write issued by the kernel to user-level
>>>>>> memory? I'm afraid, the kernel does not do that, i.e. it never touches
>>>>>> user-level memory (except the specially treated UTCB memory).
>>>>>> Could you please describe your question more verbosely?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>> _______________________________________________
>>>>>> l4-hackers mailing list
>>>>>> l4-hackers at os.inf.tu-dresden.de
>>>>>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel Krefft MSc.
>>>>> Wissenschaftlicher Mitarbeiter
>>>>>
>>>>> Technische Universitaet Muenchen
>>>>> Fakultaet fuer Informatik
>>>>> Lehrstuhl fuer Betriebssysteme
>>>>>
>>>>> Arcisstrasse 21
>>>>> 80333 Muenchen
>>>>>
>>>>> Tel. +49 89 289 18791
>>>>>
>>>>> daniel.krefft at tum.de
>>>>> www.os.in.tum.de/personen/krefft
>>>>>
>>>>> _______________________________________________
>>>>> l4-hackers mailing list
>>>>> l4-hackers at os.inf.tu-dresden.de
>>>>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>>>>
>>>> Adam
>>>>
>>>
>>> --
>>> Daniel Krefft MSc.
>>> Wissenschaftlicher Mitarbeiter
>>>
>>> Technische Universitaet Muenchen
>>> Fakultaet fuer Informatik
>>> Lehrstuhl fuer Betriebssysteme
>>>
>>> Arcisstrasse 21
>>> 80333 Muenchen
>>>
>>> Tel. +49 89 289 18791
>>>
>>> daniel.krefft at tum.de
>>> www.os.in.tum.de/personen/krefft
>>>
>>> _______________________________________________
>>> l4-hackers mailing list
>>> l4-hackers at os.inf.tu-dresden.de
>>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>>
>> _______________________________________________
>> l4-hackers mailing list
>> l4-hackers at os.inf.tu-dresden.de
>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>>
>

-- 
Regards,
Maksym Planeta

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170217/8046145f/attachment-0001.p7s>