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+Gu9rgeWYgJ_0Rpx1DmvWP90O8r=MBN4YH4xZyn3r4wrUdg@mail.gmail.com>
Date:	Fri, 22 Jan 2016 22:54:44 +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 22:07, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Fri, 22 Jan 2016 09:20:41 +0100 Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>
>> > : 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.
>> """
>
> Yes, that sounds very good.  I'd buy one :)
>

Did I tell you about the extended warranty?

> Can you please send along a complete new changelog sometime?

Sure:

"""
kallsyms: add support for relative offsets in kallsyms address table

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.

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 value, 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.

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.

Acked-by: Heiko Carstens <heiko.carstens@...ibm.com>
Tested-by: Michael Ellerman <mpe@...erman.id.au> # powerpc
Tested-by: Kees Cook <keescook@...omium.org> # x86_64
Reviewed-by: Kees Cook <keescook@...omium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
"""

Thanks,
Ard.