Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Sahibzada Irfanullah]

[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]

Dear All,

I have asked this question previously, but some people told me to explain
what I really want to do. First of all, I am completely naïve andnewbie in
the kernel development.

I am trying to develop my own program that generate the log of guest
physical addresses by trying to save the contents of "gpa" variable (which
is present in the handle_ept_violation()functino in vmx.c ) into my file. I
have found one sample code online (which uses filp_open(), filp_close(),
kernel_read(), and kernel_write() functions), this code is working in the
kernel space as a kernel module, but not working for my task in the
handle_ept_voilation().

My actual goal is to generate log of physical addresses for different
applications by writing them into the file, and then perform some analysis
at runtime in this function by reading the logs from the log file.
Furthermore, I want a file which size can dynamically grow as the size of
log increases.

I know that reading/writing in a kernel is not a good idea, but due to
nature of the task, I have to this.

Thank you very much for your help.
-- 
Regards,

*Mr. Irfanullah*

[-- Attachment #1.2: Type: text/html, Size: 2828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 850 bytes --]

On Tue, 24 Sep 2019 19:10:59 +0900, Sahibzada Irfanullah said:

> My actual goal is to generate log of physical addresses for different
> applications by writing them into the file, and then perform some analysis

What makes you think that the log of physical addresses will tell you anything
useful or interesting?

Hint:  Pretty much all physical pages usable for process space are identical as far
as the kernel is concerned, and if a virtual or disk cache page is pulled into memory
from disk more than once, the same virtual page can end up in different physical
pages.each time.

> at runtime in this function by reading the logs from the log file.
> Furthermore, I want a file which size can dynamically grow as the size of
> log increases.

Are you trying to do this *at runtime in real time*, or is post-run analysis OK?


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Sahibzada Irfanullah]

[-- Attachment #1.1: Type: text/plain, Size: 1261 bytes --]

Thank you for your response.
After having a reasonable amount  of log data, I want to perform some type
of analsys at run time, e.g., no. of unique addresses, total no. of
addresses, frequency of occurences of each addresses etc.

On Tue, 24 Sep 2019 at 20:16, Valdis Klētnieks <valdis.kletnieks@vt.edu>
wrote:

> On Tue, 24 Sep 2019 19:10:59 +0900, Sahibzada Irfanullah said:
>
> > My actual goal is to generate log of physical addresses for different
> > applications by writing them into the file, and then perform some
> analysis
>
> What makes you think that the log of physical addresses will tell you
> anything
> useful or interesting?
>
> Hint:  Pretty much all physical pages usable for process space are
> identical as far
> as the kernel is concerned, and if a virtual or disk cache page is pulled
> into memory
> from disk more than once, the same virtual page can end up in different
> physical
> pages.each time.
>
> > at runtime in this function by reading the logs from the log file.
> > Furthermore, I want a file which size can dynamically grow as the size of
> > log increases.
>
> Are you trying to do this *at runtime in real time*, or is post-run
> analysis OK?
>
>

-- 
Regards,

*Mr. Irfanullah*

[-- Attachment #1.2: Type: text/html, Size: 2098 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Greg KH]

On Tue, Sep 24, 2019 at 07:10:59PM +0900, Sahibzada Irfanullah wrote:
> Dear All,
> 
> I have asked this question previously, but some people told me to explain
> what I really want to do. First of all, I am completely naïve andnewbie in
> the kernel development.
> 
> I am trying to develop my own program that generate the log of guest
> physical addresses by trying to save the contents of "gpa" variable (which
> is present in the handle_ept_violation()functino in vmx.c ) into my file. I
> have found one sample code online (which uses filp_open(), filp_close(),
> kernel_read(), and kernel_write() functions), this code is working in the
> kernel space as a kernel module, but not working for my task in the
> handle_ept_voilation().
> 
> My actual goal is to generate log of physical addresses for different
> applications by writing them into the file, and then perform some analysis
> at runtime in this function by reading the logs from the log file.
> Furthermore, I want a file which size can dynamically grow as the size of
> log increases.
> 
> I know that reading/writing in a kernel is not a good idea, but due to
> nature of the task, I have to this.

"have to"?

What about a ring buffer that you write to in the kernel and then read
out from in userspace?  You can use debugfs for that.

But really, a simple tracepoint is probably all you need here, and maybe
not even that if you use ftrace.  Have you tried that today?  I doubt
you need any kernel changes at all to get this information directly from
the kernel to userspace.  Look at all of the ebpf and tracing examples
as a way to do this.

good luck!

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 3329 bytes --]

On Tue, 24 Sep 2019 20:26:36 +0900, Sahibzada Irfanullah said:

> After having a reasonable amount  of log data,

If you're trying to figure out how the kernel memory manager is working, you're
probably better off using 'perf'  or one of the other tracing tools already in
the kernel to track the kernel memory manager. For starters, you can get those
tools to give you things like stack tracebacks so you know who is asking for a
page, and who is *releasing* a page, and so on.

Of course, which of these tools to use depends on what data you need to answer
the question - but simply knowing what physical address was involved in a page
fault is almost certainly not going to be sufficient.

> I want to perform some type of analsys at run time, e.g., no. of unique
> addresses, total no. of addresses, frequency of occurences of each addresses
> etc.

So what "some type of analysis" are you trying to do? What question(s)
are you trying to answer? 

The number of unique physical addresses in your system is dictated by how much
RAM you have installed. Similarly for total number of addresses, although I'm
not sure why you list both - that would mean that there is some number of
non-unique addresses.  What would that even mean?

The number of pages actually available for paging and caching depends on other
things as well - the architecture of the system, how much RAM (if any) is
reserved for use by your video card, the size of the kernel, the size of loaded
modules, space taken up by kmalloc allocations, page tables, whether any
processes have called mlock() on a large chunk of space, whether the pages are
locked by the kernel because there's I/O going on, and then there's things like
mmap(), and so on.

The kernel provides /proc/meminfo and /proc/slabinfo - you're going to want
to understand all that stuff before you can make sense of anything.

Simply looking at the frequency of occurrences of each address is probably not
going to tell you much of anything, because you need to know things like
the total working and resident set sizes for the process and other context.

For example - you do the analysis, and find that there are 8 gigabytes of pages
that are constantly being re-used.  But that doesn't tell you if there are two
processes that are thrashing against each other because each is doing heavy
repeated referencing of 6 gigabytes of data, or if one process is wildly referencing
many pages because some programmer has a multi-dimensional array and is
walking across the array with the indices in the wrong order

i_max = 4095; j_max = 4095;
for (i = 0, i < i_max; i++) for j = 0, j < j_max; j++) {sum += foo[i][j]}

