- 15 Dec, 2014 2 commits
-
-
Dave Hansen authored
Give MPX a real config option. The CPUs that support it (referenced here): https://software.intel.com/en-us/forums/topic/402393 are not available publicly yet. Right now only the software emulator provides MPX for the general public. [ tglx: Make it default off. There is no point in having it on right now as no hardware and no proper tooling support are available ] Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141212183836.2569D58D@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
I was writing some MPX test programs and realized that the current design makes it tricky. I did something like: bndcfgu |= bnd_dir | BNDCFGU_ENABLE; xrstor(); printf("xrstor done"); // #BR bounds exception here prctl(MPX_ENABLE_MANAGEMENT); and then compiled the app with "-fcheck-pointer-bounds -mmpx" to enable MPX instrumentation. The problem is that there is MPX instrumentation inserted in to the area of the printf(). The kernel gets a bounds exception and since management isn't yet enabled, it SIGSEGV's. Add a bit to the documentation to explain a way around this and where apps need to be careful. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141212183835.8C581B3E@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 08 Dec, 2014 1 commit
-
-
Dan Carpenter authored
We should be checking IS_ERR() here. PTR_ERR() is always true. Fixes: fe3d197f ('x86, mpx: On-demand kernel allocation of bounds tables') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Link: http://lkml.kernel.org/r/20141125172114.GA24535@mwandaSigned-off-by: Ingo Molnar <mingo@kernel.org>
-
- 22 Nov, 2014 1 commit
-
-
Dave Hansen authored
This is a follow-on to commit 62e88b1c 'mm: Make arch_unmap()/bprm_mm_init() available to all architectures' I removed the asm-generic version of arch_unmap() in that patch, but missed arch_bprm_mm_init(). So this broke the build for architectures using asm-generic/mmu_context.h who actually have an MMU. Fixes: 62e88b1c 'mm: Make arch_unmap()/bprm_mm_init() available to all architectures' Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Cc: linux-arch@vger.kernel.org Cc: x86@kernel.org Link: http://lkml.kernel.org/r/20141122163711.0F037EE6@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 19 Nov, 2014 3 commits
-
-
Dave Hansen authored
The x86 MPX patch set calls arch_unmap() and arch_bprm_mm_init() from fs/exec.c, so we need at least a stub for them in all architectures. They are only called under an #ifdef for CONFIG_MMU=y, so we can at least restict this to architectures with MMU support. blackfin/c6x have no MMU support, so do not call arch_unmap(). They also do not include mm_hooks.h or mmu_context.h at all and do not need to be touched. s390, um and unicore32 do not use asm-generic/mm_hooks.h, so got their own arch_unmap() versions. (I also moved um's arch_dup_mmap() to be closer to the other mm_hooks.h functions). xtensa only includes mm_hooks when MMU=y, which should be fine since arch_unmap() is called only from MMU=y code. For the rest, we use the stub copies of these functions in asm-generic/mm_hook.h. I cross compiled defconfigs for cris (to check NOMMU) and s390 to make sure that this works. I also checked a 64-bit build of UML and all my normal x86 builds including PARAVIRT on and off. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Cc: linux-arch@vger.kernel.org Cc: x86@kernel.org Link: http://lkml.kernel.org/r/20141118182350.8B4AA2C2@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
asm-generic/mm_hooks.h provides some generic fillers for the 90% of architectures that do not need to hook some mmap-manipulation functions. A comment inside says: > Define generic no-op hooks for arch_dup_mmap and > arch_exit_mmap, to be included in asm-FOO/mmu_context.h > for any arch FOO which doesn't need to hook these. So, does x86 need to hook these? It depends on CONFIG_PARAVIRT. We *conditionally* include this generic header if we have CONFIG_PARAVIRT=n. That's madness. With this patch, x86 stops using asm-generic/mmu_hooks.h entirely. We use our own copies of the functions. The paravirt code provides some stubs if it is disabled, and we always call those stubs in our x86-private versions of arch_exit_mmap() and arch_dup_mmap(). Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Cc: x86@kernel.org Link: http://lkml.kernel.org/r/20141118182349.14567FA5@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
get_reg_offset() used to return the register contents themselves instead of the register offset. When it did that, it was an unsigned long. I changed it to return an integer _offset_ instead of the register. But, I neglected to change the return type of the function or the variables in which we store the result of the call. This fixes up the code to clear up the warnings from the smatch bot: New smatch warnings: arch/x86/mm/mpx.c:178 mpx_get_addr_ref() warn: unsigned 'addr_offset' is never less than zero. arch/x86/mm/mpx.c:184 mpx_get_addr_ref() warn: unsigned 'base_offset' is never less than zero. arch/x86/mm/mpx.c:188 mpx_get_addr_ref() warn: unsigned 'indx_offset' is never less than zero. arch/x86/mm/mpx.c:196 mpx_get_addr_ref() warn: unsigned 'addr_offset' is never less than zero. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Cc: x86@kernel.org Link: http://lkml.kernel.org/r/20141118182343.C3E0C629@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 18 Nov, 2014 1 commit
-
-
Dave Hansen authored
We no longer need mpx.h in exec.c. This will obviously also break the build for non-x86 builds. We get the MPX includes that we need from mmu_context.h now. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141118003608.837015B3@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 17 Nov, 2014 13 commits
-
-
Qiaowei Ren authored
This patch adds the Documentation/x86/intel_mpx.txt file with some information about Intel MPX. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151832.7FDB1720@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
The previous patch allocates bounds tables on-demand. As noted in an earlier description, these can add up to *HUGE* amounts of memory. This has caused OOMs in practice when running tests. This patch adds support for freeing bounds tables when they are no longer in use. There are two types of mappings in play when unmapping tables: 1. The mapping with the actual data, which userspace is munmap()ing or brk()ing away, etc... 2. The mapping for the bounds table *backing* the data (is tagged with VM_MPX, see the patch "add MPX specific mmap interface"). If userspace use the prctl() indroduced earlier in this patchset to enable the management of bounds tables in kernel, when it unmaps the first type of mapping with the actual data, the kernel needs to free the mapping for the bounds table backing the data. This patch hooks in at the very end of do_unmap() to do so. We look at the addresses being unmapped and find the bounds directory entries and tables which cover those addresses. If an entire table is unused, we clear associated directory entry and free the table. Once we unmap the bounds table, we would have a bounds directory entry pointing at empty address space. That address space might now be allocated for some other (random) use, and the MPX hardware might now try to walk it as if it were a bounds table. That would be bad. So any unmapping of an enture bounds table has to be accompanied by a corresponding write to the bounds directory entry to invalidate it. That write to the bounds directory can fault, which causes the following problem: Since we are doing the freeing from munmap() (and other paths like it), we hold mmap_sem for write. If we fault, the page fault handler will attempt to acquire mmap_sem for read and we will deadlock. To avoid the deadlock, we pagefault_disable() when touching the bounds directory entry and use a get_user_pages() to resolve the fault. The unmapping of bounds tables happends under vm_munmap(). We also (indirectly) call vm_munmap() to _do_ the unmapping of the bounds tables. We avoid unbounded recursion by disallowing freeing of bounds tables *for* bounds tables. This would not occur normally, so should not have any practical impact. Being strict about it here helps ensure that we do not have an exploitable stack overflow. Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151831.E4531C4A@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
This is really the meat of the MPX patch set. If there is one patch to review in the entire series, this is the one. There is a new ABI here and this kernel code also interacts with userspace memory in a relatively unusual manner. (small FAQ below). Long Description: This patch adds two prctl() commands to provide enable or disable the management of bounds tables in kernel, including on-demand kernel allocation (See the patch "on-demand kernel allocation of bounds tables") and cleanup (See the patch "cleanup unused bound tables"). Applications do not strictly need the kernel to manage bounds tables and we expect some applications to use MPX without taking advantage of this kernel support. This means the kernel can not simply infer whether an application needs bounds table management from the MPX registers. The prctl() is an explicit signal from userspace. PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to require kernel's help in managing bounds tables. PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel won't allocate and free bounds tables even if the CPU supports MPX. PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds directory out of a userspace register (bndcfgu) and then cache it into a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT will set "bd_addr" to an invalid address. Using this scheme, we can use "bd_addr" to determine whether the management of bounds tables in kernel is enabled. Also, the only way to access that bndcfgu register is via an xsaves, which can be expensive. Caching "bd_addr" like this also helps reduce the cost of those xsaves when doing table cleanup at munmap() time. Unfortunately, we can not apply this optimization to #BR fault time because we need an xsave to get the value of BNDSTATUS. ==== Why does the hardware even have these Bounds Tables? ==== MPX only has 4 hardware registers for storing bounds information. If MPX-enabled code needs more than these 4 registers, it needs to spill them somewhere. It has two special instructions for this which allow the bounds to be moved between the bounds registers and some new "bounds tables". They are similar conceptually to a page fault and will be raised by the MPX hardware during both bounds violations or when the tables are not present. This patch handles those #BR exceptions for not-present tables by carving the space out of the normal processes address space (essentially calling the new mmap() interface indroduced earlier in this patch set.) and then pointing the bounds-directory over to it. The tables *need* to be accessed and controlled by userspace because the instructions for moving bounds in and out of them are extremely frequent. They potentially happen every time a register pointing to memory is dereferenced. Any direct kernel involvement (like a syscall) to access the tables would obviously destroy performance. ==== Why not do this in userspace? ==== This patch is obviously doing this allocation in the kernel. However, MPX does not strictly *require* anything in the kernel. It can theoretically be done completely from userspace. Here are a few ways this *could* be done. I don't think any of them are practical in the real-world, but here they are. Q: Can virtual space simply be reserved for the bounds tables so that we never have to allocate them? A: As noted earlier, these tables are *HUGE*. An X-GB virtual area needs 4*X GB of virtual space, plus 2GB for the bounds directory. If we were to preallocate them for the 128TB of user virtual address space, we would need to reserve 512TB+2GB, which is larger than the entire virtual address space today. This means they can not be reserved ahead of time. Also, a single process's pre-popualated bounds directory consumes 2GB of virtual *AND* physical memory. IOW, it's completely infeasible to prepopulate bounds directories. Q: Can we preallocate bounds table space at the same time memory is allocated which might contain pointers that might eventually need bounds tables? A: This would work if we could hook the site of each and every memory allocation syscall. This can be done for small, constrained applications. But, it isn't practical at a larger scale since a given app has no way of controlling how all the parts of the app might allocate memory (think libraries). The kernel is really the only place to intercept these calls. Q: Could a bounds fault be handed to userspace and the tables allocated there in a signal handler instead of in the kernel? A: (thanks to tglx) mmap() is not on the list of safe async handler functions and even if mmap() would work it still requires locking or nasty tricks to keep track of the allocation state there. Having ruled out all of the userspace-only approaches for managing bounds tables that we could think of, we create them on demand in the kernel. Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
This patch sets bound violation fields of siginfo struct in #BR exception handler by decoding the user instruction and constructing the faulting pointer. We have to be very careful when decoding these instructions. They are completely controlled by userspace and may be changed at any time up to and including the point where we try to copy them in to the kernel. They may or may not be MPX instructions and could be completely invalid for all we know. Note: This code is based on Qiaowei Ren's specialized MPX decoder, but uses the generic decoder whenever possible. It was tested for robustness by generating a completely random data stream and trying to decode that stream. I also unmapped random pages inside the stream to test the "partial instruction" short read code. We kzalloc() the siginfo instead of stack allocating it because we need to memset() it anyway, and doing this makes it much more clear when it got initialized by the MPX instruction decoder. Changes from the old decoder: * Use the generic decoder instead of custom functions. Saved ~70 lines of code overall. * Remove insn->addr_bytes code (never used??) * Make sure never to possibly overflow the regoff[] array, plus check the register range correctly in 32 and 64-bit modes. * Allow get_reg() to return an error and have mpx_get_addr_ref() handle when it sees errors. * Only call insn_get_*() near where we actually use the values instead if trying to call them all at once. * Handle short reads from copy_from_user() and check the actual number of read bytes against what we expect from insn_get_length(). If a read stops in the middle of an instruction, we error out. * Actually check the opcodes intead of ignoring them. * Dynamically kzalloc() siginfo_t so we don't leak any stack data. * Detect and handle decoder failures instead of ignoring them. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151828.5BDD0915@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Qiaowei Ren authored
We have chosen to perform the allocation of bounds tables in kernel (See the patch "on-demand kernel allocation of bounds tables") and to mark these VMAs with VM_MPX. However, there is currently no suitable interface to actually do this. Existing interfaces, like do_mmap_pgoff(), have no way to set a modified ->vm_ops or ->vm_flags and don't hold mmap_sem long enough to let a caller do it. This patch wraps mmap_region() and hold mmap_sem long enough to make the modifications to the VMA which we need. Also note the 32/64-bit #ifdef in the header. We actually need to do this at runtime eventually. But, for now, we don't support running 32-bit binaries on 64-bit kernels. Support for this will come in later patches. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151827.CE440F67@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Qiaowei Ren authored
MPX-enabled applications using large swaths of memory can potentially have large numbers of bounds tables in process address space to save bounds information. These tables can take up huge swaths of memory (as much as 80% of the memory on the system) even if we clean them up aggressively. In the worst-case scenario, the tables can be 4x the size of the data structure being tracked. IOW, a 1-page structure can require 4 bounds-table pages. Being this huge, our expectation is that folks using MPX are going to be keen on figuring out how much memory is being dedicated to it. So we need a way to track memory use for MPX. If we want to specifically track MPX VMAs we need to be able to distinguish them from normal VMAs, and keep them from getting merged with normal VMAs. A new VM_ flag set only on MPX VMAs does both of those things. With this flag, MPX bounds-table VMAs can be distinguished from other VMAs, and userspace can also walk /proc/$pid/smaps to get memory usage for MPX. In addition to this flag, we also introduce a special ->vm_ops specific to MPX VMAs (see the patch "add MPX specific mmap interface"), but currently different ->vm_ops do not by themselves prevent VMA merging, so we still need this flag. We understand that VM_ flags are scarce and are open to other options. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151825.565625B3@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
This allows us to use cpu_feature_enabled(X86_FEATURE_MPX) as both a runtime and compile-time check. When CONFIG_X86_INTEL_MPX is disabled, cpu_feature_enabled(X86_FEATURE_MPX) will evaluate at compile-time to 0. If CONFIG_X86_INTEL_MPX=y, then the cpuid flag will be checked at runtime. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Qiaowei Ren <qiaowei.ren@intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151823.B358EAD2@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Qiaowei Ren authored
New fields about bound violation are added into general struct siginfo. This will impact MIPS and IA64, which extend general struct siginfo. This patch syncs this struct for IA64 with general version. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151822.82B3B486@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Qiaowei Ren authored
New fields about bound violation are added into general struct siginfo. This will impact MIPS and IA64, which extend general struct siginfo. This patch syncs this struct for MIPS with general version. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151820.F7EDC3CC@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Qiaowei Ren authored
This patch adds new fields about bound violation into siginfo structure. si_lower and si_upper are respectively lower bound and upper bound when bound violation is caused. Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141114151819.1908C900@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
According to Intel SDM extension, MPX configuration and status registers should be BNDCFGU and BNDSTATUS. This patch renames cfg_reg_u and status_reg to bndcfgu and bndstatus. [ tglx: Renamed 'struct bndscr_struct' to 'struct bndscr' ] Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-mips@linux-mips.org Cc: Dave Hansen <dave@sr71.net> Cc: Qiaowei Ren <qiaowei.ren@intel.com> Link: http://lkml.kernel.org/r/20141114151817.031762AC@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
Consider the bndX MPX registers. There 4 registers each containing a 64-bit lower and a 64-bit upper bound. That's 8*64 bits and we declare it thusly: struct bndregs_struct { u64 bndregs[8]; } Let's say you want to read the upper bound from the MPX register bnd2 out of the xsave buf. You do: bndregno = 2; upper_bound = xsave_buf->bndregs.bndregs[2*bndregno+1]; That kinda sucks. Every time you access it, you need to know: 1. Each bndX register is two entries wide in "bndregs" 2. The lower comes first followed by upper. We do the +1 to get upper vs. lower. This replaces the old definition. You can now access them indexed by the register number directly, and with a meaningful name for the lower and upper bound: bndregno = 2; xsave_buf->bndreg[bndregno].upper_bound; It's now *VERY* clear that there are 4 registers. The programmer now doesn't have to care what order the lower and upper bounds are in, and it's harder to get it wrong. [ tglx: Changed ub/lb to upper_bound/lower_bound and renamed struct bndreg_struct to struct bndreg ] Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@linux.intel.com> Cc: Qiaowei Ren <qiaowei.ren@intel.com> Cc: "Yu, Fenghua" <fenghua.yu@intel.com> Cc: Dave Hansen <dave@sr71.net> Link: http://lkml.kernel.org/r/20141031215820.5EA5E0EC@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Dave Hansen authored
The current x86 instruction decoder steps along through the instruction stream but always ensures that it never steps farther than the largest possible instruction size (MAX_INSN_SIZE). The MPX code is now going to be doing some decoding of userspace instructions. We copy those from userspace in to the kernel and they're obviously completely untrusted coming from userspace. In addition to the constraint that instructions can only be so long, we also have to be aware of how long the buffer is that came in from userspace. This _looks_ to be similar to what the perf and kprobes is doing, but it's unclear to me whether they are affected. The whole reason we need this is that it is perfectly valid to be executing an instruction within MAX_INSN_SIZE bytes of an unreadable page. We should be able to gracefully handle short reads in those cases. This adds support to the decoder to record how long the buffer being decoded is and to refuse to "validate" the instruction if we would have gone over the end of the buffer to decode it. The kprobes code probably needs to be looked at here a bit more carefully. This patch still respects the MAX_INSN_SIZE limit there but the kprobes code does look like it might be able to be a bit more strict than it currently is. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Jim Keniston <jkenisto@us.ibm.com> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: x86@kernel.org Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Link: http://lkml.kernel.org/r/20141114153957.E6B01535@viggo.jf.intel.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 09 Nov, 2014 10 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fixes from Catalin Marinas: - enable bpf syscall for compat - cpu_suspend fix when checking the idle state type - defconfig update * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: defconfig: update defconfig for 3.18 arm64: compat: Enable bpf syscall arm64: psci: fix cpu_suspend to check idle state type for index
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "Another quiet week: - a fix to silence edma probe error on non-supported platforms from Arnd - a fix to enable the PL clock for Parallella, to make mainline usable with the SDK. - a somewhat verbose fix for the PLL clock tree on VF610 - enabling of SD/MMC on one of the VF610-based boards (for testing) - a fix for i.MX where CONFIG_SPI used to be implicitly enabled and now needs to be added to the defconfig instead - another maintainer added for bcm2835: Lee Jones" * tag 'armsoc-for-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: zynq: Enable PL clocks for Parallella dma: edma: move device registration to platform code ARM: dts: vf610: add SD node to cosmic dts MAINTAINERS: update bcm2835 entry ARM: imx: Fix the removal of CONFIG_SPI option ARM: imx: clk-vf610: define PLL's clock tree
-
git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linuxLinus Torvalds authored
Pull devicetree bugfix from Grant Likely: "One buffer overflow bug that shouldn't be left around" * 'devicetree/merge' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux: of: Fix overflow bug in string property parsing functions
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fix from Chris Mason: "It's a one liner for an error cleanup path that leads to crashes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: fix kfree on list_head in btrfs_lookup_csums_range error cleanup
-
Linus Torvalds authored
Merge tag 'driver-core-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are 3 tiny fixes for 3.18-rc4. One fixes up a long-stading race condition in the driver core for removing directories in /sys/devices/virtual/ and the other 2 fix up the wording of a new Kconfig option that was added in 3.18-rc1" * tag 'driver-core-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: tiny: rename ENABLE_DEV_COREDUMP to ALLOW_DEV_COREDUMP tiny: reverse logic for DISABLE_DEV_COREDUMP sysfs: driver core: Fix glue dir race condition by gdp_mutex
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging driver fixes from Greg KH: "Here are some staging/iio fixes for 3.18-rc4. Nothing major, just a few bugfixes of things that have been reported" * tag 'staging-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging:iio:ade7758: Remove "raw" from channel name staging:iio:ade7758: Fix check if channels are enabled in prenable staging:iio:ade7758: Fix NULL pointer deref when enabling buffer iio: as3935: allocate correct iio_device size io: accel: kxcjk-1013: Fix iio_event_spec direction iio: tsl4531: Fix compiler error when CONFIG_PM_OPS is not defined iio: adc: mxs-lradc: Disable the clock on probe failure iio: st_sensors: Fix buffer copy staging:iio:ad5933: Drop "raw" from channel names staging:iio:ad5933: Fix NULL pointer deref when enabling buffer
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty/serial fixes from Greg KH: "Here are some tiny serial/tty fixes for 3.18-rc4 that resolve some reported issues" * tag 'tty-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: Fix pty master poll() after slave closes v2 serial: of-serial: fix uninitialized kmalloc variable tty/vt: don't set font mappings on vc not supporting this tty: serial: 8250_mtk: Fix quot calculation tty: Prevent "read/write wait queue active!" log flooding tty: Fix high cpu load if tty is unreleaseable serial: Fix divide-by-zero fault in uart_get_divisor()
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are some USB fixes for 3.18-rc4. Just a bunch of little fixes resolving reported issues and new device ids for existing drivers. Full details are in the shortlog" * tag 'usb-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (26 commits) USB: Update default usb-storage delay_use value in kernel-parameters.txt USB: cdc-acm: add quirk for control-line state requests phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly USB: storage: Fix timeout in usb_stor_euscsi_init() and usb_stor_huawei_e220_init() USB: cdc-acm: only raise DTR on transitions from B0 Revert "storage: Replace magic number with define in usb_stor_euscsi_init()" usb: core: notify disconnection when core detects disconnect usb: core: need to call usb_phy_notify_connect after device setup uas: Add US_FL_NO_ATA_1X quirk for 2 more Seagate models xhci: no switching back on non-ULT Haswell USB: quirks: enable device-qualifier quirk for yet another Elan touchscreen USB: quirks: enable device-qualifier quirk for another Elan touchscreen MAINTAINERS: Remove duplicate entry for usbip driver usb: storage: fix build warnings !CONFIG_PM usb: Remove references to non-existent PLAT_S5P symbol uas: Add NO_ATA_1X for VIA VL711 devices xhci: Disable streams on Asmedia 1042 xhci controllers USB: HWA: fix a warning message uas: Add US_FL_NO_ATA_1X quirk for 1 more Seagate model usb-storage: handle a skipped data phase ...
-
Andreas Färber authored
The Parallella board comes with a U-Boot bootloader that loads one of two predefined FPGA bitstreams before booting the kernel. Both define an AXI interface to the on-board Epiphany processor. Enable clocks FCLK0..FCLK3 for the Programmable Logic by default. Otherwise accessing, e.g., the ESYSRESET register freezes the board, as seen with the Epiphany SDK tools e-reset and e-hw-rev, using /dev/mem. Cc: <stable@vger.kernel.org> # 3.17.x Signed-off-by: Andreas Färber <afaerber@suse.de> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
- 08 Nov, 2014 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c bugfixes from Wolfram Sang: "One bigger cleanup (FSF address removal) and two bugfixes for I2C" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: core: Dispose OF IRQ mapping at client removal time i2c: at91: don't account as iowait i2c: remove FSF address
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "Two fixlets for the armada SoC interrupt controller" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip: armada-370-xp: Fix MPIC interrupt handling irqchip: armada-370-xp: Fix MSI interrupt handling
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
Pull media fixes from Mauro Carvalho Chehab: "For: - some regression fixes at the Remote Controller core and imon driver - a build fix for certain randconfigs with ir-hix5hd2 - don't feed power to satellite system at ds3000 driver init It also contains some fixes for drivers added for Kernel 3.18: - some fixes at the new ISDB-S driver, and the corresponding bits to fix some descriptors for this Japanese TV standard at the DVB core - two warning cleanups for sp2 driver if PM is disabled - change the default mode for the new vivid driver" * git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: [media] sp2: sp2_init() can be static [media] dvb:tc90522: fix always-false expression [media] dvb-core: set default properties of ISDB-S [media] dvb:tc90522: fix stats report [media] vivid: default to single planar device instances [media] imon: fix other RC type protocol support [media] ir-hix5hd2 fix build warning [media] ds3000: fix LNB supply voltage on Tevii S480 on initialization [media] rc5-decoder: BZ#85721: Fix RC5-SZ decoding [media] rc-core: fix protocol_change regression in ir_raw_event_register
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull MIPS updates from Ralf Baechle: "This weeks' round of MIPS bug fixes for 3.18: - wire up the bpf syscall - fix TLB dump output for R3000 class TLBs - fix strnlen_user return value if no NUL character was found. - fix build with binutils 2.24.51+. While there is no binutils 2.25 release yet, toolchains derived from binutils 2.24.51+ are already in common use. - the Octeon GPIO code forgot to offline GPIO IRQs. - fix build error for XLP. - fix possible BUG assertion with EVA for CMA" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: Fix build with binutils 2.24.51+ MIPS: R3000: Fix debug output for Virtual page number MIPS: Fix strnlen_user() return value in case of overlong strings. MIPS: CMA: Do not reserve memory if not required MIPS: Wire up bpf syscall. MIPS/Xlp: Remove the dead function destroy_irq() to fix build error MIPS: Octeon: Make Octeon GPIO IRQ chip CPU hotplug-aware
-
- 07 Nov, 2014 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfsLinus Torvalds authored
Pull xfs fixes from Dave Chinner: "This update fixes a warning in the new pagecache_isize_extended() and updates some related comments, another fix for zero-range misbehaviour, and an unforntuately large set of fixes for regressions in the bulkstat code. The bulkstat fixes are large but necessary. I wouldn't normally push such a rework for a -rcX update, but right now xfsdump can silently create incomplete dumps on 3.17 and it's possible that even xfsrestore won't notice that the dumps were incomplete. Hence we need to get this update into 3.17-stable kernels ASAP. In more detail, the refactoring work I committed in 3.17 has exposed a major hole in our QA coverage. With both xfsdump (the major user of bulkstat) and xfsrestore silently ignoring missing files in the dump/restore process, incomplete dumps were going unnoticed if they were being triggered. Many of the dump/restore filesets were so small that they didn't evenhave a chance of triggering the loop iteration bugs we introduced in 3.17, so we didn't exercise the code sufficiently, either. We have already taken steps to improve QA coverage in xfstests to avoid this happening again, and I've done a lot of manual verification of dump/restore on very large data sets (tens of millions of inodes) of the past week to verify this patch set results in bulkstat behaving the same way as it does on 3.16. Unfortunately, the fixes are not exactly simple - in tracking down the problem historic API warts were discovered (e.g xfsdump has been working around a 20 year old bug in the bulkstat API for the past 10 years) and so that complicated the process of diagnosing and fixing the problems. i.e. we had to fix bugs in the code as well as discover and re-introduce the userspace visible API bugs that we unwittingly "fixed" in 3.17 that xfsdump relied on to work correctly. Summary: - incorrect warnings about i_mutex locking in pagecache_isize_extended() and updates comments to match expected locking - another zero-range bug fix for stray file size updates - a bunch of fixes for regression in the bulkstat code introduced in 3.17" * tag 'xfs-for-linus-3.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs: xfs: track bulkstat progress by agino xfs: bulkstat error handling is broken xfs: bulkstat main loop logic is a mess xfs: bulkstat chunk-formatter has issues xfs: bulkstat chunk formatting cursor is broken xfs: bulkstat btree walk doesn't terminate mm: Fix comment before truncate_setsize() xfs: rework zero range to prevent invalid i_size updates mm: Remove false WARN_ON from pagecache_isize_extended() xfs: Check error during inode btree iteration in xfs_bulkstat() xfs: bulkstat doesn't release AGI buffer on error
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulatorLinus Torvalds authored
Pull regulator fixes from Mark Brown: "More changes than I'd like here, most of them for a single bug repeated in a bunch of drivers with data not being initialized correctly, plus a fix to lower the severity of a warning introduced in the last merge window which can legitimately go off so we don't want to alarm users excessively" * tag 'regulator-v3.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: s2mpa01: zero-initialize regulator match table array regulator: max8660: zero-initialize regulator match table array regulator: max77802: zero-initialize regulator match table regulator: max77686: zero-initialize regulator match table regulator: max1586: zero-initialize regulator match table array regulator: max77693: Fix use of uninitialized regulator config regulator: of: Lower the severity of the error with no container
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spiLinus Torvalds authored
Pull spi bugfixes from Mark Brown: "A couple of small driver fixes for v3.18, both quite problematic if you hit a use case that's affected" * tag 'spi-v3.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: pxa2xx: toggle clocks on suspend if not disabled by runtime PM spi: fsl-dspi: Fix CTAR selection
-
Johannes Berg authored
The ENABLE_DEV_COREDUMP option is misleading as it implies that it gets the framework enabled, this isn't true it just allows it to get enabled if a driver needs it. Rename it to ALLOW_DEV_COREDUMP to better capture its semantics. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Acked-by: Aristeu Rozanski <aris@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aristeu Rozanski authored
It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the option to ENABLE_DEV_COREDUMP and setting it to 'n' (as in allnconfig or tinyconfig) will effectively disable device coredump. Cc: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Aristeu Rozanski <arozansk@redhat.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-