On 22 January 2016 at 04:44, Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote: > On Thu, 2016-01-21 at 14:55 -0800, Kees Cook wrote: >> On Thu, Jan 21, 2016 at 2:50 PM, Andrew Morton >> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> > On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> 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"? >> >> 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. > > Yep. If I remember the figures rightly it saves ~250K of relocations for the > powerpc build. > For ppc64_defconfig (which has CONFIG_RELOCATABLE=y, i.e., it has a dynamic relocation section containing a 24-byte RELA entry per relocated quantity), I got the following numbers 101740 kallsyms entries 397 KB saved in permanent .rodata 2.4 MB saved in __init rela.dyn section ~500 KB saved in compressed image For arm64, we don't have a compressed image, which is the reason I need this for my arm64 implementation of CONFIG_RELOCATABLE (for KASLR), since the RELA overhead goes straight into the distributed image. Thanks, Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
