• Andy Lutomirski's avatar
    x86, vdso: Reimplement vdso.so preparation in build-time C · 6f121e54
    Andy Lutomirski authored
    Currently, vdso.so files are prepared and analyzed by a combination
    of objcopy, nm, some linker script tricks, and some simple ELF
    parsers in the kernel.  Replace all of that with plain C code that
    runs at build time.
    All five vdso images now generate .c files that are compiled and
    linked in to the kernel image.
    This should cause only one userspace-visible change: the loaded vDSO
    images are stripped more heavily than they used to be.  Everything
    outside the loadable segment is dropped.  In particular, this causes
    the section table and section name strings to be missing.  This
    should be fine: real dynamic loaders don't load or inspect these
    tables anyway.  The result is roughly equivalent to eu-strip's
    --strip-sections option.
    The purpose of this change is to enable the vvar and hpet mappings
    to be moved to the page following the vDSO load segment.  Currently,
    it is possible for the section table to extend into the page after
    the load segment, so, if we map it, it risks overlapping the vvar or
    hpet page.  This happens whenever the load segment is just under a
    multiple of PAGE_SIZE.
    The only real subtlety here is that the old code had a C file with
    inline assembler that did 'call VDSO32_vsyscall' and a linker script
    that defined 'VDSO32_vsyscall = __kernel_vsyscall'.  This most
    likely worked by accident: the linker script entry defines a symbol
    associated with an address as opposed to an alias for the real
    dynamic symbol __kernel_vsyscall.  That caused ld to relocate the
    reference at link time instead of leaving an interposable dynamic
    relocation.  Since the VDSO32_vsyscall hack is no longer needed, I
    now use 'call __kernel_vsyscall', and I added -Bsymbolic to make it
    work.  vdso2c will generate an error and abort the build if the
    resulting image contains any dynamic relocations, so we won't
    silently generate bad vdso images.
    (Dynamic relocations are a problem because nothing will even attempt
    to relocate the vdso.)
    Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
    Link: http://lkml.kernel.org/r/2c4fcf45524162a34d87fdda1eb046b2a5cecee7.1399317206.git.luto@amacapital.net
    Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
mmu.h 544 Bytes