Kernel Newbies archive on lore.kernel.org
 help / color / Atom feed
* Virtual To Physical Address Translation
@ 2019-05-14 12:20 Aruna Hewapathirane
  2019-05-15  9:33 ` Amit Kumar
  0 siblings, 1 reply; 3+ messages in thread
From: Aruna Hewapathirane @ 2019-05-14 12:20 UTC (permalink / raw)
  To: kernelnewbies

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

Hi,

I am trying to wrap my head around the virtual to physical memory address
translation. For example let's say I want to locate the sys_call_table.

objdump and vmlinux shows me this:
aruna@debian:~/linux-5.1.1$ objdump -t vmlinux | grep -i sys_call_table
ffffffff81c001c0 g     O .rodata    0000000000001120 sys_call_table
ffffffff81c01600 g     O .rodata    0000000000000d60 ia32_sys_call_table

and System.map shows me this:
aruna@debian:~/linux-5.1.1$ cat System.map | grep -i sys_call_table
ffffffff81c001c0 R sys_call_table
ffffffff81c01600 R ia32_sys_call_table

So addresses match.

And gdb shows me this:
aruna@debian:~/linux-5.1.1$ gdb vmlinux
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Reading symbols from vmlinux...done.

(gdb) p sys_call_table
$1 = {0xffffffff812317a0 <__x64_sys_read>,
  0xffffffff812318b0 <__x64_sys_write>, 0xffffffff8122d980
<__x64_sys_open>,
  0xffffffff8122bc40 <__x64_sys_close>,
  0xffffffff81236220 <__x64_sys_newstat>,
  0xffffffff812363e0 <__x64_sys_newfstat>,
  <snip>

Now if you take the address given by objdump and System.map which is
0xffffffff81c001c0
and ask gdb to show you I get:

(gdb) x 0xffffffff81c001c0
0xffffffff81c001c0 <sys_call_table>:    0x812317a0

My question is HOW is the address 0xffffffff81c001c0 translated to
0x812317a0 ? I am reading up on page tables and page offsets just can't yet
fully understand how it is done. A example that
breaks down the process step by step would really help.

Thanks - Aruna

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

<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi,</div><div><br></div><div>I am trying to wrap my head around the virtual to physical memory address translation. For example let&#39;s say I want to locate the sys_call_table.<br></div><div><br></div><div>objdump and vmlinux shows me this:</div><div>aruna@debian:~/linux-5.1.1$ objdump -t vmlinux | grep -i sys_call_table<br>ffffffff81c001c0 g     O .rodata    0000000000001120 sys_call_table<br>ffffffff81c01600 g     O .rodata    0000000000000d60 ia32_sys_call_table<br></div><div><br></div><div>and System.map shows me this:</div><div>aruna@debian:~/linux-5.1.1$ cat System.map | grep -i sys_call_table<br>ffffffff81c001c0 R sys_call_table<br>ffffffff81c01600 R ia32_sys_call_table<br></div><div><br></div><div>So addresses match.<br></div><div><br></div><div>And gdb shows me this:</div><div>aruna@debian:~/linux-5.1.1$ gdb vmlinux<br>GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1<br>Reading symbols from vmlinux...done.</div><div><br></div><div>(gdb) p sys_call_table<br>$1 = {0xffffffff812317a0 &lt;__x64_sys_read&gt;, <br>  0xffffffff812318b0 &lt;__x64_sys_write&gt;, 0xffffffff8122d980 &lt;__x64_sys_open&gt;, <br>  0xffffffff8122bc40 &lt;__x64_sys_close&gt;, <br>  0xffffffff81236220 &lt;__x64_sys_newstat&gt;, <br>  0xffffffff812363e0 &lt;__x64_sys_newfstat&gt;, <br></div><div>  &lt;snip&gt;<br></div><div><br></div><div>Now if you take the address given by objdump and System.map which is 0xffffffff81c001c0</div><div>and ask gdb to show you I get:<br></div><div><br></div><div>(gdb) x 0xffffffff81c001c0<br>0xffffffff81c001c0 &lt;sys_call_table&gt;:    0x812317a0</div><div><br></div><div>My question is HOW is the address 0xffffffff81c001c0 translated to 0x812317a0 ? I am reading up on page tables and page offsets just can&#39;t yet fully understand how it is done. A example that <br></div><div>breaks down the process step by step would really help. <br></div><div><br></div><div>Thanks - Aruna<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div>

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

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Virtual To Physical Address Translation
  2019-05-14 12:20 Virtual To Physical Address Translation Aruna Hewapathirane
@ 2019-05-15  9:33 ` Amit Kumar
  2019-05-15  9:39   ` Amit Kumar
  0 siblings, 1 reply; 3+ messages in thread
From: Amit Kumar @ 2019-05-15  9:33 UTC (permalink / raw)
  To: Aruna Hewapathirane; +Cc: kernelnewbies

On Tue, May 14, 2019 at 5:52 PM Aruna Hewapathirane
<aruna.hewapathirane@gmail.com> wrote:
>
> Hi,
>
> I am trying to wrap my head around the virtual to physical memory address translation. For example let's say I want to locate the sys_call_table.
>
> objdump and vmlinux shows me this:
> aruna@debian:~/linux-5.1.1$ objdump -t vmlinux | grep -i sys_call_table
> ffffffff81c001c0 g     O .rodata    0000000000001120 sys_call_table
> ffffffff81c01600 g     O .rodata    0000000000000d60 ia32_sys_call_table
>
> and System.map shows me this:
> aruna@debian:~/linux-5.1.1$ cat System.map | grep -i sys_call_table
> ffffffff81c001c0 R sys_call_table
> ffffffff81c01600 R ia32_sys_call_table
>
> So addresses match.
>
> And gdb shows me this:
> aruna@debian:~/linux-5.1.1$ gdb vmlinux
> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
> Reading symbols from vmlinux...done.
>
> (gdb) p sys_call_table
> $1 = {0xffffffff812317a0 <__x64_sys_read>,
>   0xffffffff812318b0 <__x64_sys_write>, 0xffffffff8122d980 <__x64_sys_open>,
>   0xffffffff8122bc40 <__x64_sys_close>,
>   0xffffffff81236220 <__x64_sys_newstat>,
>   0xffffffff812363e0 <__x64_sys_newfstat>,
>   <snip>
>
> Now if you take the address given by objdump and System.map which is 0xffffffff81c001c0
> and ask gdb to show you I get:
>
> (gdb) x 0xffffffff81c001c0
> 0xffffffff81c001c0 <sys_call_table>:    0x812317a0
>
> My question is HOW is the address 0xffffffff81c001c0 translated to 0x812317a0 ?
At the moment I am unable to provide you a pointer, but I have read
somewhere that kernel uses random
numbers to relocate addresses for the sake of cracking.

I am reading up on page tables and page offsets just can't yet fully
understand how it is done. A example that
> breaks down the process step by step would really help.
>
> Thanks - Aruna
>
Regards,
Amit Kumar
>
>
>
> _______________________________________________
> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Virtual To Physical Address Translation
  2019-05-15  9:33 ` Amit Kumar