If somebdy is doing foo[j][i] instead, things can get ugly.  And if you're
mixing with Fortran code, where the semantics of array references is reverse
and you *want* to use 'foo[j][i]' for efficient memory access, it's a bullet loaded
in the chamber and waiting for somebody to pull the trigger.

Not that I've ever seen *that* particular error happen with a programmer
processing 2 terabytes of arrays on a machine that only had 1.5 terabytes of
RAM.  But I did tease the person involved about it, because they *really*
should have known better. :)

So again:  What question(s) are you trying to get answers to?


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Sahibzada Irfanullah]

[-- Attachment #1.1: Type: text/plain, Size: 6341 bytes --]

1 > Have you tried that today?  I doubt you need any kernel changes at all
to get this information directly from the kernel to userspace.
I also feel the same. Because I have to written these information to the
file, as well as read from the file in the same kernel function, i.e,
handle_ept_voilation(). I want the file which stores text (e.g., CSV), not
bytes so that I can also open it using Open Office etc.
Thanks. I will try ftrace, and debugfs. I am not sure ftrace, but may be
debugfs may help some what.

2 > For starters, you can get those tools to give you things like stack
tracebacks so you know who is asking for a page, and who is *releasing* a
page, and so on
At the start my goal is to generating log of physical addresses involved in
page faults. Further, I will extend my program to store other informations
to the file, like as you said, which process is requesting/releasing the
page, and which instruction address refered to which memory reference which
was not present in the memory, how many times an address was involved in a
page fault etc.)

3 > So what "some type of analysis" are you trying to do? What question(s)
are you trying to answer?
   Uptill now I want to perform simple analysis mentioned in the above
question 2. Morevoer, this analysis will provide details about the
instruction address that is responsible for page fault along with memory
reference that is no present, the appliction that generated this page
fault, and for a single address how many times a page fault occured etc.
By unique and non-unique, I  meant the list of addresses in the log without
duplication. For example, we have log of addresses
[1,2,2,3,3,4,3,3,4,4,4,1, 4]. In this list unique addresses are 1,2,3,4,
and frquency of each address is 2,2, 4,5 respectively.   At this stage I
want to keep things very simple by ignoring the details like size of the
RAM, size of kernel, size of loaded modules etc. Briefly I can say I want
to generate the log for guest physical addresses involved in page fault,
the corresponding instruction address, coressponsing logical address, along
with the corresponding application.

