Re:Re: Will kernel in-place decompression overwrite uncompressed part ?

[Jacky]

According arch/x86/boot/compressed/head_32.S and some comments:

==
/*
 * Copy the compressed kernel to the end of our buffer
 * where decompression in place becomes safe.
 */
pushl   %esi
leal(_bss-4)(%ebp), %esi
...
/*
 * Jump to the relocated address.
 */
lealrelocated(%ebx), %eax
jmp *%eax
ENDPROC(startup_32)

.text
relocated:
...
==

We can see the kernel moves itself, including both compressed and uncompressed 
to the new location,  and after finish moving, kernel also jump to the new 
location.

And the below code in this file, uncompressed part will decompress compressed 
part in-place, so it seems that uncompressed part is overwritten ... 

At 2013-03-09 11:12:26,"leo kirotawa"  wrote:
I don't know if it can help you, but let's try. [1]
What I understand about that is. The compressed kernel is in fact a bzImage or 
some zImage kernel, and it is a file. As the link says in that compressed file 
we have this header that makes some early configurations. The kernel is 
uncompressed into the memory and the compressed kernel remains in the place it 
was before. Just what matter by the compressed kernel is that header info that 
it use to setup the stack to the new kernel.


I'm no sure if I'm talking some nosense, but that was what I saw in kernel boot 
files. Maybe some others mate here can complement or fix my thoughts here.




[1] http://www.ibm.com/developerworks/library/l-linuxboot/


On Fri, Mar 8, 2013 at 10:12 PM, Jacky  wrote:

 
Dear All,

Before, kernel first decompressed to other memory location and then merged and 
put at final destination. Now, kernel decompression  are decompressed in-place, 
so-called in-place decompression.

But the compressed part is encompassed by uncompressed part. So, after 
decompression, will the uncompressed part be overwritten by the decompressed 
kernel ? If so, some uncompressed part such as deal with kernel relocation will 
be overwritten by the decompressed kernel, which don't make sense, am I missed 
something ?

Regards,
Jacky






___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies







--
Leônidas S. Barbosa (Kirotawa)

Engenheiro de Software - IBM (LTC - Linux Technology Center)
MsC Sistemas e Computação
Bacharel em Ciências da Computação.

blog nerd: corecode.wordpress.com/


User linux : #480879


"Mais sábio é aquele que sabe que não sabe" (Sócrates)
"smile and wave" - =D + o/ (Penguins of Madagascar)


日本語の学生です。
コンピュータサイエンスの学位.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Will kernel in-place decompression overwrite uncompressed part ?

[leo kirotawa]

I don't know if it can help you, but let's try. [1]
What I understand about that is. The compressed kernel is in fact a bzImage
or some zImage kernel, and it is a file. As the link says in that
compressed file we have this header that makes some early configurations.
The kernel is uncompressed into the memory and the compressed kernel
remains in the place it was before. Just what matter by the compressed
kernel is that header info that it use to setup the stack to the new kernel.

I'm no sure if I'm talking some nosense, but that was what I saw in kernel
boot files. Maybe some others mate here can complement or fix my thoughts
here.


[1] http://www.ibm.com/developerworks/library/l-linuxboot/

On Fri, Mar 8, 2013 at 10:12 PM, Jacky  wrote:

>
> Dear All,
>
> Before, kernel first decompressed to other memory location and then merged
> and put at final destination. Now, kernel decompression  are decompressed
> in-place, so-called in-place decompression.
>
> But the compressed part is encompassed by uncompressed part. So, after
> decompression, will the uncompressed part be overwritten by the
> decompressed kernel ? If so, some uncompressed part such as deal with
> kernel relocation will be overwritten by the decompressed kernel, which
> don't make sense, am I missed something ?
>
> Regards,
> Jacky
>
>
>
>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
Leônidas S. Barbosa (Kirotawa)

Engenheiro de Software - IBM (LTC - Linux Technology Center)
MsC Sistemas e Computação
Bacharel em Ciências da Computação.

blog nerd: corecode.wordpress.com/

User linux : #480879

"Mais sábio é aquele que sabe que não sabe" (Sócrates)
"smile and wave" - =D + o/ (Penguins of Madagascar)

日本語の学生です。
コンピュータサイエンスの学位.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Will kernel in-place decompression overwrite uncompressed part ?

[Jacky]

 
Dear All,

Before, kernel first decompressed to other memory location and then merged and 
put at final destination. Now, kernel decompression  are decompressed in-place, 
so-called in-place decompression.

But the compressed part is encompassed by uncompressed part. So, after 
decompression, will the uncompressed part be overwritten by the decompressed 
kernel ? If so, some uncompressed part such as deal with kernel relocation will 
be overwritten by the decompressed kernel, which don't make sense, am I missed 
something ?

Regards,
Jacky


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re:Re: Re: What is the memory region ?

[baisheng_wang]

Thanks, Prabhunath!

Great detail, very helpful!

Regards,
Jacky

在 2013-03-08 15:37:27，"Prabhu nath"  写道：







On Thu, Mar 7, 2013 at 7:38 PM, Jacky  wrote:


Thanks Prabhunath!

The following is section header table:
==
 readelf -S /bin/cat

