Questions about Kernel Memory that I didn't find answers in Google - Please Help
Peter Teoh
htmldeveloper at gmail.com
Sun Aug 3 19:58:22 EDT 2014
I like your curiosities and interests in Linux kernel.
http://virtuallyhyper.com/2013/07/rhcsa-and-rhce-chapter-10-the-kernel/
Instead of answering one by one, I think I will just identify the knowledge
you are lacking:
Memory management (from both x86/intel and linux kernel perspective).
There are many many resources out there for you in these area, eg:
http://en.wikipedia.org/wiki/Page_table
http://en.wikipedia.org/wiki/X86-64
(both boring, but just understand it well enough)
http://wiki.osdev.org/Paging (good explanation....understand it very very
well).
The ultimate classic ebook:
https://www.kernel.org/doc/gorman/pdf/understand.pdf
And this blog site has tons of good info on intel/memory etc:
http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection/
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/
http://virtuallyhyper.com/2013/07/rhcsa-and-rhce-chapter-10-the-kernel/
http://www.cse.psu.edu/~anand/spring01/linux/memory.ppt
One more thing:
"readelf -S -W vmlinux" shows u the sections and the address where the
different sections are supposed to be loaded in memory. If u replace the
vmlinux with the kernel module, eg: ip_tables.ko, then it says:
starting at offset 0x328c blah blah....
so the loaded address is with respect to ZERO, but then the actual module
address is:
sudo cat /proc/modules |grep ip_table
ip_tables 18106 1 iptable_filter, Live 0xf8bf5000
So all the output from your readelf, just add 0xf8bf5000 to it and you will
get the actual virtual address of that section IN MEMORY.
Just only in memory. In file, the file offset of the section is
different. And many parts inside the ELF is also different from memory
too: you will need to add the virtual load address (above) to the offset
as specified inside the relocation tables (objdump -r), and for each
section there is a separate relocation table (all independent from another,
meaning that the different section CAN BE loaded to different parts in
memory).
Thanks.
On Sun, Aug 3, 2014 at 11:59 PM, Lucas Tanure <tanure at linux.com> wrote:
> Hi,
>
> I'm looking for some site, pdf, book etc, that can answer this questions.
> For now I have :
>
> http://unix.stackexchange.com/questions/5124/what-does-the-virtual-kernel-memory-layout-in-dmesg-imply
>
>
> I want to understand a few things about the memory and the execution
> of Linux kernel.
> Taking from a X86 and grub I have:
>
> 1) Grub loads kernel and root file system in memory, and the vmlinux
> has the code to decompress it self, right ? linux
>
> 2) The address of load kernel is always the same ? And It's at
> compilation time that is chosen ?
>
> 2a) The kernel takes places in 3g-4g memory place, and user space from 0
> to 3gb.
> But if the pc has only 256mb of memory ?
> And when pc has 16gb of memory, the user space will be split in two ?
>
> 2b) And if kernel has soo many modules that needs more than 1gb to run ?
>
> 2c) How we configure all of that memory configs ? make menuconfig and
> friends ?
>
> 3) The function A will call functon B. B is at 0xGGGGGG in .text
> section, but kernel was loaded in address 0xJJJJJJJJJJ, how A will
> find B ?
>
> 4) Please consider this:
> $ readelf -S -W vmlinux
> There are 37 section headers, starting at offset 0xe05718:
>
> Section Headers:
> [Nr] Name Type Address
> Off Size ES Flg Lk Inf Al
> [ 0] NULL
> 0000000000000000 000000 000000 00 0 0 0
> [ 1] .text PROGBITS
> ffffffff81000000 200000 53129a 00 AX 0 0 4096
> [ 2] .notes NOTE
> ffffffff8153129c 73129c 0001d8 00 AX 0 0 4
> [ 3] __ex_table PROGBITS ffffffff81531480
> 731480 002018 00 A 0 0 8
> [ 4] .rodata PROGBITS
> ffffffff81600000 800000 1655ee 00 A 0 0 64
> [ 5] __bug_table PROGBITS ffffffff817655f0
> 9655f0 005424 00 A 0 0 1
> [ 6] .pci_fixup PROGBITS ffffffff8176aa18
> 96aa18 002f88 00 A 0 0 8
> [ 7] .tracedata PROGBITS ffffffff8176d9a0
> 96d9a0 00003c 00 A 0 0 1
> [ 8] __ksymtab PROGBITS ffffffff8176d9e0
> 96d9e0 00e710 00 A 0 0 16
> [ 9] __ksymtab_gpl PROGBITS ffffffff8177c0f0
> 97c0f0 00a150 00 A 0 0 16
> [10] __kcrctab PROGBITS ffffffff81786240
> 986240 007388 00 A 0 0 8
> [11] __kcrctab_gpl PROGBITS ffffffff8178d5c8
> 98d5c8 0050a8 00 A 0 0 8
> [12] __ksymtab_strings PROGBITS ffffffff81792670
> 992670 01cb42 00 A 0 0 1
> [13] __init_rodata PROGBITS ffffffff817af1c0
> 9af1c0 0000e8 00 A 0 0 32
> [14] __param PROGBITS ffffffff817af2a8
> 9af2a8 000b00 00 A 0 0 8
> [15] __modver PROGBITS ffffffff817afda8
> 9afda8 000258 00 A 0 0 8
> [16] .data PROGBITS
> ffffffff81800000 a00000 0e1180 00 WA 0 0 4096
> [17] .vvar PROGBITS
> ffffffff818e2000 ae2000 001000 00 WA 0 0 16
> [18] .data..percpu PROGBITS 0000000000000000
> c00000 015300 00 WA 0 0 4096
> [19] .init.text PROGBITS
> ffffffff818f9000 cf9000 0503ea 00 AX 0 0 16
> [20] .init.data PROGBITS
> ffffffff8194a000 d4a000 09e4c8 00 WA 0 0 4096
> [21] .x86_cpu_dev.init PROGBITS ffffffff819e84c8
> de84c8 000018 00 A 0 0 8
> [22] .parainstructions PROGBITS ffffffff819e84e0
> de84e0 00bd3c 00 A 0 0 8
> [23] .altinstructions PROGBITS ffffffff819f4220
> df4220 005f40 00 A 0 0 1
> [24] .altinstr_replacement PROGBITS ffffffff819fa160
> dfa160 001a69 00 AX 0 0 1
> [25] .iommu_table PROGBITS ffffffff819fbbd0
> dfbbd0 0000f0 00 A 0 0 8
> [26] .apicdrivers PROGBITS ffffffff819fbcc0
> dfbcc0 000020 00 WA 0 0 8
> [27] .exit.text PROGBITS ffffffff819fbce0
> dfbce0 0009bc 00 AX 0 0 1
> [28] .smp_locks PROGBITS ffffffff819fd000
> dfd000 005000 00 A 0 0 4
> [29] .data_nosave PROGBITS ffffffff81a02000
> e02000 001000 00 WA 0 0 4
> [30] .bss NOBITS
> ffffffff81a03000 e03000 122000 00 WA 0 0 4096
> [31] .brk NOBITS
> ffffffff81b25000 e03000 425000 00 WA 0 0 1
> [32] .comment PROGBITS 0000000000000000
> e03000 000027 01 MS 0 0 1
> [33] .debug_frame PROGBITS 0000000000000000
> e03028 002560 00 0 0 8
> [34] .shstrtab STRTAB
> 0000000000000000 e05588 00018a 00 0 0 1
> [35] .symtab SYMTAB 0000000000000000
> e06058 1a29f8 18 36 43659 8
> [36] .strtab STRTAB
> 0000000000000000 fa8a50 180d92 00 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
> So the vmlinux is loaded in memory like a dd ?
>
> 5) In my function A, inside the module that I wrote, a non-initialized
> variable will take place in non-initialized section that was loaded in
> memory ?
> Or my modules has a new sections for it's own use, and my module is
> loaded my memory like a process, with all his sections?
> So how another module or kernel code will fin my exported
> variable/function ?
>
>
> 6) Let's suppose:
> I have a int variable, with 17 as content, and the address is 0xGGGGGG.
> If I stop the linux in this time, read my memory at address 0xGGGGGG I
> will got 17, right ?
> 0xGGGGGGG will be bigger than 0xc0000000 always, right ?
>
>
> 7) Now take int from question and change for:
> struct mystruct * foo = (struct mystruct* ) kmalloc(sizeof(struct
> mystruct));
>
> I will be able to read at address 0xGGGGGG the struct that created,
> and it address will be greater than 0xc0000000, right ?
> But for this struct, the memory will be allocated for ever, until I
> free the pointer, right ?
>
>
>
> Well, this just a start. I really want to understand how kernel is
> run, loaded etc. Any help is appreciate, answering my questions, links
> to read, books to read.
> Actually, I didn't find any book with that kind of information .
>
>
> --
> Lucas Tanure
> +55 (19) 988176559
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont at kvack.org"> email at kvack.org </a>
>
--
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140804/9eee0aaf/attachment.html
More information about the Kernelnewbies
mailing list