futex: Prevent attaching to kernel threads

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Dave Jones <davej@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Darren Hart <darren@...art.com>
Cc: Davidlohr Bueso <davidlohr@...com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Clark Williams <williams@...hat.com>
Cc: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Roland McGrath <roland@...k.frob.com>
Cc: Carlos ODonell <carlos@...hat.com>
Cc: Jakub Jelinek <jakub@...hat.com>
Cc: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@...utronix.de
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Change-Id: I7444c58d00cbded35b078331a8740e8431cb13a5
futex: Add another early deadlock detection check

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
  http://lkml.kernel.org/r/20140429151655.GA14277@...hat.com

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Dave Jones <davej@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Darren Hart <darren@...art.com>
Cc: Davidlohr Bueso <davidlohr@...com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Clark Williams <williams@...hat.com>
Cc: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Roland McGrath <roland@...k.frob.com>
Cc: Carlos ODonell <carlos@...hat.com>
Cc: Jakub Jelinek <jakub@...hat.com>
Cc: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@...utronix.de
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Change-Id: I245f77622443435cf36bbd157b98798c235acdb0
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

If uaddr == uaddr2, then we have broken the rule of only requeueing
from a non-pi futex to a pi futex with this call. If we attempt this,
then dangling pointers may be left for rt_waiter resulting in an
exploitable condition.

This change brings futex_requeue() into line with
futex_wait_requeue_pi() which performs the same check as per commit
6f7b0a2a5 (futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi())

[ tglx: Compare the resulting keys as well, as uaddrs might be
  	different depending on the mapping ]

Fixes CVE-2014-3153.

Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Change-Id: Iea1dfe1d877d63a374db2623dca6cea4e7a544b9
futex: Validate atomic acquisition in futex_lock_pi_atomic()

We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.

Verify whether the futex has waiters associated with kernel state. If
it has, return -EINVAL. The state is corrupted already, so no point in
cleaning it up. Subsequent calls will fail as well. Not our problem.

[ tglx: Use futex_top_waiter() and explain why we do not need to try
  	restoring the already corrupted user space state. ]

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Change-Id: I6c19ae4a5e85fbc9c560723e672d5136c4786ab6
futex: Always cleanup owner tid in unlock_pi

If the owner died bit is set at futex_unlock_pi, we currently do not
cleanup the user space futex. So the owner TID of the current owner
(the unlocker) persists. That's observable inconsistant state,
especially when the ownership of the pi state got transferred.

Clean it up unconditionally.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org

Change-Id: Ic84473a62bdf3e5702f46e04b266afa38e9ec40e
futex: Make lookup_pi_state more robust

The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters
bit or the owner died bit is set or we are called from the requeue_pi
path or from user space just for fun.

The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.

Handle the cases explicit:

     Waiter | pi_state | pi->owner | uTID      | uODIED | ?

