crypto: create generic version of ablk_helper

Create a generic version of ablk_helper so it can be reused
by other architectures.

Change-Id: I48f570fd56ea9e281dd2a1504d2b9e13e78b1d95
Acked-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
ARM: crypto: add NEON accelerated XOR implementation

Add a source file xor-neon.c (which is really just the reference
C implementation passed through the GCC vectorizer) and hook it
up to the XOR framework.

Change-Id: Ic92f9b016bb47061088fe90bc32d62212b7bb4bb
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
ARM: 7835/2: fix modular build of xor_blocks() with NEON enabled

Commit 0195659 introduced a NEON accelerated version of the xor_blocks()
function, but it needs the changes in this patch to allow it to be built
as a module rather than statically into the kernel.

This patch creates a separate module xor-neon.ko which exports the NEON
inner xor_blocks() functions depended upon by the regular xor.ko if it
is built with CONFIG_KERNEL_MODE_NEON=y

Change-Id: Id37b1d7421370ccf1319aec2b3ee8eb022719a6c
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: only allow kernel mode neon with AEABI

This prevents the linker erroring with:

arm-linux-ld: error: arch/arm/lib/xor-neon.o uses VFP instructions, whereas arch/arm/lib/built-in.o does not
arm-linux-ld: failed to merge target specific data of file arch/arm/lib/xor-neon.o

This is due to the non-neon files being marked as containing FPA data/
instructions (even though they do not) being mixed with files which
contain VFP, which is an incompatible floating point format.

Change-Id: I161e270c8ef68e7de05a0c362d4afb7e72f4511a
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks

When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.

Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.

This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).

Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.

We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.

crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
("Os") because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.

Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.

As we use ("Os"), this patch also provides a loop-free "fast-path" for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.

