1. 23 10月, 2008 1 次提交
  2. 24 2月, 2008 1 次提交
    • J
      uml: fix FP register corruption · 2f56debd
      Jeff Dike 提交于
      Commit ee3d9bd4 ("uml: simplify SIGSEGV
      handling"), while greatly simplifying the kernel SIGSEGV handler that
      runs in the process address space, introduced a bug which corrupts FP
      state in the process.
      
      Previously, the SIGSEGV handler called the sigreturn system call by hand - it
      couldn't return through the restorer provided to it because that could try to
      call the libc restorer which likely wouldn't exist in the process address
      space.  So, it blocked off some signals, including SIGUSR1, on entry to the
      SIGSEGV handler, queued a SIGUSR1 to itself, and invoked sigreturn.  The
      SIGUSR1 was delivered, and was visible to the UML kernel after sigreturn
      finished.
      
      The commit eliminated the signal masking and the call to sigreturn.  The
      handler simply hits itself with a SIGTRAP to let the UML kernel know that it
      is finished.  UML then restores the process registers, which effectively
      longjmps the process out of the signal handler, skipping sigreturn's restoring
      of register state and the signal mask.
      
      The bug is that the host apparently sets used_fp to 0 when it saves the
      process FP state in the sigcontext on the process signal stack.  Thus, when
      the process is longjmped out of the handler, its FP state is corrupt because
      it wasn't saved on the context switch to the UML kernel.
      
      This manifested itself as sleep hanging.  For some reason, sleep uses floating
      point in order to calculate the sleep interval.  When a page fault corrupts
      its FP state, it is faked into essentially sleeping forever.
      
      This patch saves the FP state before entering the SIGSEGV handler and restores
      it afterwards.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f56debd
  3. 06 2月, 2008 2 次提交
    • J
      uml: kill processes instead of panicing kernel · 3e6f2ac4
      Jeff Dike 提交于
      UML was panicing in the case of failures of libc calls which shouldn't happen.
       This is an overreaction since a failure from libc doesn't normally mean that
      kernel data structures are in an unknown state.  Instead, the current process
      should just be killed if there is no way to recover.
      
      The case that prompted this was a failure of PTRACE_SETREGS restoring the same
      state that was read by PTRACE_GETREGS.  It appears that when a process tries
      to load a bogus value into a segment register, it segfaults (as expected) and
      the value is actually loaded and is seen by PTRACE_GETREGS (not expected).
      
      This case is fixed by forcing a fatal SIGSEGV on the process so that it
      immediately dies.  fatal_sigsegv was added for this purpose.  It was declared
      as noreturn, so in order to pursuade gcc that it actually does not return, I
      added a call to os_dump_core (and declared it noreturn) so that I get a core
      file if somehow the process survives.
      
      All other calls in arch/um/os-Linux/skas/process.c got the same treatment,
      with failures causing the process to die instead of a kernel panic, with some
      exceptions.
      
      userspace_tramp exits with status 1 if anything goes wrong there.  That will
      cause start_userspace to return an error.  copy_context_skas0 and
      map_stub_pages also now return errors instead of panicing.  Callers of thes
      functions were changed to check for errors and do something appropriate.
      Usually that's to return an error to their callers.
      check_skas3_ptrace_faultinfo just exits since that's too early to do anything
      else.
      
      save_registers, restore_registers, and init_registers now return status
      instead of panicing on failure, with their callers doing something
      appropriate.
      
      There were also duplicate declarations of save_registers and restore_registers
      in os.h - these are gone.
      
      I noticed and fixed up some whitespace damage.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3e6f2ac4
    • J
      uml: use ptrace directly in libc code · d25f2e12
      Jeff Dike 提交于
      Some register accessor cleanups -
      	userspace() was calling restore_registers and save_registers for no
      reason, since userspace() is on the libc side of the house, and these
      add no value over calling ptrace directly
      	init_thread_registers and get_safe_registers were the same thing,
      so init_thread_registers is gone
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d25f2e12
  4. 17 10月, 2007 3 次提交
    • J
      uml: floating point signal delivery fixes · a5f6096c
      Jeff Dike 提交于
      Handle floating point state in across signals correctly.  UML/i386 needs to
      know whether the host does PTRACE_[GS]ETFPXREGS, so an arch_init_registers
      hook is added, which on x86_64 does nothing.
      
      UML doesn't save and restore floating point registers on kernel entry and
      exit, so they need to be copied between the host process and the sigcontext.
      save_fpx_registers and restore_fpx_registers are added for this purpose.
      save_fp_registers and restore_fp_registers already exist.
      
      There was a bunch of floating point state conversion code in
      arch/um/sys-i386/ptrace.c which isn't needed there, but is needed in signal.c,
      so it is moved over.
      
      The i386 code now distinguishes between fp and fpx state and handles them
      correctly.  The x86_64 code just needs to copy state as-is between the host
      process and the stack.  There are also some fixes there to pass the correct
      address of the floating point state around.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a5f6096c
    • J
      uml: remove code made redundant by CHOOSE_MODE removal · 77bf4400
      Jeff Dike 提交于
      This patch makes a number of simplifications enabled by the removal of
      CHOOSE_MODE.  There were lots of functions that looked like
      
      	int foo(args){
      		foo_skas(args);
      	}
      
      The bodies of foo_skas are now folded into foo, and their declarations (and
      sometimes entire header files) are deleted.
      
      In addition, the union uml_pt_regs, which was a union between the tt and skas
      register formats, is now a struct, with the tt-mode arm of the union being
      removed.
      
      It turns out that usr2_handler was unused, so it is gone.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      77bf4400
    • J
      uml: stop saving process FP state · 42daba31
      Jeff Dike 提交于
      Throw out a lot of code dealing with saving and restoring floating-point
      state.  In skas mode, where processes run in a restoring floating-point state
      on kernel entry and exit is pointless.
      
      This eliminates most of arch/um/os-Linux/sys-{i386,x86_64}/registers.c.  Most
      of what remained is now arch-indpendent, and can be moved up to
      arch/um/os-Linux/registers.c.  Both arches need the jmp_buf accessor
      get_thread_reg, and i386 needs {save,restore}_fp_regs because it cheats during
      sigreturn by getting the fp state using ptrace rather than copying it out of
      the process sigcontext.
      
      After this, it turns out that arch/um/include/skas/mode-skas.h is almost
      completely unneeded.  The declarations in it are variables which either don't
      exist or which don't have global scope.  The one exception is
      kill_off_processes_skas.  If that's removed, this header can be deleted.
      
      This uncovered a bug in user.h, which wasn't correctly making sure that a
      size_t definition was available to both userspace and kernelspace files.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42daba31
  5. 26 9月, 2006 1 次提交
    • J
      [PATCH] uml: stack usage reduction · 75e29b18
      Jeff Dike 提交于
      The KSTK_* macros used an inordinate amount of stack.  In order to overcome
      an impedance mismatch between their interface, which just returns a single
      register value, and the interface of get_thread_regs, which took a full
      pt_regs, the implementation created an on-stack pt_regs, filled it in, and
      returned one field.  do_task_stat calls KSTK_* twice, resulting in two
      local pt_regs, blowing out the stack.
      
      This patch changes the interface (and name) of get_thread_regs to just
      return a single register from a jmp_buf.
      
      The include of archsetjmp.h" in registers.h to get the definition of
      jmp_buf exposed a bogus include of <setjmp.h> in start_up.c.  <setjmp.h>
      shouldn't be used anywhere any more since UML uses the klibc
      setjmp/longjmp.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      75e29b18
  6. 08 2月, 2006 1 次提交
  7. 05 10月, 2005 1 次提交
  8. 08 7月, 2005 1 次提交
    • J
      [PATCH] uml: skas0 - separate kernel address space on stock hosts · d67b569f
      Jeff Dike 提交于
      UML has had two modes of operation - an insecure, slow mode (tt mode) in
      which the kernel is mapped into every process address space which requires
      no host kernel modifications, and a secure, faster mode (skas mode) in
      which the UML kernel is in a separate host address space, which requires a
      patch to the host kernel.
      
      This patch implements something very close to skas mode for hosts which
      don't support skas - I'm calling this skas0.  It provides the security of
      the skas host patch, and some of the performance gains.
      
      The two main things that are provided by the skas patch, /proc/mm and
      PTRACE_FAULTINFO, are implemented in a way that require no host patch.
      
      For the remote address space changing stuff (mmap, munmap, and mprotect),
      we set aside two pages in the process above its stack, one of which
      contains a little bit of code which can call mmap et al.
      
      To update the address space, the system call information (system call
      number and arguments) are written to the stub page above the code.  The
      %esp is set to the beginning of the data, the %eip is set the the start of
      the stub, and it repeatedly pops the information into its registers and
      makes the system call until it sees a system call number of zero.  This is
      to amortize the cost of the context switch across multiple address space
      updates.
      
      When the updates are done, it SIGSTOPs itself, and the kernel process
      continues what it was doing.
      
      For a PTRACE_FAULTINFO replacement, we set up a SIGSEGV handler in the
      child, and let it handle segfaults rather than nullifying them.  The
      handler is in the same page as the mmap stub.  The second page is used as
      the stack.  The handler reads cr2 and err from the sigcontext, sticks them
      at the base of the stack in a faultinfo struct, and SIGSTOPs itself.  The
      kernel then reads the faultinfo and handles the fault.
      
      A complication on x86_64 is that this involves resetting the registers to
      the segfault values when the process is inside the kill system call.  This
      breaks on x86_64 because %rcx will contain %rip because you tell SYSRET
      where to return to by putting the value in %rcx.  So, this corrupts $rcx on
      return from the segfault.  To work around this, I added an
      arch_finish_segv, which on x86 does nothing, but which on x86_64 ptraces
      the child back through the sigreturn.  This causes %rcx to be restored by
      sigreturn and avoids the corruption.  Ultimately, I think I will replace
      this with the trick of having it send itself a blocked signal which will be
      unblocked by the sigreturn.  This will allow it to be stopped just after
      the sigreturn, and PTRACE_SYSCALLed without all the back-and-forth of
      PTRACE_SYSCALLing it through sigreturn.
      
      This runs on a stock host, so theoretically (and hopefully), tt mode isn't
      needed any more.  We need to make sure that this is better in every way
      than tt mode, though.  I'm concerned about the speed of address space
      updates and page fault handling, since they involve extra round-trips to
      the child.  We can amortize the round-trip cost for large address space
      updates by writing all of the operations to the data page and having the
      child execute them all at the same time.  This will help fork and exec, but
      not page faults, since they involve only one page.
      
      I can't think of any way to help page faults, except to add something like
      PTRACE_FAULTINFO to the host.  There is PTRACE_SIGINFO, but UML doesn't use
      siginfo for SIGSEGV (or anything else) because there isn't enough
      information in the siginfo struct to handle page faults (the faulting
      operation type is missing).  Adding that would make PTRACE_SIGINFO a usable
      equivalent to PTRACE_FAULTINFO.
      
      As for the code itself:
      
      - The system call stub is in arch/um/kernel/sys-$(SUBARCH)/stub.S.  It is
        put in its own section of the binary along with stub_segv_handler in
        arch/um/kernel/skas/process.c.  This is manipulated with run_syscall_stub
        in arch/um/kernel/skas/mem_user.c.  syscall_stub will execute any system
        call at all, but it's only used for mmap, munmap, and mprotect.
      
      - The x86_64 stub calls sigreturn by hand rather than allowing the normal
        sigreturn to happen, because the normal sigreturn is a SA_RESTORER in
        UML's address space provided by libc.  Needless to say, this is not
        available in the child's address space.  Also, it does a couple of odd
        pops before that which restore the stack to the state it was in at the
        time the signal handler was called.
      
      - There is a new field in the arch mmu_context, which is now a union.
        This is the pid to be manipulated rather than the /proc/mm file
        descriptor.  Code which deals with this now checks proc_mm to see whether
        it should use the usual skas code or the new code.
      
      - userspace_tramp is now used to create a new host process for every UML
        process, rather than one per UML processor.  It checks proc_mm and
        ptrace_faultinfo to decide whether to map in the pages above its stack.
      
      - start_userspace now makes CLONE_VM conditional on proc_mm since we need
        separate address spaces now.
      
      - switch_mm_skas now just sets userspace_pid[0] to the new pid rather
        than PTRACE_SWITCH_MM.  There is an addition to userspace which updates
        its idea of the pid being manipulated each time around the loop.  This is
        important on exec, when the pid will change underneath userspace().
      
      - The stub page has a pte, but it can't be mapped in using tlb_flush
        because it is part of tlb_flush.  This is why it's required for it to be
        mapped in by userspace_tramp.
      
      Other random things:
      
      - The stub section in uml.lds.S is page aligned.  This page is written
        out to the backing vm file in setup_physmem because it is mapped from
        there into user processes.
      
      - There's some confusion with TASK_SIZE now that there are a couple of
        extra pages that the process can't use.  TASK_SIZE is considered by the
        elf code to be the usable process memory, which is reasonable, so it is
        decreased by two pages.  This confuses the definition of
        USER_PGDS_IN_LAST_PML4, making it too small because of the rounding down
        of the uneven division.  So we round it to the nearest PGDIR_SIZE rather
        than the lower one.
      
      - I added a missing PT_SYSCALL_ARG6_OFFSET macro.
      
      - um_mmu.h was made into a userspace-usable file.
      
      - proc_mm and ptrace_faultinfo are globals which say whether the host
        supports these features.
      
      - There is a bad interaction between the mm.nr_ptes check at the end of
        exit_mmap, stack randomization, and skas0.  exit_mmap will stop freeing
        pages at the PGDIR_SIZE boundary after the last vma.  If the stack isn't
        on the last page table page, the last pte page won't be freed, as it
        should be since the stub ptes are there, and exit_mmap will BUG because
        there is an unfreed page.  To get around this, TASK_SIZE is set to the
        next lowest PGDIR_SIZE boundary and mm->nr_ptes is decremented after the
        calls to init_stub_pte.  This ensures that we know the process stack (and
        all other process mappings) will be below the top page table page, and
        thus we know that mm->nr_ptes will be one too many, and can be
        decremented.
      
      Things that need fixing:
      
      - We may need better assurrences that the stub code is PIC.
      
      - The stub pte is set up in init_new_context_skas.
      
      - alloc_pgdir is probably the right place.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d67b569f
  9. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4