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]

Message-ID: <CAKv+Gu8QvECRJ9DhEd=k-oTy=xVVFJSMaW0EOCxMMPsWsF2RMQ@mail.gmail.com>
Date:	Fri, 22 Jan 2016 09:20:41 +0100
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kees Cook <keescook@...omium.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Michal Marek <mmarek@...e.cz>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Arnd Bergmann <arnd@...db.de>,
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms
 address table

On 22 January 2016 at 00:20, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Thu, 21 Jan 2016 14:55:00 -0800 Kees Cook <keescook@...omium.org> wrote:
>
>> IIUC, this means that the relocation work done after decompression now
>> doesn't have to do relocation updates for all these values, which
>> means a smaller relocation table as well.
>
> Makes sense, thanks.  I altered the changelog
>
> : 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.
> :

Thanks for taking the patch, but the bit below does not make sense anymore:

"""
> : The benefit is that such table entries are no longer subject to dynamic
> : relocation when the build time so the relocation work done after
> : decompression now doesn't have to do relocation updates for all these
> : values, which means a smaller relocation table as well.
> :
> : Also, the 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.
> :
"""

In addition to fixing the broken grammar, would it make sense to
mention that dynamic relocation only occurs under
CONFIG_RELOCATABLE=y? I.e., something like

"""
On 64-bit architectures, it cuts the size of the kallsyms address
table in half, since offsets between kernel symbols can typically be
expressed in 32 bits. This saves several hundreds of kilobytes of
permanent .rodata on average. In addition, the kallsyms address table
is no longer subject to dynamic relocation when CONFIG_RELOCATABLE is
in effect, so the relocation work done after decompression now doesn't
have to do relocation updates for all these values. This saves up to
24 bytes (i.e., the size of a ELF64 RELA relocation table entry) per
table entry, which easily adds up to a couple of megabytes of
uncompressed __init data on ppc64 or arm64. Even if these relocation
entries typically compress well, the combined size reduction of 2.8 MB
uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
data) results in a ~500 KB space saving in the compressed image.
"""

Thanks,
Ard.