<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><br>Thanks, Prabhunath!<br><br>Great detail, very helpful!<br><br>Regards,<br>Jacky<br><br>ÔÚ 2013-03-08 15:37:27£¬"Prabhu&nbsp;nath"&nbsp;&lt;gprabhunath@gmail.com&gt; Ð´µÀ£º<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br clear="all"><div><br></div>
<br><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 7:38 PM, Jacky <span dir="ltr">&lt;<a href="mailto:jackyclivia@163.com" target="_blank">jackyclivia@163.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="line-height:1.7;font-size:14px;font-family:arial"><br>Thanks Prabhunath!<br><br>The following is section header table:<br>==============================<br>&nbsp;readelf -S /bin/cat <br><br>There are 28 section headers, starting at offset 0xb260:<br>
<br>Section Headers:<br>&nbsp; [Nr] Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Addr&nbsp;&nbsp;&nbsp;&nbsp; Off&nbsp;&nbsp;&nbsp; Size&nbsp;&nbsp; ES Flg Lk Inf Al<br>&nbsp; [ 0]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NULL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000000 000000 000000 00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 0&nbsp; 0<br>&nbsp; [ 1] .interp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048154 000154 000013 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0&nbsp; 1<br>
&nbsp; [ 2] .note.ABI-tag&nbsp;&nbsp;&nbsp;&nbsp; NOTE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048168 000168 000020 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [ 3] .note.gnu.build-i NOTE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048188 000188 000024 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [ 4] .gnu.hash&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GNU_HASH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 080481ac 0001ac 000044 04&nbsp;&nbsp; A&nbsp; 5&nbsp;&nbsp; 0&nbsp; 4<br>
&nbsp; [ 5] .dynsym&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DYNSYM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 080481f0 0001f0 0004e0 10&nbsp;&nbsp; A&nbsp; 6&nbsp;&nbsp; 1&nbsp; 4<br>&nbsp; [ 6] .dynstr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STRTAB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 080486d0 0006d0 000349 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0&nbsp; 1<br>&nbsp; [ 7] .gnu.version&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VERSYM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048a1a 000a1a 00009c 02&nbsp;&nbsp; A&nbsp; 5&nbsp;&nbsp; 0&nbsp; 2<br>
&nbsp; [ 8] .gnu.version_r&nbsp;&nbsp;&nbsp; VERNEED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048ab8 000ab8 000090 00&nbsp;&nbsp; A&nbsp; 6&nbsp;&nbsp; 1&nbsp; 4<br>&nbsp; [ 9] .rel.dyn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048b48 000b48 000030 08&nbsp;&nbsp; A&nbsp; 5&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [10] .rel.plt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048b78 000b78 000228 08&nbsp;&nbsp; A&nbsp; 5&nbsp; 12&nbsp; 4<br>
&nbsp; [11] .init&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048da0 000da0 000024 00&nbsp; AX&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [12] .plt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08048dd0 000dd0 000460 04&nbsp; AX&nbsp; 0&nbsp;&nbsp; 0 16<br>&nbsp; [13] .text&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08049230 001230 006f2c 00&nbsp; AX&nbsp; 0&nbsp;&nbsp; 0 16<br>
&nbsp; [14] .fini&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0805015c 00815c 000015 00&nbsp; AX&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [15] .rodata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08050180 008180 000e86 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0 32<br>&nbsp; [16] .eh_frame_hdr&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08051008 009008 0002d4 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>
&nbsp; [17] .eh_frame&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 080512dc 0092dc 000d30 00&nbsp;&nbsp; A&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [18] .init_array&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INIT_ARRAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08053f04 00af04 000004 00&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [19] .fini_array&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FINI_ARRAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08053f08 00af08 000004 00&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>
&nbsp; [20] .jcr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08053f0c 00af0c 000004 00&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [21] .dynamic&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DYNAMIC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08053f10 00af10 0000e8 08&nbsp; WA&nbsp; 6&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [22] .got&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08053ff8 00aff8 000008 04&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>
&nbsp; [23] .got.plt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08054000 00b000 000120 04&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [24] .data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08054120 00b120 00003c 00&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0&nbsp; 4<br>&nbsp; [25] .bss&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NOBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 08054160 00b15c 0005c4 00&nbsp; WA&nbsp; 0&nbsp;&nbsp; 0 32<br>
&nbsp; [26] .gnu_debuglink&nbsp;&nbsp;&nbsp; PROGBITS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000000 00b15c 000008 00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 0&nbsp; 1<br>&nbsp; [27] .shstrtab&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STRTAB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000000 00b164 0000fc 00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 0&nbsp; 1<br>Key to Flags:<br>&nbsp; W (write), A (alloc), X (execute), M (merge), S (strings)<br>
&nbsp; I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)<br>&nbsp; O (extra OS processing required) o (OS specific), p (processor specific)<br>==============================<br><br>But, according the kernel elf loader :<br>
<br>linux-3.7.4/fs/binfmt_elf.c:<br>static int load_elf_binary(...)<br>{<br>&nbsp;&nbsp;&nbsp; ...<br>&nbsp;&nbsp;&nbsp; for(i = 0, elf_ppnt = elf_phdata;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i &lt; loc-&gt;elf_ex.e_phnum; i++, elf_ppnt++) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (elf_ppnt-&gt;p_type != PT_LOAD)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue;<br>&nbsp;&nbsp;&nbsp; ...<br>}<br><br>The kernel elf loader just load PT_LOAD segment, but GNU_RELRO is not PT_LOAD type ?<div><div class="h5"><br></div></div></div></blockquote><div>&nbsp;&nbsp; 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. <br>
<br>First Let us look at Section to Segment mapping. <br>Sections 1 to 17 which have access permissions AX are mapped to 1st Loadable segment (Code)<br>Sections 18 to 26 which have access permissions WA are mapped to 2nd Loadable segment (Data)<br>
Of these Section 18 to 22 are also mapped to GNU_RELRO. <br><br>When an application is initiated for execution sections 18 to 22 will be accessed by the dynamic linker to edit few locations&nbsp; . 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. <br>
<br>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. <br><br>Thus once the dynamic linker finishes its job, this trick is done to split the virtual address region 08053000-08055000 to <br>
08053000-08054000 r--p 0000a000 08:01 261656&nbsp;&nbsp;&nbsp;&nbsp; /bin/cat<br>08054000-08055000 rw-p 0000b000 08:01 261656&nbsp;&nbsp;&nbsp;&nbsp; /bin/cat<br><br>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 section when the application invokes some of the library functions.<br>
<br>Why this trick ?<br><br>Suppose the entire virtual address region 08053000-08055000 is RW. The application can inadvertently access the addresses which are mapped to section 18 to 22 and cause the application to crash. <br>
<br>For eg. <br><br>int a[3]; // Suppose address of a is 0x08054160 belongs to .bss<br><br>int main()<br>{<br>&nbsp;&nbsp;&nbsp; a[-0x168] = 12;<br>&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp; return 0;<br>}<br><br>Since a[-0x168] is *(a-0x168). This will generate the address 0x08053FF8 which belongs to .got section (sec 22). <br>
This code will be writing into the .got section and cause the app. to crash at some point later. <br><br>To avoid this type of errors, sections 18 to 22 will be marked as READONLY, so that the kernel can do a access type<br>
validation of the generated address and not allow the program to write into READONLY area. <br><br>Regards,<br>Prabhunath G<br>Linux Trainer<br>Bangalore <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="line-height:1.7;font-size:14px;font-family:arial"><div><div class="h5"><br>At 2013-03-07 18:53:46,"Prabhu&nbsp;nath"&nbsp;&lt;<a href="mailto:gprabhunath@gmail.com" target="_blank">gprabhunath@gmail.com</a>&gt; wrote:<br>
 <blockquote style="PADDING-LEFT:1ex;MARGIN:0px 0px 0px 0.8ex;BORDER-LEFT:#ccc 1px solid">Looks like they have added a new section GNU_RELRO in the later versions. The one you are referring is read-only section. It would be nice if you share the section header table. <br>