[1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
[2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

[3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

[4]  Found  | Found    | NULL      | 0         | 1      | Valid
[5]  Found  | Found    | NULL      | >0        | 1      | Invalid

[6]  Found  | Found    | task      | 0         | 1      | Valid

[7]  Found  | Found    | NULL      | Any       | 0      | Invalid

[8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
[9]  Found  | Found    | task      | 0         | 0      | Invalid
[10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

[1]  Indicates that the kernel can acquire the futex atomically. We
     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

[2]  Valid, if TID does not belong to a kernel thread. If no matching
     thread is found then it indicates that the owner TID has died.

[3]  Invalid. The waiter is queued on a non PI futex

[4]  Valid state after exit_robust_list(), which sets the user space
     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

[5]  The user space value got manipulated between exit_robust_list()
     and exit_pi_state_list()

[6]  Valid state after exit_pi_state_list() which sets the new owner in
     the pi_state but cannot access the user space value.

[7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.

[8]  Owner and user space value match

[9]  There is no transient state which sets the user space TID to 0
     except exit_robust_list(), but this is indicated by the
     FUTEX_OWNER_DIED bit. See [4]

[10] There is no transient state which leaves owner and user space
     TID out of sync.

Backport to 3.13
  conflicts: kernel/futex.c

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org

Change-Id: I967e3bb07b239941ea51af6b09d61d7b08138f40
stereo call recording support

Patch that allows for call recording in
stereo (left channel: TX; right channel:
RX). Tested on Nexus 5 (MSM8974). Likely
works on other recent MSM chipsets as
well.

Change-Id: I3f67ee5b83383f09b339f0af710b470f8a3a000c
msm: kgsl: Enable protected mode for A3XX

Enable protected register mode for A3XX with these commits from
msm-3.10:

msm: kgsl: Enable protected register mode for A3XX
msm: kgsl: Print the register that causes a protected mode error
msm: kgsl: Unprotect the VBIF performance counters

Change-Id: Ic0dedbad950ffbd063fd861d9440bb5dce8d5fb1
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Protect SMMU registers from being written by the GPU

Put the SMMU register range in protected mode to shield them from
IB1/IB2 writes from userspace.

CRs-Fixed: 599971
Change-Id: Ic0dedbad8c03fc1c54ff73221231e2440d3c34dd
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Mark the IOMMU setstate memory as read only

Mark the IOMMU setstate memory as read only in the pagetable.

Change-Id: Ic0dedbadb19e499c749cd744c3e89be3bcb4c2a2
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Protect CP_STATE_DEBUG_INDEX

Put CP_STATE_DEBUG_INDEX and CP_STATE_DEBUG_DATA under protection
to keep it from being written from an IB1. Doing so however opens
up a subtle "feature" in the microcode: memory read opcodes turn off
protected mode in the microcode to do the read and then turns it
back on regardless of the initial state. This is a problem if the
memory read happens while protected mode is turned off and then we
try to access a protected register which then complains and goes boom.

To account for this irregularity explicitly turn back off protected
mode in all the places where we know this will be a problem.

Change-Id: Ic0dedbad1397ca9b80132241ac006560a615e042
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
gpu: ion: system_heap: add support for 2MB allocations

Enable 2MB (order 9) allocations from the system heap. This improves the
performance of some heavyweight use cases. The benefit is especially
large for use cases where the buffer is mapped into an IOMMU since we
can leverage the 2MB IOMMU page table mappings.

Change-Id: I869733089b9ccba8090bbca80aac7b5f248b335e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ion: use iounmap instead of __arm_iounmap

The API iounmap() is more generic and portable
than __arm_iounmap().

Change-Id: If9601e9266bec56442686d3f2bdb1d475cd7bead
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
ion: use PAGE_KERNEL instead of pgprot_kernel

The ion code uses PAGE_KERNEL (which is more generic than
pgprot_kernel) everywhere except in one place (so fix it).

Change-Id: I38fa1c682a3e04e9c8cb3cd25678094862fe8c9c
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
ion: remove unused function

Somehow, during [83c50939e88d0 gpu: ion: optimize zero'ing of pages] we
retained some cruft. Remove it.

Change-Id: I38f2ef5d6cd1baa3fe8a758a0bf8164695e2b657
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: fix use-after-free in ion_heap_freelist_drain

The `buffer' variable is being used after being freed. Fix this.

Change-Id: Iea3471fa7dc7535bbf0620c1639fea2008d7cf19
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ion: system_heap: only use low gfp flags for order-0 pages

By trying a little harder to get high-order pages (by virtue of the
liberal gfp flags used for high-order allocations) we can actually
optimize performance since high-order pages seem to help a lot. Only use
the low-order flags as a last resort, when trying to allocate an order-0
page.

Change-Id: If8d8f4b1b4503b0c7546cf5a4bcdcaecd2bb5905
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ion: invalidate buffers before zero'ing

Currently, we invalidate the cache for buffers being zero'd *after* we
zero them. However, this is racey since a dirty cache line from an
earlier mapping could be written out to memory between the zero'ing and
the invalidation. Fix this by invalidating the cache *before* zero'ing
the buffer.

Before this change, I was seeing corruption with:

    $ cat <<EOF | ./memory_prof -e -i -
    simple_alloc,1,ION_SYSTEM_HEAP_ID,ION_FLAG_CACHED,0x100000,1MB
    simple_basic_sanity,1
    simple_profile,1
    simple_free,1
    EOF

After this change, no corruption.

CRs-Fixed: 585524
Change-Id: I1f2603604efc9be4ebf9112b06728e0aeca60ea0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ion: remove ion_cp_heap

The CP heap has been replaced by CMA-based heaps. Remove it.

Change-Id: I6b5e81d701e730584a456c7d9c3ff71397a12c0f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>

msm: Remove references to SMI

SMI memory is no longer supported on current targets. Remove
all references to it.

Change-Id: Ifbdf6247cc4b13c1d0173f1c998e07c702c06408
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

gpu: ion: get rid of adjacent heap code

The targets that require adjacent heaps are no longer present. Get
rid of the complicated crufty code.

Change-Id: Ic46cd16d36b812b19a7dc88202264cf137aebdd1
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

gpu: ion: Remove mach/ion.h

This file is now mostly useless. Move the remaining defintions elsewhere
and cleanup the cruft.

Change-Id: Icc19f9138a0d9d24a466511d69bc0eed45789fb9
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

gpu: ion: Remove allocate_contiguous_ebi call for carveouts

The allocate_contiguous_ebi APIs are being deprecated in favor
of the standard dma_alloc_coherent APIs. The carveout heap
does not currently support the dma_alloc_coherent APIs so just
give a note that clients should switch over to a heap type that
does support dma_alloc_coherent for non-fixed addresses. Remove
some crufty stuff related to allocate_contiguous_ebi memory types
as well.

Change-Id: I96fd43eb59d4cde4cdfd5c8d414885467ff423db
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

x9007: Remove references to SMI memory

Change-Id: I1b22e2d09c830be47e8100f1fbe9cf084fd0be31

gpu: ion: change pr_err to pr_debug for secure buffer failure

New architecture requirements for secure buffers mean that a
secure buffer failure may happen during normal playback. There's
no need to print an error message every time during normal use
cases so change the pr_err to pr_debug.

Change-Id: Ic05d0e95e2542dec9661e990cbfefd50274abc9e
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

gpu: ion: Pull secure buffers out of Ion

Securing individual buffers does not belong in the Ion framework.
Pull the code out of the framework and into a file which can be
managed separately. The file can be moved elsewhere at a later
date.

Change-Id: Ifaec740abcd78ee1bc3769a6c73014e4309c82be
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

gpu: ion: Skip wrong usage check for secure buffers

With the change to secure buffers at allocation time, it is
no longer possible to correctly validate if the memory is
re-secured with a different usage hint. Considering the usage
hint is being deprecated anyway, drop the redundant check. If
a client tries to re-secure with the wrong usage hint, failures
will occur elsewhere to indicate the problem.

Change-Id: If8487c431eb4555927cd06c6cc5edcb1a66002f1
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

gpu: ion: only secure buffers when supported

There are some targets where securing Ion buffers is not supported
through the TZ API used in the MSM secure buffer code. Currently, we
simply try the allocation and if it fails we let the clients secure it
themselves through some other means. However, due to a recent change to
the TZ error logging in the kernel, the current "ask for forgiveness"
approach results in logspam. Fix this by moving to an "ask for
permission" approach: if the TZ API to secure the buffers is not
available, don't attempt to use it.

Change-Id: Ie003d5139a0622ce9c18719ca2697525e23e7733
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>

ion: fix print statements

Use %zx, %zu for printing size_t and %p for printing
pointers (rather than casting them as integers and using %x).

Change-Id: I86bc2b10283b640f51a861adde6b8181bdbbcb29
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>

msm: Remove lib/memory_alloc.c and related files

The memory pools are gone for good. Remove memory_alloc.c and the
associated header file from clients.

Change-Id: I8d303c72fa03cdca7eee34b39d57d5cbb5df920d
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: Remove memory reservation code

The memory reservation API used for allocate_contiguous_ebi is now
deprecated in favor of using standard kernel APIs such as
dma_alloc_coherent and CMA for reserving/allocating memory. Remove
lots of code.

Change-Id: I5a7c22cce6b4b772dc67d18029e40b4509d3ba40
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: Remove ugly header include fixme

Long ago, some targets needed ugly hacks to work around buggy
hardware. These targets have fortunately been deprecated.
Remove the ugly header include remnants.

Change-Id: Ia7eef2f8f625775e40c1a73f5c2095560618cada
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: Remove store_ttbr0

This was used for debugging a while back but isn't even called
anymore. Remove it.

Change-Id: Ia5e9c609508a80ae471b9ff448b92fe193e2d2b1
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: clean up memory.c

This file contained support and workarounds for platforms that are
no longer supported on 3.10 -- remove this code.

Change-Id: I841a04c34c5fbe36a40b5ee49e3ac8608c963808
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>

msm: clean up memory.h

Remove various defines and comments which were only
relevant to platforms or features not supported any more.

Change-Id: I3eade953577079878375c87e35c842090c35f55d
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>

msm: remove allocate_contiguous_ebi APIs

The allocate_contiguous_ebi APIs are now deprecated. Remove them.

Change-Id: Icb83230e5b4b2eca135e8a27f6d5e73a0b9b3bb9
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: Remove DONT_MAP_HOLE_AFTER_MEMBANK0

The DONT_MAP_HOLE_AFTER_MEMBANK0 feature is now deprecated. Remove
the code associated with it.

Change-Id: I729b9574a7655e97c8e7abc68797b874e90dcac2
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

ASoC: msm: qdsp6v2: Migrate away from allocate_contiguous_ebi APIs

The allocate_contiguous_ebi APIs are being deprecated in favor of
the standard dma_alloc_coherent APIs. Migrate accordingly.

Change-Id: I01dece36f7aaae192afa689daf0b51de4c1ec592
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: kgsl: Remove reference to memory_alloc.h

Change-Id: I11a86f6f3254c8f150b7287d729540ef5db71ea1

msm: rtb: Convert away from allocate_contiguous_ebi APIs

The allocate_contiguous_ebi APIs are now deprecated. Move
to using dma_alloc_coherent for the RTB buffer. Because we
aren't using allocate_contiguous_ebi for allocation, change
the devicetree bindings as well to support using CMA or just
a regular size from the generic region.

Change-Id: I8ab0b7336924a78b40c68af3f215d7bfd2fba33c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: pm-boot: Remove boot remapping support

All devices that used the boot remapping code are no longer supported.
Remove the code that sets this up.

Change-Id: I85eb4e9f01664c855b0f96c34daca4c2a16ce896
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: pm-boot: clean up non TZ support code

Modern ARM processors supporting TZ environment by
default. Currently, cores warmboot starts from TZ when
there is a TZ support. This patch removes the non TZ
supported code.

Change-Id: Ifa5df40bd649e4860a2660132f3fc30fa7937358
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>

msm: pm-boot: flush msm_pm_boot_vector to main memory

msm_pm_boot_vector array stores cores warmboot entry before
cores enter into LPM mode. These warm boot entries must be
visible to core when it comes out of LPM mode. To ensure
this variable to appear in main memory use flush APIs to
flush out of caches. Use a different API to do this on
latest ARM based targets.

Change-Id: I870b68e4f6f6b116e93deffe59edff9094db0fa8
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>

msm: buspm: Remove allocate_contiguous_ebi calls

allocate_contiguous_ebi is being deprecated in favor of the standard
dma_alloc_coherent APIs. Move accordingly.

Change-Id: I3746e5ac047b1a6ee570aaf96ffbe305e3b6a49f
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

msm: kgsl: Add CMA memory feature to support NOMMU for GPU

Reserves CMA memory for kgsl driver early during bootup and then
uses dma_alloc_coherent() to allocate physically contiguous memory
instead of using the MMU

Change-Id: Ica9b244fe9b9d8a902d670293a0bec2edf81bd5d
Signed-off-by: Shrenuj Bansal <shrenujb@codeaurora.org>

media: Remove videobuf2-msm-mem.c

This file is no longer needed by any frameworks. Remove it.

Change-Id: I66f01ab9ba273ba15b1966ad040d1d3d172d33bf
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ion: remove use of qcom,msm-ion-reserve

The device tree string "qcom,msm-ion-reserve" is no
longer needed since we don't support carveout heaps any more.

Change-Id: Icb24d86fff9b478504d17518fda4c2e7b04833b8
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>