[PATCH v3] kallsyms: add support for relative offsets in kallsyms address table

Kees Cook keescook at chromium.org
Fri Jan 22 09:55:00 AEDT 2016


On Thu, Jan 21, 2016 at 2:50 PM, Andrew Morton
<akpm at linux-foundation.org> wrote:
> On Thu, 21 Jan 2016 18:19:43 +0100 Ard Biesheuvel <ard.biesheuvel at linaro.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"?

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.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


More information about the Linuxppc-dev mailing list