At the first stage, I am trying to develope an application that provides
some basic functionalities (i.e., instruction instrumentation) of Pin Tool
<https://software.intel.com/sites/landingpage/pintool/docs/71313/Pin/html/index.html#EXAMPLES>
for
just guest physical address by tracing instruction addresses, memory
referencees, and save it to the file. And the file can not only be
accessible from within the kernel, but also can be opened using any word
processing application ,e.g., csv or .txt file.
Thank you very much for the help.


On Wed, 25 Sep 2019 at 03:55, Valdis Klētnieks <valdis.kletnieks@vt.edu>
wrote:

> On Tue, 24 Sep 2019 20:26:36 +0900, Sahibzada Irfanullah said:
>
> > After having a reasonable amount  of log data,
>
> If you're trying to figure out how the kernel memory manager is working,
> you're
> probably better off using 'perf'  or one of the other tracing tools
> already in
> the kernel to track the kernel memory manager. For starters, you can get
> those
> tools to give you things like stack tracebacks so you know who is asking
> for a
> page, and who is *releasing* a page, and so on.
>
> Of course, which of these tools to use depends on what data you need to
> answer
> the question - but simply knowing what physical address was involved in a
> page
> fault is almost certainly not going to be sufficient.
>
> > I want to perform some type of analsys at run time, e.g., no. of unique
> > addresses, total no. of addresses, frequency of occurences of each
> addresses
> > etc.
>
> So what "some type of analysis" are you trying to do? What question(s)
> are you trying to answer?
>
> The number of unique physical addresses in your system is dictated by how
> much
> RAM you have installed. Similarly for total number of addresses, although
> I'm
> not sure why you list both - that would mean that there is some number of
> non-unique addresses.  What would that even mean?
>
> The number of pages actually available for paging and caching depends on
> other
> things as well - the architecture of the system, how much RAM (if any) is
> reserved for use by your video card, the size of the kernel, the size of
> loaded
> modules, space taken up by kmalloc allocations, page tables, whether any
> processes have called mlock() on a large chunk of space, whether the pages
> are
> locked by the kernel because there's I/O going on, and then there's things
> like
> mmap(), and so on.
>
> The kernel provides /proc/meminfo and /proc/slabinfo - you're going to want
> to understand all that stuff before you can make sense of anything.
>
> Simply looking at the frequency of occurrences of each address is probably
> not
> going to tell you much of anything, because you need to know things like
> the total working and resident set sizes for the process and other context.
>
> For example - you do the analysis, and find that there are 8 gigabytes of
> pages
> that are constantly being re-used.  But that doesn't tell you if there are
> two
> processes that are thrashing against each other because each is doing heavy
> repeated referencing of 6 gigabytes of data, or if one process is wildly
> referencing
> many pages because some programmer has a multi-dimensional array and is
> walking across the array with the indices in the wrong order
>
> i_max = 4095; j_max = 4095;
> for (i = 0, i < i_max; i++) for j = 0, j < j_max; j++) {sum += foo[i][j]}
>
> If somebdy is doing foo[j][i] instead, things can get ugly.  And if you're
> mixing with Fortran code, where the semantics of array references is
> reverse
> and you *want* to use 'foo[j][i]' for efficient memory access, it's a
> bullet loaded
> in the chamber and waiting for somebody to pull the trigger.
>
> Not that I've ever seen *that* particular error happen with a programmer
> processing 2 terabytes of arrays on a machine that only had 1.5 terabytes
> of
> RAM.  But I did tease the person involved about it, because they *really*
> should have known better. :)
>
> So again:  What question(s) are you trying to get answers to?
>
>

-- 
Regards,

*Mr. Irfanullah*