@ 2019-05-15  9:39   ` Amit Kumar
  0 siblings, 0 replies; 3+ messages in thread
From: Amit Kumar @ 2019-05-15  9:39 UTC (permalink / raw)
  To: Aruna Hewapathirane; +Cc: kernelnewbies

On Wed, May 15, 2019 at 3:03 PM Amit Kumar <free.amit.kumar@gmail.com> wrote:
>
> On Tue, May 14, 2019 at 5:52 PM Aruna Hewapathirane
> <aruna.hewapathirane@gmail.com> wrote:
> >
> > Hi,
> >
> > I am trying to wrap my head around the virtual to physical memory address translation. For example let's say I want to locate the sys_call_table.
> >
> > objdump and vmlinux shows me this:
> > aruna@debian:~/linux-5.1.1$ objdump -t vmlinux | grep -i sys_call_table
> > ffffffff81c001c0 g     O .rodata    0000000000001120 sys_call_table
> > ffffffff81c01600 g     O .rodata    0000000000000d60 ia32_sys_call_table
> >
> > and System.map shows me this:
> > aruna@debian:~/linux-5.1.1$ cat System.map | grep -i sys_call_table
> > ffffffff81c001c0 R sys_call_table
> > ffffffff81c01600 R ia32_sys_call_table
> >
> > So addresses match.
> >
> > And gdb shows me this:
> > aruna@debian:~/linux-5.1.1$ gdb vmlinux
> > GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
> > Reading symbols from vmlinux...done.
> >
> > (gdb) p sys_call_table
> > $1 = {0xffffffff812317a0 <__x64_sys_read>,
> >   0xffffffff812318b0 <__x64_sys_write>, 0xffffffff8122d980 <__x64_sys_open>,
> >   0xffffffff8122bc40 <__x64_sys_close>,
> >   0xffffffff81236220 <__x64_sys_newstat>,
> >   0xffffffff812363e0 <__x64_sys_newfstat>,
> >   <snip>
> >
> > Now if you take the address given by objdump and System.map which is 0xffffffff81c001c0
> > and ask gdb to show you I get:
> >
> > (gdb) x 0xffffffff81c001c0
> > 0xffffffff81c001c0 <sys_call_table>:    0x812317a0
> >
> > My question is HOW is the address 0xffffffff81c001c0 translated to 0x812317a0 ?
> At the moment I am unable to provide you a pointer, but I have read
> somewhere that kernel uses random
> numbers to relocate addresses for the sake of cracking.
https://lwn.net/Articles/569635/
> I am reading up on page tables and page offsets just can't yet fully
> understand how it is done. A example that
> > breaks down the process step by step would really help.
> >
> > Thanks - Aruna
> >
> Regards,
> Amit Kumar
> >
> >
> >
> > _______________________________________________
> > 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-14 12:20 Virtual To Physical Address Translation Aruna Hewapathirane
2019-05-15  9:33 ` Amit Kumar
2019-05-15  9:39   ` Amit Kumar

Kernel Newbies archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org kernelnewbies@archiver.kernel.org
	public-inbox-index kernelnewbies


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/ public-inbox