1. 13 10月, 2012 1 次提交
  2. 09 1月, 2009 1 次提交
    • K
      ELF: implement AT_RANDOM for glibc PRNG seeding · f06295b4
      Kees Cook 提交于
      While discussing[1] the need for glibc to have access to random bytes
      during program load, it seems that an earlier attempt to implement
      AT_RANDOM got stalled.  This implements a random 16 byte string, available
      to every ELF program via a new auxv AT_RANDOM vector.
      
      [1] http://sourceware.org/ml/libc-alpha/2008-10/msg00006.html
      
      Ulrich said:
      
      glibc needs right after startup a bit of random data for internal
      protections (stack canary etc).  What is now in upstream glibc is that we
      always unconditionally open /dev/urandom, read some data, and use it.  For
      every process startup.  That's slow.
      
      ...
      
      The solution is to provide a limited amount of random data to the
      starting process in the aux vector.  I suggested 16 bytes and this is
      what the patch implements.  If we need only 16 bytes or less we use the
      data directly.  If we need more we'll use the 16 bytes to see a PRNG.
      This avoids the costly /dev/urandom use and it allows the kernel to use
      the most adequate source of random data for this purpose.  It might not
      be the same pool as that for /dev/urandom.
      
      Concerns were expressed about the depletion of the randomness pool.  But
      this patch doesn't make the situation worse, it doesn't deplete entropy
      more than happens now.
      Signed-off-by: NKees Cook <kees.cook@canonical.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f06295b4
  3. 25 7月, 2008 1 次提交
    • N
      ELF loader support for auxvec base platform string · 483fad1c
      Nathan Lynch 提交于
      Some IBM POWER-based platforms have the ability to run in a
      mode which mostly appears to the OS as a different processor from the
      actual hardware.  For example, a Power6 system may appear to be a
      Power5+, which makes the AT_PLATFORM value "power5+".  This means that
      programs are restricted to the ISA supported by Power5+;
      Power6-specific instructions are treated as illegal.
      
      However, some applications (virtual machines, optimized libraries) can
      benefit from knowledge of the underlying CPU model.  A new aux vector
      entry, AT_BASE_PLATFORM, will denote the actual hardware.  For
      example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
      will be "power5+" and AT_BASE_PLATFORM will be "power6".  The idea is
      that AT_PLATFORM indicates the instruction set supported, while
      AT_BASE_PLATFORM indicates the underlying microarchitecture.
      
      If the architecture has defined ELF_BASE_PLATFORM, copy that value to
      the user stack in the same manner as ELF_PLATFORM.
      Signed-off-by: NNathan Lynch <ntl@pobox.com>
      Acked-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      483fad1c
  4. 23 7月, 2008 1 次提交
    • J
      execve filename: document and export via auxiliary vector · 65191087
      John Reiser 提交于
      The Linux kernel puts the filename argument of execve() into the new
      address space.  Many developers are surprised to learn this.  Those who
      know and could use it, object "But it's not documented."
      
      Those who want to use it dislike the expression
        (char *)(1+ strlen(env[-1+ n_env]) + env[-1+ n_env])
      because it requires locating the last original environment variable,
      and assumes that the filename follows the characters.
      
      This patch documents the insertion of the filename, and makes it easier
      to find by adding a new tag AT_EXECFN in the ElfXX_auxv_t; see <elf.h>.
      
      In many cases readlink("/proc/self/exe",) gives the same answer.  But if
      all the original pages get unmapped, then the kernel erases the symlink
      for /proc/self/exe.  This can happen when a program decompressor does a
      good job of cleaning up after uncompressing directly to memory, so that
      the address space of the target program looks the same as if compression
      had never happened.  One example is http://upx.sourceforge.net .
      
      One notable use of the underlying concept (what path containED the
      executable) is glibc expanding $ORIGIN in DT_RUNPATH.  In practice for
      the near term, it may be a good idea for user-mode code to use both
      /proc/self/exe and AT_EXECFN as fall-back methods for each other.
      /proc/self/exe can fail due to unmapping, AT_EXECFN can fail because it
      won't be present on non-new systems.  The auxvec or {AT_EXECFN}.d_val
      also can get overwritten, although in nearly all cases this would be the
      result of a bug.
      
      The runtime cost is one NEW_AUX_ENT using two words of stack space.  The
      underlying value is maintained already as bprm->exec; setup_arg_pages()
      in fs/exec.c slides it for stack_shift, etc.
      Signed-off-by: NJohn Reiser <jreiser@BitWagon.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      65191087
  5. 17 10月, 2007 1 次提交
    • O
      increase AT_VECTOR_SIZE to terminate saved_auxv properly · 4f9a58d7
      Olaf Hering 提交于
      include/asm-powerpc/elf.h has 6 entries in ARCH_DLINFO.  fs/binfmt_elf.c
      has 14 unconditional NEW_AUX_ENT entries and 2 conditional NEW_AUX_ENT
      entries.  So in the worst case, saved_auxv does not get an AT_NULL entry at
      the end.
      
      The saved_auxv array must be terminated with an AT_NULL entry.  Make the
      size of mm_struct->saved_auxv arch dependend, based on the number of
      ARCH_DLINFO entries.
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4f9a58d7
  6. 14 1月, 2006 1 次提交
    • P
      [PATCH] Increase AT_VECTOR_SIZE · 67daf5f1
      Paul Mackerras 提交于
      On PowerPC, we want to be able to provide an AT_PLATFORM aux table
      entry to userspace, so that glibc can choose optimized libraries for
      the processor we're running on.  Unfortunately that would be the 21st
      aux table entry on powerpc, meaning that the aux table including the
      terminating null entry would overflow the mm->saved_auxv[] array,
      leading to userland programs segfaulting.
      
      This increases the size of the mm->saved_auxv array to be large enough
      to accommodate an AT_PLATFORM entry on powerpc.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      67daf5f1
  7. 08 9月, 2005 1 次提交
    • H
      [PATCH] auxiliary vector cleanups · 36d57ac4
      H. J. Lu 提交于
      The size of auxiliary vector is fixed at 42 in linux/sched.h.  But it isn't
      very obvious when looking at linux/elf.h.  This patch adds AT_VECTOR_SIZE
      so that we can change it if necessary when a new vector is added.
      
      Because of include file ordering problems, doing this necessitated the
      extraction of the AT_* symbols into a standalone header file.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      36d57ac4