linux-kernel - Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

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]

Date:	Thu, 21 Jan 2016 14:50:08 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, x86@...nel.org,
	keescook@...omium.org, mingo@...nel.org, hpa@...or.com,
	heiko.carstens@...ibm.com, benh@...nel.crashing.org,
	mpe@...erman.id.au, mmarek@...e.cz, rusty@...tcorp.com.au,
	arnd@...db.de, linux-arch@...r.kernel.org
Subject: Re: [PATCH v3] kallsyms: add support for relative offsets in
 kallsyms address table

On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:

> Similar to how relative extables are implemented, it is possible to emit
> the kallsyms table in such a way that it contains offsets relative to some
> anchor point in the kernel image rather than absolute addresses. The benefit
> is that such table entries are no longer subject to dynamic relocation when
> the build time and runtime offsets of the kernel image are different. Also,
> on 64-bit architectures, it essentially cuts the size of the address table
> in half since offsets can typically be expressed in 32 bits.
> 
> Since it is useful for some architectures (like x86) to retain the ability
> to emit absolute values as well, this patch adds support for both, by
> emitting absolute addresses as positive 32-bit values, and addresses
> relative to the lowest encountered relative symbol as negative values, which
> are subtracted from the runtime address of this base symbol to produce the
> actual address.
> 
> Support for the above is enabled by default for all architectures except
> IA-64, whose symbols are too far apart to capture in this manner.

I'm not really understanding the benefits of this.  A smaller address
table is nice, but why is it desirable that "such table entries are no
longer subject to dynamic relocation when the build time and runtime
offsets of the kernel image are different"?