15 Jul, 2019

1 commit

  • Blob buffer size is 48 bytes larger than the plain text buffer,
    set correct range when flush the dcache. Also use cache aligned
    buffer for the blob/plain_text to avoid failure in CAAM.

    Change-Id: I8f311b9d21fc7d26d60e9ba23dfb239d2582cedf
    Signed-off-by: Ji Luo

    Ji Luo
     

10 Jul, 2019

2 commits

  • The CAAM driver in u-boot will use JR0 by default, but for
    imx8q, both JR0 and JR1 are assigned to SECO and A core
    should never access them.
    Power on the JR3 in this patchset and use it to complete
    the CAAM operations for imx8q.

    Test: CAAM self test cases pass for imx8q.

    below patches are merged to this commit:
    MA-13964 imx8q: Kick the CAAM JR before kicking the SMMU
    MA-13969 Fix CAAM build warnings

    Change-Id: Ie3d77d1f2910e7f4c257c797c12b5c8a30ad936a
    Signed-off-by: Ji Luo

    Ji Luo
     
  • Add CAAM RNG generating and BLOB encap/decap
    self test cases.

    Test: Test cases pass on imx8qm_mek/imx6qp_sabresd.

    Change-Id: I538f7b1581b36df83a3006ac133ca9e7b57ab4f0
    Signed-off-by: Ji Luo

    Ji Luo
     

09 Jul, 2019

1 commit

  • Add DEK blob encapsulation support for IMX8M through "dek_blob" command.
    On ARMv8, u-boot runs in non-secure, thus cannot encapsulate a DEK blob
    for encrypted boot.
    The DEK blob is encapsulated by OP-TEE through a trusted application call.
    U-boot sends and receives the DEK and the DEK blob binaries through OP-TEE
    dynamic shared memory.

    To enable the DEK blob encapsulation, add to the defconfig:
    CONFIG_SECURE_BOOT=y
    CONFIG_FAT_WRITE=y
    CONFIG_CMD_DEKBLOB=y

    Signed-off-by: Clement Faure
    Reviewed-by: Ye Li

    Clement Faure
     

26 Jun, 2019

2 commits


24 May, 2019

