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. cheers -- 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
