u-boot.git/drivers/crypto, branch v2018.05

SPDX: Convert all of our single license tags to Linux Kernel style

2018-05-07T13:34:12+00:00

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini

libfdt: move headers to and

2018-03-05T15:16:28+00:00

Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.

This commit moves the header code:
  include/libfdt.h         -> include/linux/libfdt.h
  include/libfdt_env.h     -> include/linux/libfdt_env.h

and replaces include directives:
  #include       -> #include 
  #include   -> #include 

Reported-by: Thomas Petazzoni 
Signed-off-by: Masahiro Yamada

crypto/fsl: instantiate all rng state handles

2018-02-09T16:34:34+00:00

Extend the instantiate_rng() function and the corresponding CAAM job
descriptor to instantiate all RNG state handles. This moves the RNG
instantiation code in line with the CAAM kernel driver.

Previously, only the first state handle was instantiated. The second
one was instantiated by the CAAM kernel driver. This works if the
kernel runs in secure mode, but fails in non-secure mode since the
kernel driver uses DEC0 directly instead of over the job ring
interface. Instantiating all RNG state handles in u-boot removes the
need for using DEC0 in the kernel driver, making it possible to use
the CAAM in non-secure mode.

Signed-off-by: Lukas Auer 
Tested-by: Bryan O'Donoghue 
Reviewed-by: York Sun

drivers/crypto/fsl: assign job-rings to non-TrustZone

2018-02-04T11:14:11+00:00

After enabling TrustZone various parts of the CAAM silicon become
inaccessible to non TrustZone contexts. The job-ring registers are designed
to allow non TrustZone contexts like Linux to still submit jobs to CAAM
even after TrustZone has been enabled.

The default job-ring permissions after the BootROM look like this for
job-ring zero.

ms=0x00008001 ls=0x00008001

The MS field is JRaMIDR_MS (job ring MID most significant).

Referring to "Security Reference Manual for i.MX 7Dual and 7Solo
Applications Processors, Rev. 0, 03/2017" section 8.10.4 we see that
JROWN_NS controls whether or not a job-ring is accessible from non
TrustZone.

Bit 15 (TrustZone) is the logical inverse of bit 3 hence the above value of
0x8001 shows that JROWN_NS=0 and TrustZone=1.

Clearly then as soon as TrustZone becomes active the job-ring registers are
no longer accessible from Linux, which is not what we want.

This patch explicitly sets all job-ring registers to JROWN_NS=1 (non
TrustZone) by default and to the Non-Secure MID 001. Both settings are
required to successfully assign a job-ring to non-secure mode. If a piece
of TrustZone firmware requires ownership of job-ring registers it can unset
the JROWN_NS bit itself.

This patch in conjunction with a modification of the Linux kernel to skip
HWRNG initialisation makes CAAM usable to Linux with TrustZone enabled.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Alex Porosanu 
Cc: Ruchika Gupta 
Cc: Aneesh Bansal 
Link: https://github.com/OP-TEE/optee_os/issues/1408
Link: https://tinyurl.com/yam5gv9a
Tested-by: Lukas Auer

crypto/fsl: Fix HW accelerated hash commands

2018-01-23T19:21:20+00:00

The hash command function were not flushing the dcache before passing data
to CAAM/DMA and not invalidating the dcache when getting data back.

Due the data cache incoherency, HW accelerated hash commands used to fail
with CAAM errors like "Invalid KEY Command".

Check if pbuf and pout buffers are properly aligned to the cache line size
and flush/invalidate the memory regions to address this issue.

This solution is based in a previous work from Clemens Gruber in
commit 598e9dccc75d ("crypto/fsl: fix BLOB encapsulation and
decapsulation")

Reported-by: Anatolij Gustschin 
Signed-off-by: Breno Lima 
Reviewed-by: York Sun

crypto/fsl: fix BLOB encapsulation and decapsulation

2018-01-08T13:26:03+00:00

The blob_encap and blob_decap functions were not flushing the dcache
before passing data to CAAM/DMA and not invalidating the dcache when
getting data back.
Therefore, blob encapsulation and decapsulation failed with errors like
the following due to data cache incoherency:
"40000006: DECO: desc idx 0: Invalid KEY command"

To ensure coherency, we require the key_mod, src and dst buffers to be
aligned to the cache line size and flush/invalidate the memory regions.
The same requirements apply to the job descriptor.

Tested on an i.MX6Q board.

Reviewed-by: Sumit Garg 
Signed-off-by: Clemens Gruber

crypto/fsl: fix obj-yy in Makefile

2017-09-04T13:02:07+00:00

When enabling CONFIG_CMD_BLOB and/or CONFIG_CMD_DEKBLOB, the build fails
with a linker error:
  ...
  LD      u-boot
arch/arm/mach-imx/built-in.o: In function `blob_encap_dek':
/home/clemens/dev/u-boot/arch/arm/mach-imx/cmd_dek.c:46: undefined
reference to `blob_dek'

This is due to an error in the Makefile, resulting in obj-yy/obj-yn/..
and fsl_blob.o is therefore not linked.

Fix it by splitting it up into two obj-y lines.

Signed-off-by: Clemens Gruber 
Reviewed-by: Fabio Estevam

Convert CONFIG_CMD_HASH to Kconfig

2017-05-22T16:38:15+00:00

This converts the following to Kconfig:
   CONFIG_CMD_HASH

Signed-off-by: Simon Glass 
Reviewed-by: Tom Rini 
[trini: Rework slightly, enable on some boards again]
Signed-off-by: Tom Rini

lib: move hash CONFIG options to Kconfig

2017-05-22T12:36:58+00:00

Commit 94e3c8c4fd7b ("crypto/fsl - Add progressive hashing support
using hardware acceleration.") created entries for CONFIG_SHA1,
CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
However, no defconfig has migrated to it.  Complete the move by first
adding additional logic to various Kconfig files to select this when
required and then use the moveconfig tool.  In many cases we can select
these because they are required to implement other drivers.  We also
correct how we include the various hashing algorithms in SPL.

This commit was generated as follows (after Kconfig additions):

[1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
[2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL

Note:
We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
because there is dependency between them.

Cc: Poonam Aggrwal 
Cc: Naveen Burmi 
Cc: Po Liu 
Cc: Shengzhou Liu 
Cc: Priyanka Jain 
Cc: Shaohui Xie 
Cc: Chunhe Lan 
Cc: Chander Kashyap 
Cc: Steve Rae 
Cc: Dirk Eibach 
Cc: Feng Li 
Cc: Alison Wang 
Cc: Sumit Garg 
Cc: Mingkai Hu 
Cc: York Sun 
Cc: Prabhakar Kushwaha 
Cc: Jaehoon Chung 
Cc: Akshay Saraswat 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Signed-off-by: Tom Rini 
Reviewed-by: Simon Glass 
Signed-off-by: Tom Rini

Merge git://git.denx.de/u-boot-fsl-qoriq

2017-04-18T15:36:06+00:00