linux-toradex.git/drivers/crypto/ccp, branch v5.0

cross-tree: phase out dma_zalloc_coherent()

2019-01-08T12:58:37+00:00

We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.

This change was generated with the following Coccinelle SmPL patch:

@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@

-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)

Suggested-by: Christoph Hellwig 
Signed-off-by: Luis Chamberlain 
[hch: re-ran the script on the latest tree]
Signed-off-by: Christoph Hellwig

Remove 'type' argument from access_ok() function

2019-01-04T02:57:57+00:00

Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
of the user address range verification function since we got rid of the
old racy i386-only code to walk page tables by hand.

It existed because the original 80386 would not honor the write protect
bit when in kernel mode, so you had to do COW by hand before doing any
user access.  But we haven't supported that in a long time, and these
days the 'type' argument is a purely historical artifact.

A discussion about extending 'user_access_begin()' to do the range
checking resulted this patch, because there is no way we're going to
move the old VERIFY_xyz interface to that model.  And it's best done at
the end of the merge window when I've done most of my merges, so let's
just get this done once and for all.

This patch was mostly done with a sed-script, with manual fix-ups for
the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

There were a couple of notable cases:

 - csky still had the old "verify_area()" name as an alias.

 - the iter_iov code had magical hardcoded knowledge of the actual
   values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
   really used it)

 - microblaze used the type argument for a debug printout

but other than those oddities this should be a total no-op patch.

I tried to fix up all architectures, did fairly extensive grepping for
access_ok() uses, and the changes are trivial, but I may have missed
something.  Any missed conversion should be trivially fixable, though.

Signed-off-by: Linus Torvalds

crypto: drop mask=CRYPTO_ALG_ASYNC from 'cipher' tfm allocations

2018-11-20T06:26:55+00:00

'cipher' algorithms (single block ciphers) are always synchronous, so
passing CRYPTO_ALG_ASYNC in the mask to crypto_alloc_cipher() has no
effect.  Many users therefore already don't pass it, but some still do.
This inconsistency can cause confusion, especially since the way the
'mask' argument works is somewhat counterintuitive.

Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags.

This patch shouldn't change any actual behavior.

Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

crypto: ccp - Make function sev_get_firmware() static

2018-10-05T02:16:56+00:00

Fixes the following sparse warning:

drivers/crypto/ccp/psp-dev.c:444:5: warning:
 symbol 'sev_get_firmware' was not declared. Should it be static?

Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on Family and Model")
Signed-off-by: Wei Yongjun 
Signed-off-by: Herbert Xu

crypto: ccp - Remove forward declaration

2018-10-05T02:16:56+00:00

Clang emits a warning about this construct:

drivers/crypto/ccp/sp-platform.c:36:36: warning: tentative array
definition assumed to have one element
static const struct acpi_device_id sp_acpi_match[];
                                   ^
1 warning generated.

Just remove the forward declarations and move the initializations up
so that they can be used in sp_get_of_version and sp_get_acpi_version.

Reported-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Nick Desaulniers 
Acked-by: Gary R Hook 
Signed-off-by: Herbert Xu

crypto: ccp - Remove VLA usage of skcipher

2018-09-28T04:46:08+00:00

In the quest to remove all stack VLA usage from the kernel[1], this
replaces struct crypto_skcipher and SKCIPHER_REQUEST_ON_STACK() usage
with struct crypto_sync_skcipher and SYNC_SKCIPHER_REQUEST_ON_STACK(),
which uses a fixed stack size.

[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com

Cc: Tom Lendacky 
Cc: Gary Hook 
Signed-off-by: Kees Cook 
Signed-off-by: Herbert Xu

crypto: ccp - Allow SEV firmware to be chosen based on Family and Model

2018-09-21T05:24:52+00:00

During PSP initialization, there is an attempt to update the SEV firmware
by looking in /lib/firmware/amd/. Currently, sev.fw is the expected name
of the firmware blob.

This patch will allow for firmware filenames based on the family and
model of the processor.

Model specific firmware files are given highest priority. Followed by
firmware for a subset of models. Lastly, failing the previous two options,
fallback to looking for sev.fw.

Signed-off-by: Janakarajan Natarajan 
Reviewed-by: Tom Lendacky 
Acked-by: Gary R Hook 
Signed-off-by: Herbert Xu

crypto: ccp - Fix static checker warning

2018-09-21T05:24:52+00:00

Under certain configuration SEV functions can be defined as no-op.
In such a case error can be uninitialized.

Initialize the variable to 0.

Cc: Dan Carpenter 
Reported-by: Dan Carpenter 
Signed-off-by: Janakarajan Natarajan 
Acked-by: Gary R Hook 
Signed-off-by: Herbert Xu

crypto: ccp - add timeout support in the SEV command

2018-09-04T03:37:04+00:00

Currently, the CCP driver assumes that the SEV command issued to the PSP
will always return (i.e. it will never hang).  But recently, firmware bugs
have shown that a command can hang.  Since of the SEV commands are used
in probe routines, this can cause boot hangs and/or loss of virtualization
capabilities.

To protect against firmware bugs, add a timeout in the SEV command
execution flow.  If a command does not complete within the specified
timeout then return -ETIMEOUT and stop the driver from executing any
further commands since the state of the SEV firmware is unknown.

Cc: Tom Lendacky 
Cc: Gary Hook 
Cc: Herbert Xu 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh 
Signed-off-by: Herbert Xu

crypto: ccp - Check for NULL PSP pointer at module unload

2018-08-03T10:06:05+00:00

Should the PSP initialization fail, the PSP data structure will be
freed and the value contained in the sp_device struct set to NULL.
At module unload, psp_dev_destroy() does not check if the pointer
value is NULL and will end up dereferencing a NULL pointer.

Add a pointer check of the psp_data field in the sp_device struct
in psp_dev_destroy() and return immediately if it is NULL.

Cc:  # 4.16.x-
Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP) device support")
Signed-off-by: Tom Lendacky 
Acked-by: Gary R Hook 
Signed-off-by: Herbert Xu