1. 14 7月, 2011 2 次提交
  2. 07 6月, 2011 1 次提交
    • A
      x86-64: Emulate legacy vsyscalls · 5cec93c2
      Andy Lutomirski 提交于
      There's a fair amount of code in the vsyscall page.  It contains
      a syscall instruction (in the gettimeofday fallback) and who
      knows what will happen if an exploit jumps into the middle of
      some other code.
      
      Reduce the risk by replacing the vsyscalls with short magic
      incantations that cause the kernel to emulate the real
      vsyscalls. These incantations are useless if entered in the
      middle.
      
      This causes vsyscalls to be a little more expensive than real
      syscalls.  Fortunately sensible programs don't use them.
      The only exception is time() which is still called by glibc
      through the vsyscall - but calling time() millions of times
      per second is not sensible. glibc has this fixed in the
      development tree.
      
      This patch is not perfect: the vread_tsc and vread_hpet
      functions are still at a fixed address.  Fixing that might
      involve making alternative patching work in the vDSO.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/e64e1b3c64858820d12c48fa739efbd1485e79d5.1307292171.git.luto@mit.edu
      [ Removed the CONFIG option - it's simpler to just do it unconditionally. Tidied up the code as well. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cec93c2
  3. 06 6月, 2011 4 次提交
    • A
      x86-64: Map the HPET NX · d319bb79
      Andy Lutomirski 提交于
      Currently the HPET mapping is a user-accessible syscall
      instruction at a fixed address some of the time.
      
      A sufficiently determined hacker might be able to guess when.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/ab41b525a4ca346b1ca1145d16fb8d181861a8aa.1307292171.git.luto@mit.eduSigned-off-by: NIngo Molnar <mingo@elte.hu>
      d319bb79
    • A
      x86-64: Remove kernel.vsyscall64 sysctl · 0d7b8547
      Andy Lutomirski 提交于
      It's unnecessary overhead in code that's supposed to be highly
      optimized.  Removing it allows us to remove one of the two
      syscall instructions in the vsyscall page.
      
      The only sensible use for it is for UML users, and it doesn't
      fully address inconsistent vsyscall results on UML.  The real
      fix for UML is to stop using vsyscalls entirely.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/973ae803fe76f712da4b2740e66dccf452d3b1e4.1307292171.git.luto@mit.eduSigned-off-by: NIngo Molnar <mingo@elte.hu>
      0d7b8547
    • A
      x86-64: Give vvars their own page · 9fd67b4e
      Andy Lutomirski 提交于
      Move vvars out of the vsyscall page into their own page and mark
      it NX.
      
      Without this patch, an attacker who can force a daemon to call
      some fixed address could wait until the time contains, say,
      0xCD80, and then execute the current time.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/b1460f81dc4463d66ea3f2b5ce240f58d48effec.1307292171.git.luto@mit.eduSigned-off-by: NIngo Molnar <mingo@elte.hu>
      9fd67b4e
    • A
      x86-64: Fix alignment of jiffies variable · 6879eb2d
      Andy Lutomirski 提交于
      It's declared __attribute__((aligned(16)) but it's explicitly
      not aligned.  This is probably harmless but it's a bit
      embarrassing.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/5f3bc5542e9aaa9382d53f153f54373165cdef89.1307292171.git.luto@mit.eduSigned-off-by: NIngo Molnar <mingo@elte.hu>
      6879eb2d
  4. 29 5月, 2011 2 次提交
    • L
      x86 idle: clarify AMD erratum 400 workaround · 02c68a02
      Len Brown 提交于
      The workaround for AMD erratum 400 uses the term "c1e" falsely suggesting:
      1. Intel C1E is somehow involved
      2. All AMD processors with C1E are involved
      
      Use the string "amd_c1e" instead of simply "c1e" to clarify that
      this workaround is specific to AMD's version of C1E.
      Use the string "e400" to clarify that the workaround is specific
      to AMD processors with Erratum 400.
      
      This patch is text-substitution only, with no functional change.
      
      cc: x86@kernel.org
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      02c68a02
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  5. 27 5月, 2011 4 次提交
  6. 25 5月, 2011 6 次提交
    • R
      x86: remove 32-bit versions of readq()/writeq() · dbee8a0a
      Roland Dreier 提交于
      The presense of a writeq() implementation on 32-bit x86 that splits the
      64-bit write into two 32-bit writes turns out to break the mpt2sas driver
      (and in general is risky for drivers as was discussed in
      <http://lkml.kernel.org/r/adaab6c1h7c.fsf@cisco.com>).  To fix this,
      revert 2c5643b1 ("x86: provide readq()/writeq() on 32-bit too") and
      follow-on cleanups.
      
      This unfortunately leads to pushing non-atomic definitions of readq() and
      write() to various x86-only drivers that in the meantime started using the
      definitions in the x86 version of <asm/io.h>.  However as discussed
      exhaustively, this is actually the right thing to do, because the right
      way to split a 64-bit transaction is hardware dependent and therefore
      belongs in the hardware driver (eg mpt2sas needs a spinlock to make sure
      no other accesses occur in between the two halves of the access).
      
      Build tested on 32- and 64-bit x86 allmodconfig.
      
      Link: http://lkml.kernel.org/r/x86-32-writeq-is-broken@mdm.bga.comAcked-by: NHitoshi Mitake <h.mitake@gmail.com>
      Cc: Kashyap Desai <Kashyap.Desai@lsi.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ravi Anand <ravi.anand@qlogic.com>
      Cc: Vikas Chaudhary <vikas.chaudhary@qlogic.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Acked-by: NJames Bottomley <James.Bottomley@parallels.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dbee8a0a
    • R
      x86: Reorder mm_context_t to remove x86_64 alignment padding and thus shrink mm_struct · af6a25f0
      Richard Kennedy 提交于
      Reorder mm_context_t to remove alignment padding on 64 bit
      builds shrinking its size from 64 to 56 bytes.
      
      This allows mm_struct to shrink from 840 to 832 bytes, so using
      one fewer cache lines, and getting more objects per slab when
      using slub.
      
      slabinfo mm_struct reports
      before :-
      
          Sizes (bytes)     Slabs
          -----------------------------------
          Object :     840  Total  :       7
          SlabObj:     896  Full   :       1
          SlabSiz:   16384  Partial:       4
          Loss   :      56  CpuSlab:       2
          Align  :      64  Objects:      18
      
      after :-
      
          Sizes (bytes)     Slabs
          ----------------------------------
          Object :     832  Total  :       7
          SlabObj:     832  Full   :       1
          SlabSiz:   16384  Partial:       4
          Loss   :       0  CpuSlab:       2
          Align  :      64  Objects:      19
      Signed-off-by: NRichard Kennedy <richard@rsk.demon.co.uk>
      Cc: wilsons@start.ca
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Link: http://lkml.kernel.org/r/1306244999.1999.5.camel@castor.rskSigned-off-by: NIngo Molnar <mingo@elte.hu>
      af6a25f0
    • C
      x86, UV: Clean up uv_tlb.c · f073cc8f
      Cliff Wickman 提交于
      SGI UV's uv_tlb.c driver has become rather hard to read, with overly large
      functions, non-standard coding style and (way) too long variable, constant
      and function names and non-obvious code flow sequences.
      
      This patch improves the readability and maintainability of the driver
      significantly, by doing the following strict code cleanups with no side
      effects:
      
       - Split long functions into shorter logical functions.
      
       - Shortened some variable and structure member names.
      
       - Added special functions for reads and writes of MMR regs with
         very long names.
      
       - Added the 'tunables' table to shortened tunables_write().
      
       - Added the 'stat_description' table to shorten uv_ptc_proc_write().
      
       - Pass fewer 'stat' arguments where it can be derived from the 'bcp'
         argument.
      
       - Function definitions consistent on one line, and inline in few (short) cases.
      
       - Moved some small structures and an atomic inline function to the header file.
      
       - Moved some local variables to the blocks where they are used.
      
       - Updated the copyright date.
      
       - Shortened uv_write_global_mmr64() etc. using some aliasing; no
         line breaks. Renamed many uv_.. functions that are not exported.
      
       - Aligned structure fields.
          [ note that not all structures are aligned the same way though; I'd like
            to keep the extensive commenting in some of them. ]
      
       - Shortened some long structure names.
      
       - Standard pass/fail exit from init_per_cpu()
      
       - Vertical alignment for mass initializations.
      
       - More separation between blocks of code.
      
      Tested on a 16-processor Altix UV.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: penberg@kernel.org
      Link: http://lkml.kernel.org/r/E1QOw12-0004MN-Lp@eag09.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      f073cc8f
    • J
      x86, UV: Add support for SGI UV2 hub chip · 2a919596
      Jack Steiner 提交于
      This patch adds support for a new version of the SGI UV hub
      chip. The hub chip is the node controller that connects multiple
      blades into a larger coherent SSI.
      
      For the most part, UV2 is compatible with UV1. The majority of
      the changes are in the addresses of MMRs and in a few cases, the
      contents of MMRs. These changes are the result in changes in the
      system topology such as node configuration, processor types,
      maximum nodes, physical address sizes, etc.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/20110511175028.GA18006@sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      2a919596
    • K
      x86, cpufeature: Update CPU feature RDRND to RDRAND · 7ccafc5f
      Kees Cook 提交于
      The Intel manual changed the name of the CPUID bit to match the
      instruction name. We should follow suit for sanity's sake. (See Intel SDM
      Volume 2, Table 3-20 "Feature Information Returned in the ECX Register".)
      
      [ hpa: we can only do this at this time because there are currently no CPUs
        with this feature on the market, hence this is pre-hardware enabling.
        However, Cc:'ing stable so that stable can present a consistent ABI. ]
      Signed-off-by: NKees Cook <kees.cook@canonical.com>
      Link: http://lkml.kernel.org/r/20110524232926.GA27728@outflux.netSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: <stable@kernel.org> v2.6.36-39
      7ccafc5f
    • R
      PM / Hibernate: Remove arch_prepare_suspend() · 35425801
      Rafael J. Wysocki 提交于
      All architectures supporting hibernation define
      arch_prepare_suspend() as an empty function, so remove it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      35425801
  7. 24 5月, 2011 3 次提交
  8. 22 5月, 2011 17 次提交
  9. 21 5月, 2011 1 次提交
    • L
      sanitize <linux/prefetch.h> usage · 268bb0ce
      Linus Torvalds 提交于
      Commit e66eed65 ("list: remove prefetching from regular list
      iterators") removed the include of prefetch.h from list.h, which
      uncovered several cases that had apparently relied on that rather
      obscure header file dependency.
      
      So this fixes things up a bit, using
      
         grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
         grep -L 'prefetchw*(' $(git grep -l 'linux/prefetch.h' -- '*.[ch]')
      
      to guide us in finding files that either need <linux/prefetch.h>
      inclusion, or have it despite not needing it.
      
      There are more of them around (mostly network drivers), but this gets
      many core ones.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      268bb0ce