This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].

  [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
  [2] https://lkml.org/lkml/2013/2/10/131

Change-Id: Id6796ba73611f310dbc2f156a2b99704f8a3b4d7
Signed-off-by: James Yonan <james@openvpn.net>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: more robust crypto_memneq

Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.

Instead of disabling compiler optimizations, use a dummy inline assembly
(based on RELOC_HIDE) to block the problematic kinds of optimization,
while still allowing other optimizations to be applied to the code.

The dummy inline assembly is added after every OR, and has the
accumulator variable as its input and output. The compiler is forced to
assume that the dummy inline assembly could both depend on the
accumulator variable and change the accumulator variable, so it is
forced to compute the value correctly before the inline assembly, and
cannot assume anything about its value after the inline assembly.

This change should be enough to make crypto_memneq work correctly (with
data-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.

Compile-tested on x86_64.

Change-Id: I5fea15c326bb8fb2e8a058a8366e97878fb4014b
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.eti.br>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: memneq - fix for archs without efficient unaligned access

Commit fe8c8a126806 introduced a possible build error for archs
that do not have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS set. :/
Fix this up by bringing else braces outside of the ifdef.

Change-Id: I278729707b9b3834191474bde8417fb52f906e18
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Fixes: fe8c8a126806 ("crypto: more robust crypto_memneq")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-By: Cesar Eduardo Barros <cesarb@cesarb.eti.br>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
relocate simd.h

Change-Id: I0dec4aaf66170d6f90f7e366ed70d59fabb63f0d
drivers: ipc_router: Add support to disable loading a subsystem

IPC Router interfaces with PIL to load/unload a remote subsystem. In
certain System-on-Chips(SoCs) this support is not required.

Add a device tree configuration entry to disable loading a subsystem by
IPC Router. By default, IPC Router loads the remote subsystem and if that
entry is defined, then IPC Router does not load the concerned subsystem.

Change-Id: Ifd3ac7adb196736f3ccf24289cdcaf8fde7dfcb3
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
net: ipc_router: Fix the race condition during SSR

During subsystem restart, SMD XPRT state is checked after starting the
write operation on a SMD channel. The channel state is different from its
corresponding XPRT state. This causes a writer to start the write operation
and then abort it, since the channel is not in reset state and the XPRT is
in reset state. This in turn causes the channel to be busy.

Check the XPRT state first before performing the write operation on its
corresponding channel. Remove the XPRT from the XPRT list at the earliest
possible, so that any write operation on a reset XPRT is avoided.

Change-Id: Id5745a3755c8a3f88910af2acb4d443f335d27e0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
ion: Remove custom compat framework

It was pointed out that there is no need for a custom compat ioctl
framework in Ion, that decision can all be handled in device
registration. Remove the custom compat framework and just handle
the decision regarding compat ioctls in msm_ion.c

Change-Id: I224cfb0c3cc65abbb92c2d6826d15b5ee5e2bb21
ion: fix remaining instances of sg_dma_len

Recently, [ec6c8a8f443: "ion: convert sg_dma_len(sg) to sg->length"]
moved Ion away from using sg_dma_len. However, a few instances were left
over from MSM-specific code. Fix these instances so that we're using
sg->length everywhere.

Change-Id: I5b4e7637a81c59900d2a0e66234c59b41572cd6e
ion: WARN when the handle kmap_cnt is going to wrap around

There are certain client bugs (double unmap, for example) that can cause
the handle->kmap_cnt (an unsigned int) to wrap around from zero. This
causes problems when the handle is destroyed because we have:

        while (handle->kmap_cnt)
                ion_handle_kmap_put(handle);

which takes a long time to complete when kmap_cnt starts at ~0 and can
result in a watchdog timeout.

WARN and bail when kmap_cnt is about to wrap around from zero.

Change-Id: I19493ab2daf9a7bafad1a4610b69bee572d02974
gpu: ion: Clarify variable names and comments around heap ids v types

There is some confusion between when to use the heap type and when
the id.  This patch clarifies this by using clearer variable names
and describing the intention in the comments.  Also fixes the client
debug code to print heaps by id instead of type.

Change-Id: I63f58a5336666ddb269147c742d804d28326acd0
ion: move shrinker out of heaps

Every heap that uses deferred frees is going to need a shrinker
to shrink the freelist under memory pressure.  Rather than
requiring each heap to implement a shrinker, automatically
register a shrinker if the deferred free flag is set.
The system heap also needs to shrink its page pools, so add
a shrink function to the heap ops that will be called after
shrinking the freelists.

Change-Id: I7175f850e5272ed9821a269ba4a0cd523219ea86
staging: ion: msm: Only parse available dt nodes

ION is currently ignoring the status property of device tree
heap nodes. Make ION aware of the status of the ION heap nodes making
it possible to disable certain heaps.

Change-Id: Ieb40ca743a02ab69a8981fe5f0393ca40b81bc41
ion: Always flush using kernel virtual address

Cache operations via userspace address always has a risk of a
page fault. On arm64, userspace addresses are marked as write
protect and fixed up on first accesses. If a userspace address
that has not been written to is invalidated, we will take a
fault, fixup and proceed on. If the mmap semaphore is locked at
the time however we cannot fixup the fault and will abort instead.
Rather than hope the mmap semaphore is not write protected, always
invalidate via the kernel virtual addresses instead.

Change-Id: I9f9f21a7618eb6fc74fc4438cc920d857664c428
ion: msm: remove superfluous function argument

msm_ion_client_create doesn't actually do anything with its heap_mask
parameter. Remove it. Also remove the extra argument from an audio
function that wraps msm_ion_client_create.

The following semantic patch was used to generate this patch:

    @@
    expression E1, E2;
    @@

    msm_ion_client_create(
    -       E1,
            E2)

    @@
    expression E1, E2;
    @@

    msm_audio_ion_client_create(
    -       E1,
            E2)

Change-Id: I5dfcc105431c023882747ad7fc3112e41f7f4528
ion: msm: move custom zero'ing functions out of core Ion

MSM targets currently use some optimized zero'ing functions. However,
there are always merge conflicts when bringing in patches from upstream
so these custom functions should be moved into the MSM space and the
original zero'ing functions from upstream should be restored.

All users of the custom zero'ing functions should continue to use the
custom functions. The goal, over time, is to unify the approaches but
for now just leave them separated.

Change-Id: I5a545af2358d8a7a20737b30d181b3057407a831
ion: msm: plumb ION_HEAP_TYPE_DMA to core Ion

ION_HEAP_TYPE_DMA has made its way into core Ion since it was originally
added to the MSM Ion code base. Move some of the hooks and function
declarations out of MSM-specific code and into core Ion. There are still
some differences in the heap implementations themselves that will need
to be rectified later.

Change-Id: Ia3019e6519212bc3f1ab36525e2f530a32399a5c