There are 28 section headers, starting at offset 0xb260:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .interp   PROGBITS08048154 000154 13 00   A  0   0  1
  [ 2] .note.ABI-tag NOTE08048168 000168 20 00   A  0   0  4
  [ 3] .note.gnu.build-i NOTE08048188 000188 24 00   A  0   0  4
  [ 4] .gnu.hash GNU_HASH080481ac 0001ac 44 04   A  5   0  4
  [ 5] .dynsym   DYNSYM  080481f0 0001f0 0004e0 10   A  6   1  4
  [ 6] .dynstr   STRTAB  080486d0 0006d0 000349 00   A  0   0  1
  [ 7] .gnu.version  VERSYM  08048a1a 000a1a 9c 02   A  5   0  2
  [ 8] .gnu.version_rVERNEED 08048ab8 000ab8 90 00   A  6   1  4
  [ 9] .rel.dyn  REL 08048b48 000b48 30 08   A  5   0  4
  [10] .rel.plt  REL 08048b78 000b78 000228 08   A  5  12  4
  [11] .init PROGBITS08048da0 000da0 24 00  AX  0   0  4
  [12] .plt  PROGBITS08048dd0 000dd0 000460 04  AX  0   0 16
  [13] .text PROGBITS08049230 001230 006f2c 00  AX  0   0 16
  [14] .fini PROGBITS0805015c 00815c 15 00  AX  0   0  4
  [15] .rodata   PROGBITS08050180 008180 000e86 00   A  0   0 32
  [16] .eh_frame_hdr PROGBITS08051008 009008 0002d4 00   A  0   0  4
  [17] .eh_frame PROGBITS080512dc 0092dc 000d30 00   A  0   0  4
  [18] .init_array   INIT_ARRAY  08053f04 00af04 04 00  WA  0   0  4
  [19] .fini_array   FINI_ARRAY  08053f08 00af08 04 00  WA  0   0  4
  [20] .jcr  PROGBITS08053f0c 00af0c 04 00  WA  0   0  4
  [21] .dynamic  DYNAMIC 08053f10 00af10 e8 08  WA  6   0  4
  [22] .got  PROGBITS08053ff8 00aff8 08 04  WA  0   0  4
  [23] .got.plt  PROGBITS08054000 00b000 000120 04  WA  0   0  4
  [24] .data PROGBITS08054120 00b120 3c 00  WA  0   0  4
  [25] .bss  NOBITS  08054160 00b15c 0005c4 00  WA  0   0 32
  [26] .gnu_debuglinkPROGBITS 00b15c 08 00  0   0  1
  [27] .shstrtab STRTAB   00b164 fc 00  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)
==

But, according the kernel elf loader :

linux-3.7.4/fs/binfmt_elf.c:
static int load_elf_binary(...)
{
...
for(i = 0, elf_ppnt = elf_phdata;
i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
...
if (elf_ppnt->p_type != PT_LOAD)
continue;
...
}

The kernel elf loader just load PT_LOAD segment, but GNU_RELRO is not PT_LOAD 
type ?


   GNU_RELRO is a subset of PT_LOAD 2 i.e. 2nd Loadable segment. This type of 
adjustment I had seen in WindRiver distribution of Linux. This is actually made 
to avoid unnecessary application crash (segmentation faults) which I will 
explain later.

First Let us look at Section to Segment mapping.
Sections 1 to 17 which have access permissions AX are mapped to 1st Loadable 
segment (Code)
Sections 18 to 26 which have access permissions WA are mapped to 2nd Loadable 
segment (Data)
Of these Section 18 to 22 are also mapped to GNU_RELRO.

When an application is initiated for execution sections 18 to 22 will be 
accessed by the dynamic linker to edit few locations  . Since dynamic linker 
code also will be mapped to the virtual address space of the application (see 
/proc/self/maps), virtual address associated to sections 18 to 22 should have 
write permissions for the dynamic linker to write into those sections.

And the application's code has explicitly nothing to do with the sections 18 to 
22, though the execution control passes through these sections without the 
knowledge of the application programmer.

Thus once the dynamic linker finishes its job, this trick is done to split the 
virtual address region 08053000-08055000 to
08053000-08054000 r--p a000 08:01 261656 /bin/cat
08054000-08055000 rw-p b000 08:01 261656 /bin/cat

If you carefully observe, section 23 (.got.plt) is still part of the virtual 
address region 08054000-08055000, even though the application code has nothing 
to do with this section explicitly. This is because of lazy binding adopted by 
dynamic linker. The dynamic linker will put its hand on to this sec

Why FIB_TABLE_HASHSZ=2 when CONFIG_IP_ROUTE_MULTIPATH

[tingwei liu]

Hi, all

   who can tell me why? I think is should be 256 also.


#ifdef CONFIG_IP_ROUTE_MULTIPATH

#define FIB_RES_NH(res) ((res).fi->fib_nh[(res).nh_sel])

#define FIB_TABLE_HASHSZ 2

#else /* CONFIG_IP_ROUTE_MULTIPATH */

#define FIB_RES_NH(res) ((res).fi->fib_nh[0])

#define FIB_TABLE_HASHSZ 256

#endif /* CONFIG_IP_ROUTE_MULTIPATH */

Thanks

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies