• Jeff Dike's avatar
    [PATCH] uml: add elf vsyscall support · 22f0b7f9
    Jeff Dike authored
    From: Bodo Stroesser
    
    This is the first patch of a series of four.
    These patches allow the use of sysenter-systemcalls in UML
    if the host support sysenter.
    Some facts have to be noted:
    - the sysenter instruction does not save anything, not even the
      return address. Thus the host-kernel builds a stackframe with an
      fixed return address for the backjump to the vsyscall-page. All
      kernels that support sysenter thus must have a vsyscall-page
    - The hosts vsyscall-page is visible in all memory-contexts on the
      host, even in those of the processes running on UML. This cannot
      be changed.
    So the best way to implement sysenter is to integrate the host's
    vsyscall-page into UML, if available.
    
    This patch creates a new source file containing an UML
    initialization function. The function scans the Elf-auxiliary vector
    that is prepared by the host for relevant information about:
    - vsyscall elf-header
    - vsyscall entry
    - machine type (called "platform", e.g. "i586" or "i686")
    - hardware capabilities
    These informations are inserted into the Elf-auxiliary-vector that is
    generated if an UML process calls "execXX()". If the information from
    the auxiliray-vector is not complete, UML uses the previos default
    values, with one exception: if the host has no vsyscall-page, UML now
    does no longer insert AT_SYSINFO or AT_SYSINFO_EHDR elements. (I think,
    that's better than writing dummies)
    
    Since the host's vsyscall-page is always visible to UML processes, this
    change is enough to let UML with an i686-compiled glibc use sysenter.
    
    what's missing:
    - is_syscall() in SKAS cannot access the code in the vsyscall-page via
      copy_from_user(), thus singlesteppers still could break out. (Note:
      that's not new, if someone jumps willingly to the sysenter-entry in
      the vsyscall-page, he can do that without the patch, too).
    - a debugger cannot access the code in the vsyscall-page via
      ptrace( PEEKTEXT, ...)
    
    Risks:
    could there by any feature of the host's processor, that is indicated in
    the hardware capabilities, but must not be used in UML?
    Signed-off-by: default avatarBodo Stroesser <bodo.stroesser@fujitsu-siemens.com>
    Signed-off-by: default avatarJeff Dike <jdike@addtoit.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    22f0b7f9
archparam-i386.h 4.73 KB