[-- Attachment #1.2: Type: text/html, Size: 7591 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Sahibzada Irfanullah]

[-- Attachment #1.1: Type: text/plain, Size: 7012 bytes --]

I am sorry if I am bothering you.
I have read this article
<http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html>,
I have to ask that will Netlink socket work for my task; Storing the
contents of "gpa" variable (which is present in the
handle_ept_violation()functino in vmx.c ) into a file.
Thank you.

On Wed, 25 Sep 2019 at 11:44, Sahibzada Irfanullah <irfan.gomalian@gmail.com>
wrote:

> 1 > Have you tried that today?  I doubt you need any kernel changes at all
> to get this information directly from the kernel to userspace.
> I also feel the same. Because I have to written these information to the
> file, as well as read from the file in the same kernel function, i.e,
> handle_ept_voilation(). I want the file which stores text (e.g., CSV), not
> bytes so that I can also open it using Open Office etc.
> Thanks. I will try ftrace, and debugfs. I am not sure ftrace, but may be
> debugfs may help some what.
>
> 2 > For starters, you can get those tools to give you things like stack
> tracebacks so you know who is asking for a page, and who is *releasing* a
> page, and so on
> At the start my goal is to generating log of physical addresses involved
> in page faults. Further, I will extend my program to store other
> informations to the file, like as you said, which process is
> requesting/releasing the page, and which instruction address refered to
> which memory reference which was not present in the memory, how many times
> an address was involved in a page fault etc.)
>
> 3 > So what "some type of analysis" are you trying to do? What question(s)
> are you trying to answer?
>    Uptill now I want to perform simple analysis mentioned in the above
> question 2. Morevoer, this analysis will provide details about the
> instruction address that is responsible for page fault along with memory
> reference that is no present, the appliction that generated this page
> fault, and for a single address how many times a page fault occured etc.
> By unique and non-unique, I  meant the list of addresses in the log
> without duplication. For example, we have log of addresses
> [1,2,2,3,3,4,3,3,4,4,4,1, 4]. In this list unique addresses are 1,2,3,4,
> and frquency of each address is 2,2, 4,5 respectively.   At this stage I
> want to keep things very simple by ignoring the details like size of the
> RAM, size of kernel, size of loaded modules etc. Briefly I can say I want
> to generate the log for guest physical addresses involved in page fault,
> the corresponding instruction address, coressponsing logical address, along
> with the corresponding application.
>
> At the first stage, I am trying to develope an application that provides
> some basic functionalities (i.e., instruction instrumentation) of Pin Tool
> <https://software.intel.com/sites/landingpage/pintool/docs/71313/Pin/html/index.html#EXAMPLES> for
> just guest physical address by tracing instruction addresses, memory
> referencees, and save it to the file. And the file can not only be
> accessible from within the kernel, but also can be opened using any word
> processing application ,e.g., csv or .txt file.
> Thank you very much for the help.
>
>
> On Wed, 25 Sep 2019 at 03:55, Valdis Klētnieks <valdis.kletnieks@vt.edu>
> wrote:
>
>> On Tue, 24 Sep 2019 20:26:36 +0900, Sahibzada Irfanullah said:
>>
>> > After having a reasonable amount  of log data,
>>
>> If you're trying to figure out how the kernel memory manager is working,
>> you're
>> probably better off using 'perf'  or one of the other tracing tools
>> already in
>> the kernel to track the kernel memory manager. For starters, you can get
>> those
>> tools to give you things like stack tracebacks so you know who is asking
>> for a
>> page, and who is *releasing* a page, and so on.
>>
>> Of course, which of these tools to use depends on what data you need to
>> answer
>> the question - but simply knowing what physical address was involved in a
>> page
>> fault is almost certainly not going to be sufficient.
>>
>> > I want to perform some type of analsys at run time, e.g., no. of unique
>> > addresses, total no. of addresses, frequency of occurences of each
>> addresses
>> > etc.
>>
>> So what "some type of analysis" are you trying to do? What question(s)
>> are you trying to answer?
>>
>> The number of unique physical addresses in your system is dictated by how
>> much
>> RAM you have installed. Similarly for total number of addresses, although
>> I'm
>> not sure why you list both - that would mean that there is some number of
>> non-unique addresses.  What would that even mean?
>>
>> The number of pages actually available for paging and caching depends on
>> other
>> things as well - the architecture of the system, how much RAM (if any) is
>> reserved for use by your video card, the size of the kernel, the size of
>> loaded
>> modules, space taken up by kmalloc allocations, page tables, whether any
>> processes have called mlock() on a large chunk of space, whether the
>> pages are
>> locked by the kernel because there's I/O going on, and then there's
>> things like
>> mmap(), and so on.
>>
>> The kernel provides /proc/meminfo and /proc/slabinfo - you're going to
>> want
>> to understand all that stuff before you can make sense of anything.
>>
>> Simply looking at the frequency of occurrences of each address is
>> probably not
>> going to tell you much of anything, because you need to know things like
>> the total working and resident set sizes for the process and other
>> context.
>>
>> For example - you do the analysis, and find that there are 8 gigabytes of
>> pages
>> that are constantly being re-used.  But that doesn't tell you if there
>> are two
>> processes that are thrashing against each other because each is doing
>> heavy
>> repeated referencing of 6 gigabytes of data, or if one process is wildly
>> referencing
>> many pages because some programmer has a multi-dimensional array and is
>> walking across the array with the indices in the wrong order
>>
>> i_max = 4095; j_max = 4095;
>> for (i = 0, i < i_max; i++) for j = 0, j < j_max; j++) {sum += foo[i][j]}
>>
>> If somebdy is doing foo[j][i] instead, things can get ugly.  And if you're
>> mixing with Fortran code, where the semantics of array references is
>> reverse
>> and you *want* to use 'foo[j][i]' for efficient memory access, it's a
>> bullet loaded
>> in the chamber and waiting for somebody to pull the trigger.
>>
>> Not that I've ever seen *that* particular error happen with a programmer
>> processing 2 terabytes of arrays on a machine that only had 1.5 terabytes
>> of
>> RAM.  But I did tease the person involved about it, because they *really*
>> should have known better. :)
>>
>> So again:  What question(s) are you trying to get answers to?
>>
>>
>
> --
> Regards,
>
> *Mr. Irfanullah*
>
>

