* 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 --]
[-- 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, other threads:[~2019-05-15 9:41 UTC | newest]
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).