Plz see inline<br><br clear="all"><div>Regards,<br>
Prabhunath G<br>Linux Trainer<br>Bangalore<br></div>
<br><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 3:31 PM, Jacky <span dir="ltr">&lt;<a href="mailto:jackyclivia@163.com" target="_blank">jackyclivia@163.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="line-height:1.7;font-size:14px;font-family:arial">Dear all,<br><br>This is the Program Header for "cat" info:<br><br>================================<br>readelf -l /bin/cat <br>...<br>Program Headers:<br>

&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Offset&nbsp;&nbsp; VirtAddr&nbsp;&nbsp; PhysAddr&nbsp;&nbsp; FileSiz MemSiz&nbsp; Flg Align<br>&nbsp; PHDR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4<br>&nbsp; INTERP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x000154 0x08048154 0x08048154 0x00013 0x00013 R&nbsp;&nbsp; 0x1<br>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Requesting program interpreter: /lib/ld-linux.so.2]<br>&nbsp; LOAD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x000000 0x08048000 0x08048000 0x0a00c 0x0a00c R E 0x1000<br>&nbsp; LOAD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00af04 0x08053f04 0x08053f04 0x00258 0x00820 RW&nbsp; 0x1000<br>&nbsp; DYNAMIC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00af10 0x08053f10 0x08053f10 0x000e8 0x000e8 RW&nbsp; 0x4<br>