-- 
Regards,

*Mr. Irfanullah*

[-- Attachment #1.2: Type: text/html, Size: 8952 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Greg KH]

On Wed, Sep 25, 2019 at 04:00:08PM +0900, Sahibzada Irfanullah wrote:
> I am sorry if I am bothering you.
> I have read this article
> <http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html>,
> I have to ask that will Netlink socket work for my task; Storing the
> contents of "gpa" variable (which is present in the
> handle_ept_violation()functino in vmx.c ) into a file.

Try using ftrace and tracing in general first, before messing around
with netlink.  ftrace does not require any kernel changes at all, why
would you _not_ want to try that?  :)

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Ruben Safir]

On 9/25/19 5:38 AM, Greg KH wrote:
> On Wed, Sep 25, 2019 at 04:00:08PM +0900, Sahibzada Irfanullah wrote:
>> I am sorry if I am bothering you.
>> I have read this article
>> <http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html>,
>> I have to ask that will Netlink socket work for my task; Storing the
>> contents of "gpa" variable (which is present in the
>> handle_ept_violation()functino in vmx.c ) into a file.
> 
> Try using ftrace and tracing in general first, before messing around
> with netlink.  ftrace does not require any kernel changes at all, why
> would you _not_ want to try that?  :)
> 
> thanks,
> 
> greg k-h
> 


The kernel has GPS data in it?


> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 454 bytes --]

On Wed, 25 Sep 2019 11:38:24 +0200, Greg KH said:
> Try using ftrace and tracing in general first, before messing around
> with netlink.  ftrace does not require any kernel changes at all, why
> would you _not_ want to try that?  :)

Beginning programmers write complicated messy code.
Good programmers write clean readable code.
Great programmers avoid writing code in the first place.

Something that many beginners don't seem to have a handle on. :)


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Greg KH]

On Wed, Sep 25, 2019 at 10:21:18AM -0400, Ruben Safir wrote:
> On 9/25/19 5:38 AM, Greg KH wrote:
> > On Wed, Sep 25, 2019 at 04:00:08PM +0900, Sahibzada Irfanullah wrote:
> >> I am sorry if I am bothering you.
> >> I have read this article
> >> <http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html>,
> >> I have to ask that will Netlink socket work for my task; Storing the
> >> contents of "gpa" variable (which is present in the
> >> handle_ept_violation()functino in vmx.c ) into a file.
> > 
> > Try using ftrace and tracing in general first, before messing around
> > with netlink.  ftrace does not require any kernel changes at all, why
> > would you _not_ want to try that?  :)
> 
> The kernel has GPS data in it?

Of course it does, why wouldn't it? :)

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Ruben Safir]

