lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 6 Oct 2006 23:35:47 -0700 From: Andrew Morton <akpm@...l.org> To: vgoyal@...ibm.com Cc: linux kernel mailing list <linux-kernel@...r.kernel.org>, Reloc Kernel List <fastboot@...ts.osdl.org>, ebiederm@...ssion.com, ak@...e.de, horms@...ge.net.au, lace@...kratochvil.net, hpa@...or.com, magnus.damm@...il.com, lwang@...hat.com, dzickus@...hat.com, maneesh@...ibm.com Subject: Re: [PATCH 1/12] i386: Distinguish absolute symbols On Tue, 3 Oct 2006 13:04:13 -0400 Vivek Goyal <vgoyal@...ibm.com> wrote: > Ld knows about 2 kinds of symbols, absolute and section > relative. Section relative symbols symbols change value > when a section is moved and absolute symbols do not. > > Currently in the linker script we have several labels > marking the beginning and ending of sections that > are outside of sections, making them absolute symbols. > Having a mixture of absolute and section relative > symbols refereing to the same data is currently harmless > but it is confusing. > > This must be done carefully as newer revs of ld do not place > symbols that appear in sections without data and instead > ld makes those symbols global :( > > My ultimate goal is to build a relocatable kernel. The > safest and least intrusive technique is to generate > relocation entries so the kernel can be relocated at load > time. The only penalty would be an increase in the size > of the kernel binary. The problem is that if absolute and > relocatable symbols are not properly specified absolute symbols > will be relocated or section relative symbols won't be, which > is fatal. > > The practical motivation is that when generating kernels that > will run from a reserved area for analyzing what caused > a kernel panic, it is simpler if you don't need to hard code > the physical memory location they will run at, especially > for the distributions. This patch causes the following warnings: /opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: .tmp_vmlinux1: warning: allocated section `.smp_altinstr_replacement' not in segment /opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: .tmp_vmlinux2: warning: allocated section `.smp_altinstr_replacement' not in segment /opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: vmlinux: warning: allocated section `.smp_altinstr_replacement' not in segment The patch i386-force-section-size-to-be-non-zero-to-prevent-a-symbol-becoming-absolute.patch makes those warnings go away again, but we decided to drop that. This: .smp_altinstr_replacement : AT(ADDR(.smp_altinstr_replacement) - LOAD_OFFSET) { *(.smp_altinstr_replacement) . = ALIGN(4096); __smp_alt_end = .; } looks odd. What's the point in putting a gap before __smp_alt_end? Moving __smp_alt_end to before the ALIGN doesn't prevent the warning. GNU ld version 2.16.1, gcc-4.1.0, config at http://userweb.kernel.org/~akpm/config-vmm.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists