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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061006233547.43888a48.akpm@osdl.org>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