On Wed, Sep 25, 2019 at 07:08:14PM +0200, Greg KH wrote:
> On Wed, Sep 25, 2019 at 10:21:18AM -0400, Ruben Safir wrote:
> > On 9/25/19 5:38 AM, Greg KH wrote:
> > > On Wed, Sep 25, 2019 at 04:00:08PM +0900, Sahibzada Irfanullah wrote:
> > >> I am sorry if I am bothering you.
> > >> I have read this article
> > >> <http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html>,
> > >> I have to ask that will Netlink socket work for my task; Storing the
> > >> contents of "gpa" variable (which is present in the
> > >> handle_ept_violation()functino in vmx.c ) into a file.
> > > 
> > > Try using ftrace and tracing in general first, before messing around
> > > with netlink.  ftrace does not require any kernel changes at all, why
> > > would you _not_ want to try that?  :)
> > 
> > The kernel has GPS data in it?
> 
> Of course it does, why wouldn't it? :)
> 


So when the Nazi's and current Nazi's want to put me in the oven that
they can't track me.

Or put it this way, if it doesn't make the hardware GO, why would it be
in the kernel?

My computer doesn't even have a GPS...and it is going to stay that way.



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Sahibzada Irfanullah]

[-- Attachment #1.1: Type: text/plain, Size: 2237 bytes --]

Thank you very for your help. I have checked the ftrace, and perf. I think
it won't work for me.I am not analyzing/tracing the the kernel. I want to
develop my own dynamic tool like Pin Tool
<https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool>
(or moudule which can be loaded/unloaded at run time dynamically), so that
I can easily tune/modify for different purposes , and to get any type of
specific information from the kernel/KVM, espcecially in the context of
virtualization (guest and/or host memory management). That's why I take a
start from generating the log of guest physical addresses from the kernel
by saving it to the file; with the passage of time, I will add the
funcationalities to it.
Thank you.

On Thu, 26 Sep 2019 at 03:05, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On Wed, Sep 25, 2019 at 07:08:14PM +0200, Greg KH wrote:
> > On Wed, Sep 25, 2019 at 10:21:18AM -0400, Ruben Safir wrote:
> > > On 9/25/19 5:38 AM, Greg KH wrote:
> > > > On Wed, Sep 25, 2019 at 04:00:08PM +0900, Sahibzada Irfanullah wrote:
> > > >> I am sorry if I am bothering you.
> > > >> I have read this article
> > > >> <
> http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html
> >,
> > > >> I have to ask that will Netlink socket work for my task; Storing the
> > > >> contents of "gpa" variable (which is present in the
> > > >> handle_ept_violation()functino in vmx.c ) into a file.
> > > >
> > > > Try using ftrace and tracing in general first, before messing around
> > > > with netlink.  ftrace does not require any kernel changes at all, why
> > > > would you _not_ want to try that?  :)
> > >
> > > The kernel has GPS data in it?
> >
> > Of course it does, why wouldn't it? :)
> >
>
>
> So when the Nazi's and current Nazi's want to put me in the oven that
> they can't track me.
>
> Or put it this way, if it doesn't make the hardware GO, why would it be
> in the kernel?
>
> My computer doesn't even have a GPS...and it is going to stay that way.
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
Regards,

*Mr. Irfanullah*