&nbsp; NOTE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x000168 0x08048168 0x08048168 0x00044 0x00044 R&nbsp;&nbsp; 0x4<br>&nbsp; GNU_EH_FRAME&nbsp;&nbsp; 0x009008 0x08051008 0x08051008 0x002d4 0x002d4 R&nbsp;&nbsp; 0x4<br>&nbsp; GNU_STACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW&nbsp; 0x4<br>

&nbsp; GNU_RELRO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00af04 0x08053f04 0x08053f04 0x000fc 0x000fc R&nbsp;&nbsp; 0x1<br>==============================<br><br>So there are just 2 PT_LOAD segments. But why kernel maps 3 memory regions ? The following is the maps output:<br>

<br></div></blockquote><div>Though the second PT_LOAD starts at the file offset&nbsp; 0xaf04, The first fc bytes belong to GNU_RELRO segment (The last entry in the Program Header). If you add af04 +fc you get afff. Looks like they have placed this section advertently in such a way that the actual DATA segment will start at the next virtual address page boundary 0x08054000. Thus the GNU_RELRO section with read-only permissions is placed in the separate virtual address region. <br>

&nbsp;&nbsp;&nbsp; This is the result of the maps file you see below. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;font-size:14px;font-family:arial">

============================<br>cat /proc/self/maps <br><br>08048000-08053000 r-xp 00000000 08:01 261656&nbsp;&nbsp;&nbsp;&nbsp; /bin/cat<br>08053000-08054000 r--p 0000a000 08:01 261656&nbsp;&nbsp;&nbsp;&nbsp; /bin/cat<br>08054000-08055000 rw-p 0000b000 08:01 261656&nbsp;&nbsp;&nbsp;&nbsp; /bin/cat<br>

09b58000-09b79000 rw-p 00000000 00:00 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [heap]<br>b75bd000-b75be000 rw-p 00000000 00:00 0 <br>b75be000-b7761000 r-xp 00000000 08:01 523958&nbsp;&nbsp;&nbsp;&nbsp; /lib/i386-linux-gnu/<a href="http://libc-2.15.so" target="_blank">libc-2.15.so</a><br>

...<br>==================<br><br>The above output, there are 3 memory regions for "/bin/cat", and what is the following segment:<br><br>08053000-08054000 r--p 0000a000 08:01 261656&nbsp;&nbsp;&nbsp;&nbsp; /bin/cat<br><br>According the 'cat' program header, there is no "r" segment.<br>

<br><br>Regards,<br>Jacky<br><br><br>&nbsp;<br><br><br><br><br><br><br></div><br><br><span title="neteasefooter"><span></span></span><br>_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br></blockquote></div><br>
</blockquote></div></div></div><br><br><span title="neteasefooter"><span></span></span></blockquote></div><br>
</blockquote></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>