Re: read/write to virtual address

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. 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
>>>>> [email protected]
>>>>> 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
>>>>
>>>> [email protected]
>>>> www.os.in.tum.de/personen/krefft
>>>>
>>>> _______________________________________________
>>>> l4-hackers mailing list
>>>> [email protected]
>>>> 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
>>
>> [email protected]
>> www.os.in.tum.de/personen/krefft
>>
>> _______________________________________________
>> 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
> 

-- 
Daniel Krefft MSc.
Wissenschaftlicher Mitarbeiter

Technische Universitaet Muenchen
Fakultaet fuer Informatik
Lehrstuhl fuer Betriebssysteme

Arcisstrasse 21
80333 Muenchen

Tel. +49 89 289 18791

[email protected]
www.os.in.tum.de/personen/krefft