[-- Attachment #1.2: Type: text/html, Size: 3676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Brock]

On Thu, 2019-09-26 at 15:45 +0900, Sahibzada Irfanullah wrote:
> Thank you very for your help. I have checked the ftrace, and perf. I
> think it won't work for me.I am not analyzing/tracing the the kernel.
> I want to develop my own dynamic tool like Pin Tool  (or moudule
> which can be loaded/unloaded at run time dynamically), so that I can
> easily tune/modify for different purposes , and to get any type of
> specific information from the kernel/KVM, espcecially in the context
> of virtualization (guest and/or host memory management). That's why I
> take a start from generating the log of guest physical addresses from
> the kernel by saving it to the file; with the passage of time, I will
> add the funcationalities to it.
> Thank you.  
I'm not sure if it's hardware addresses but you can get kernel/user/kvm
page fault information with:
perf record -a -e kvm:kvm_page_fault -e exceptions:page_fault_kernel -e
exceptions:page_fault_user -- sleep 30

An example output from my machine running an Ubuntu 18.04 guest:
kvm:kvm_page_fault:
   0.72%  address 40d26a78 error_code 181
   0.54%  address 46a09d00 error_code 181
   0.36%  address 2b10ef08 error_code 181
   0.36%  address 4a361000 error_code 181
   0.36%  address 4b0a2000 error_code 181
   ...<snipped>
exceptions:page_fault_kernel
   1.20%  address=0x17d0b30fe000s ip=filldir64 error_code=0x2
   1.20%  address=0x17d0b30ff000s ip=filldir64 error_code=0x2
   1.20%  address=0x17d0b3100000s ip=filldir64 error_code=0x2
   0.40%  address=0x55ac27551b46s ip=do_sys_poll error_code=0x2
   0.20%  address=0x55ac27de2000s ip=copy_user_generic_string
error_code=0x0
   0.20%  address=0x55ac27de3000s ip=copy_user_generic_string
error_code=0x0
   ...<snipped>
exceptions:page_fault_user
   0.12%  address=0xf8553529000s ip=0x7f7dc0d3c5dcs error_code=0x6
   0.12%  address=0xf855352a000s ip=0x7f7dc0d3c617s error_code=0x6
   0.12%  address=0xf855352b000s ip=0x7f7dc0d3c617s error_code=0x6
   0.12%  address=0xf855352c000s ip=0x7f7dc0d3c617s error_code=0x6
   0.12%  address=0xf855352d000s ip=0x7f7dc0d3c617s error_code=0x6
   ...<snipped>

The number (0.12%) at the start is how many times the address was seen
in the total number of samples in this case pagefaults that hit that
address I would guess.

You can find events you're interested in with `perf list` or
`cat /sys/kernel/debug/tracing/available_events`

Seems like you really want to develop your own module though but this
may still help see if there is existing kernel infrastructure you can
leverage.

Regards Brock.

> On Thu, 26 Sep 2019 at 03:05, Ruben Safir <ruben@mrbrklyn.com> wrote:
> > On Wed, Sep 25, 2019 at 07:08:14PM +0200, Greg KH wrote:
> > > On Wed, Sep 25, 2019 at 10:21:18AM -0400, Ruben Safir wrote:
> > > > On 9/25/19 5:38 AM, Greg KH wrote:
> > > > > On Wed, Sep 25, 2019 at 04:00:08PM +0900, Sahibzada
> > Irfanullah wrote:
> > > > >> I am sorry if I am bothering you.
> > > > >> I have read this article
> > > > >> <
> > http://amsekharkernel.blogspot.com/2012/01/what-are-ways-of-communication-bw-user.html>
> > ;,
> > > > >> I have to ask that will Netlink socket work for my task;
> > Storing the
> > > > >> contents of "gpa" variable (which is present in the
> > > > >> handle_ept_violation()functino in vmx.c ) into a file.
> > > > > 
> > > > > Try using ftrace and tracing in general first, before messing
> > around
> > > > > with netlink.  ftrace does not require any kernel changes at
> > all, why
> > > > > would you _not_ want to try that?  :)
> > > > 
> > > > The kernel has GPS data in it?
> > > 
> > > Of course it does, why wouldn't it? :)
> > > 
> > 
> > 
> > So when the Nazi's and current Nazi's want to put me in the oven
> > that
> > they can't track me.
> > 
> > Or put it this way, if it doesn't make the hardware GO, why would
> > it be
> > in the kernel?
> > 
> > My computer doesn't even have a GPS...and it is going to stay that
> > way.
> > 
> > 
> > 
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> 


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1277 bytes --]

On Thu, 26 Sep 2019 20:05:57 +1000, Brock said:
> On Thu, 2019-09-26 at 15:45 +0900, Sahibzada Irfanullah wrote:
> > Thank you very for your help. I have checked the ftrace, and perf. I
> > think it won't work for me.I am not analyzing/tracing the the kernel.
> > I want to develop my own dynamic tool like Pin Tool  (or moudule
> > which can be loaded/unloaded at run time dynamically), so that I can
> > easily tune/modify for different purposes , and to get any type of
> > specific information from the kernel/KVM, espcecially in the context
> > of virtualization (guest and/or host memory management). That's why I
> > take a start from generating the log of guest physical addresses from
> > the kernel by saving it to the file; with the passage of time, I will
> > add the funcationalities to it.
> > Thank you.
> I'm not sure if it's hardware addresses but you can get kernel/user/kvm
> page fault information with:

I admit I'm still mystified by the requirement for the hardware address rather than
the virtual address, when doing any sort of analytics is going to require mapping
back to a process and virtual address - and possibly incorrectly (consider a page fault
from an instruction in a shared library that's mmap'ed into 250 running processes, like
glibc...)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies