1. 25 1月, 2013 2 次提交
    • A
      x86/msr: Add capabilities check · c903f045
      Alan Cox 提交于
      At the moment the MSR driver only relies upon file system
      checks. This means that anything as root with any capability set
      can write to MSRs. Historically that wasn't very interesting but
      on modern processors the MSRs are such that writing to them
      provides several ways to execute arbitary code in kernel space.
      Sample code and documentation on doing this is circulating and
      MSR attacks are used on Windows 64bit rootkits already.
      
      In the Linux case you still need to be able to open the device
      file so the impact is fairly limited and reduces the security of
      some capability and security model based systems down towards
      that of a generic "root owns the box" setup.
      
      Therefore they should require CAP_SYS_RAWIO to prevent an
      elevation of capabilities. The impact of this is fairly minimal
      on most setups because they don't have heavy use of
      capabilities. Those using SELinux, SMACK or AppArmor rules might
      want to consider if their rulesets on the MSR driver could be
      tighter.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Horses <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c903f045
    • M
      x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES · 73b664ce
      Maarten Lankhorst 提交于
      I ran out of free entries when I had CONFIG_DMA_API_DEBUG
      enabled. Some other archs seem to default to 65536, so increase
      this limit for x86 too.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Link: http://lkml.kernel.org/r/50A612AA.7040206@canonical.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ----
      73b664ce
  2. 24 1月, 2013 3 次提交
  3. 20 1月, 2013 1 次提交
    • H
      x86-32: Start out cr0 clean, disable paging before modifying cr3/4 · 021ef050
      H. Peter Anvin 提交于
      Patch
      
        5a5a51db x86-32: Start out eflags and cr4 clean
      
      ... made x86-32 match x86-64 in that we initialize %eflags and %cr4
      from scratch.  This broke OLPC XO-1.5, because the XO enters the
      kernel with paging enabled, which the kernel doesn't expect.
      
      Since we no longer support 386 (the source of most of the variability
      in %cr0 configuration), we can simply match further x86-64 and
      initialize %cr0 to a fixed value -- the one variable part remaining in
      %cr0 is for FPU control, but all that is handled later on in
      initialization; in particular, configuring %cr0 as if the FPU is
      present until proven otherwise is correct and necessary for the probe
      to work.
      
      To deal with the XO case sanely, explicitly disable paging in %cr0
      before we muck with %cr3, %cr4 or EFER -- those operations are
      inherently unsafe with paging enabled.
      
      NOTE: There is still a lot of 386-related junk in head_32.S which we
      can and should get rid of, however, this is intended as a minimal fix
      whereas the cleanup can be deferred to the next merge window.
      Reported-by: NAndres Salomon <dilinger@queued.net>
      Tested-by: NDaniel Drake <dsd@laptop.org>
      Link: http://lkml.kernel.org/r/50FA0661.2060400@linux.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      021ef050
  4. 14 1月, 2013 2 次提交
  5. 12 1月, 2013 1 次提交
    • J
      x86/Sandy Bridge: reserve pages when integrated graphics is present · a9acc536
      Jesse Barnes 提交于
      SNB graphics devices have a bug that prevent them from accessing certain
      memory ranges, namely anything below 1M and in the pages listed in the
      table.  So reserve those at boot if set detect a SNB gfx device on the
      CPU to avoid GPU hangs.
      
      Stephane Marchesin had a similar patch to the page allocator awhile
      back, but rather than reserving pages up front, it leaked them at
      allocation time.
      
      [ hpa: made a number of stylistic changes, marked arrays as static
        const, and made less verbose; use "memblock=debug" for full
        verbosity. ]
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a9acc536
  6. 08 1月, 2013 1 次提交
  7. 04 1月, 2013 1 次提交
    • G
      X86: drivers: remove __dev* attributes. · a18e3690
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitconst,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Daniel Drake <dsd@laptop.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18e3690
  8. 27 12月, 2012 1 次提交
  9. 21 12月, 2012 1 次提交
  10. 20 12月, 2012 7 次提交
  11. 19 12月, 2012 2 次提交
  12. 18 12月, 2012 5 次提交
  13. 16 12月, 2012 2 次提交
  14. 15 12月, 2012 1 次提交
  15. 14 12月, 2012 1 次提交
    • K
      module: add syscall to load module from fd · 34e1169d
      Kees Cook 提交于
      As part of the effort to create a stronger boundary between root and
      kernel, Chrome OS wants to be able to enforce that kernel modules are
      being loaded only from our read-only crypto-hash verified (dm_verity)
      root filesystem. Since the init_module syscall hands the kernel a module
      as a memory blob, no reasoning about the origin of the blob can be made.
      
      Earlier proposals for appending signatures to kernel modules would not be
      useful in Chrome OS, since it would involve adding an additional set of
      keys to our kernel and builds for no good reason: we already trust the
      contents of our root filesystem. We don't need to verify those kernel
      modules a second time. Having to do signature checking on module loading
      would slow us down and be redundant. All we need to know is where a
      module is coming from so we can say yes/no to loading it.
      
      If a file descriptor is used as the source of a kernel module, many more
      things can be reasoned about. In Chrome OS's case, we could enforce that
      the module lives on the filesystem we expect it to live on.  In the case
      of IMA (or other LSMs), it would be possible, for example, to examine
      extended attributes that may contain signatures over the contents of
      the module.
      
      This introduces a new syscall (on x86), similar to init_module, that has
      only two arguments. The first argument is used as a file descriptor to
      the module and the second argument is a pointer to the NULL terminated
      string of module arguments.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (merge fixes)
      34e1169d
  16. 13 12月, 2012 4 次提交
  17. 12 12月, 2012 5 次提交
    • M
      mm: use vm_unmapped_area() in hugetlbfs on i386 architecture · cdc17344
      Michel Lespinasse 提交于
      Update the i386 hugetlb_get_unmapped_area function to make use of
      vm_unmapped_area() instead of implementing a brute force search.
      
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cdc17344
    • M
      mm: fix cache coloring on x86_64 architecture · 7d025059
      Michel Lespinasse 提交于
      Fix the x86-64 cache alignment code to take pgoff into account.  Use the
      x86 and MIPS cache alignment code as the basis for a generic cache
      alignment function.
      
      The old x86 code will always align the mmap to aliasing boundaries,
      even if the program mmaps the file with a non-zero pgoff.
      
      If program A mmaps the file with pgoff 0, and program B mmaps the file
      with pgoff 1.  The old code would align the mmaps, resulting in misaligned
      pages:
      
        A:  0123
        B:  123
      
      After this patch, they are aligned so the pages line up:
      
        A: 0123
        B:  123
      
      Proposed by Rik van Riel.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d025059
    • M
      mm: use vm_unmapped_area() on x86_64 architecture · f9902472
      Michel Lespinasse 提交于
      Update the x86_64 arch_get_unmapped_area[_topdown] functions to make use
      of vm_unmapped_area() instead of implementing a brute force search.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f9902472
    • A
      mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB · 42d7395f
      Andi Kleen 提交于
      There was some desire in large applications using MAP_HUGETLB or
      SHM_HUGETLB to use 1GB huge pages on some mappings, and stay with 2MB on
      others.  This is useful together with NUMA policy: use 2MB interleaving
      on some mappings, but 1GB on local mappings.
      
      This patch extends the IPC/SHM syscall interfaces slightly to allow
      specifying the page size.
      
      It borrows some upper bits in the existing flag arguments and allows
      encoding the log of the desired page size in addition to the *_HUGETLB
      flag.  When 0 is specified the default size is used, this makes the
      change fully compatible.
      
      Extending the internal hugetlb code to handle this is straight forward.
      Instead of a single mount it just keeps an array of them and selects the
      right mount based on the specified page size.  When no page size is
      specified it uses the mount of the default page size.
      
      The change is not visible in /proc/mounts because internal mounts don't
      appear there.  It also has very little overhead: the additional mounts
      just consume a super block, but not more memory when not used.
      
      I also exported the new flags to the user headers (they were previously
      under __KERNEL__).  Right now only symbols for x86 and some other
      architecture for 1GB and 2MB are defined.  The interface should already
      work for all other architectures though.  Only architectures that define
      multiple hugetlb sizes actually need it (that is currently x86, tile,
      powerpc).  However tile and powerpc have user configurable hugetlb
      sizes, so it's not easy to add defines.  A program on those
      architectures would need to query sysfs and use the appropiate log2.
      
      [akpm@linux-foundation.org: cleanups]
      [rientjes@google.com: fix build]
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Acked-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42d7395f
    • G
      KVM: emulator: fix real mode segment checks in address linearization · 58b7825b
      Gleb Natapov 提交于
      In real mode CS register is writable, so do not #GP on write.
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      58b7825b