12 commits

  • The blob command is not working on i.MX7D, i.MX8MQ and i.MX8MM
    devices.

    Due to different cache management it's necessary to flush dcache
    range for destination address so data can be available in memory.

    Add necessary operations in blob_encap() and blob_decap() functions.

    Signed-off-by: Breno Lima
    Reviewed-by: Ye Li
    (cherry picked from commit 639e5c15816c3eea0d4904a72ad175627be043d8)

    Breno Lima
     
  • Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to
    non-TrustZone") breaks HABv4 encrypted boot support in the
    following i.MX devices:

    - i.MX6UL
    - i.MX7S
    - i.MX7D
    - i.MX7ULP

    For preparing a HABv4 encrypted boot image it's necessary to
    encapsulated the generated DEK in a blob. The blob generation
    function takes into consideration the Job Ring TrustZone
    ownership configuration (JROWN_NS) and can be only decapsulated
    by the same configuration.

    The ROM code expects DEK blobs encapsulated by the Secure World
    environments which commonly have JROWN_NS = 0.

    As U-Boot is running in Secure World we must have JROWN_NS=0
    so the blobs generated by dek_blob tool can be decapsulated
    by the ROM code.

    As NXP BSP does not requires all job-rings assigned to
    non-Secure world this commit can be safely reverted.

    This reverts commit 22191ac353445ad8fafc5a78aefcd94e78963041.

    Reviewed-by: Silvano Di Ninno
    Signed-off-by: Breno Lima
    (cherry picked from commit 3eebc76f5571f7ce74d385235019e8eb4a6718f6)

    Breno Lima
     
  • Found the imx8mq Rev A chip (B0 and B1 chips are ok) boot hang at CAAM RNG init.
    The jobring 0 can't complete instantiation descriptor and spins on checking ORSFR_JR0.

    In current implementation, the descriptor and jobring input and output base address locate
    on TCM, because the driver uses raw_data array in jr_data_st structure as the buffer.
    This seems cause the issue. If switched from TCM to OCRAM, the issue will go.

    Since accessing TCM by CAAM is not very reliable. Add this patch to use OCRAM for SPL case.
    The early malloc is ready on SPL before calling board_init_f. So we can use malloc to allocate
    memory instead of the raw_data array.

    Signed-off-by: Ye Li
    Reviewed-by: Peng Fan
    (cherry picked from commit b12e170792c918efc7c371f86989d34fc397fe06)

    Ye Li
     
  • The TRNG as used in RNG4, used in CAAM has a documentation issue. The
    effect is that it is possible that the entropy used to instantiate the
    DRBG may be old entropy, rather than newly generated entropy. There is
    proper programming guidance, but it is not in the documentation.

    Signed-off-by: Aymen Sghaier
    (cherry picked from commit 2aff5ffb2c4bb19106f3faa76415b51591cbc2b2)

    Aymen Sghaier
     
  • The following reasons lead to instantiate the TRNG into U-Boot/SPL:

    - On some i.MX platforms Linux Kernel could not instantiate RNG
    - RNG could be used/needed by M4/M0 cores before Kernel stage
    - Having the RNG instantiation implemented only once for
    almost i.MX platforms

    Signed-off-by: Aymen Sghaier
    (cherry picked from commit 1f4134c85f6416cbdadaf5f4ff6321f6c685c74c)

    Aymen Sghaier
     
  • Add the fsl CAAM driver and new commands to implement DEK blob operations,
    like "caam genblob" to generate encrypted blob and "caam decap" to output
    orignal plain data.

    Signed-off-by: Ye Li
    (cherry picked from commit 4ec81a0b075d8d853ac696172660a7771064405d)

    Ye Li
     
  • The CAAM block used in i.MX8M is 32 bits address size but when the flag
    PHYS_64BIT is enabled for armv8, the CAAM driver will try to use a
    wrong pointer size.
    This patch fixes this issue.

    Signed-off-by: Aymen Sghaier
    (cherry picked from commit 9e1ef25c121240cf3f6a142058e617dd7df0030b)
    (cherry picked from commit 1733916155ca319be754c45861130df327d8a57d)

    Aymen Sghaier
     
  • Enabling CAAM driver for i.MX8M platforms, a 64 bits architecture,
    lead to casting warnings: from/to pointer to/from integer with
    different size. This patch fix these warnings

    Signed-off-by: Aymen Sghaier
    (cherry picked from commit d02fbc7d2957f4788ced017ccf17fd35ab968121)
    (cherry picked from commit 79e90af14af32e86fd7efd3c84e09a0bd572ab5b)

    Aymen Sghaier
     
  • This patch enable CAAM support for i.MX8M platforms.

    Signed-off-by: Aymen Sghaier
    (cherry picked from commit 1fc92e6e34b06bdee81240ce06326aca1d9c02d8)
    (cherry picked from commit b0f889b77b367b69aa0778b1d03a2ec30fdee243)

    Aymen Sghaier
     
  • Signed-off-by: Franck LENORMAND
    (cherry picked from commit 5f429339ab5a5f0d1f00a2880ce05cf479f11ba5)
    (cherry picked from commit c26db25a130ef1f0abd43a3133877f74431eb217)

    Franck LENORMAND
     
  • Signed-off-by: Franck LENORMAND
    (cherry picked from commit 6503c1ed0264fc61945c2b3b5948b793f104fc32)
    (cherry picked from commit d1d10af5a15473377fefbca56c1dac293fb06f3b)

    Franck LENORMAND
     
  • This code was originally developed by Raul Cardenas
    and modified to be applied in U-Boot imx_v2017.03.

    More information about the initial submission can be seen
    in the link below:
    https://lists.denx.de/pipermail/u-boot/2016-February/245273.html

    i.MX7D has an a protection feature for Manufacturing process.
    This feature uses asymmetric encryption to sign and verify
    authenticated software handled between parties. This command
    enables the use of such feature.

    The private key is unique and generated once per device.
    And it is stored in secure memory and only accessible by CAAM.
    Therefore, the public key generation and signature functions
    are the only functions available for the user.

    The manufacturing-protection authentication process can be used to
    authenticate the chip to the OEM's server.

    Command usage:

    Print the public key for the device.
    - mfgprot pubk

    Generates Signature over given data.
    - mfgprot sign

    Signed-off-by: Raul Ulises Cardenas
    Signed-off-by: Breno Lima
    Reviewed-by: Fabio Estevam
    Reviewed-by: Ye Li
    (cherry picked from commit db2dbf622d3c711b2fbd85e6814992e023479dad)

    Breno Lima
     

07 May, 2018

1 commit

  • 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

    Tom Rini
     

05 Mar, 2018

1 commit

  • 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

    Masahiro Yamada
     

10 Feb, 2018

1 commit

  • 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

    Lukas Auer
     

04 Feb, 2018

1 commit

  • 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

    Bryan O'Donoghue
     

24 Jan, 2018

1 commit

  • 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

    Breno Lima
     

08 Jan, 2018

1 commit

  • 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

    Clemens Gruber
     

04 Sep, 2017

1 commit

  • 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

    Clemens Gruber
     

23 May, 2017

1 commit


22 May, 2017

1 commit

  • 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

    Tom Rini
     

18 Apr, 2017

4 commits


05 Jan, 2017

2 commits


24 Nov, 2016

1 commit


07 Oct, 2016

1 commit


24 Sep, 2016

2 commits


03 Aug, 2016

1 commit


27 Jul, 2016

1 commit


22 Jul, 2016

1 commit

  • As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
    the next level U-boot image. Add a new function spl_validate_uboot to
    perform the validation.

    Enable hardware crypto operations in SPL using SEC block.
    In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
    access to CPC configured as SRAM, configure PAMU.

    Reviewed-by: Ruchika Gupta
    Signed-off-by: Aneesh Bansal
    Signed-off-by: Sumit Garg
    Reviewed-by: Simon Glass
    Reviewed-by: York Sun

    Sumit Garg