11 Feb, 2020

1 commit


07 Feb, 2020

1 commit

  • H1 is a Google security chip present in recent Chromebooks, Pixel phones
    and other devices. Cr50 is the name of the software that runs on H1 in
    Chromebooks.

    This chip is used to handle TPM-like functionality and also has quite a
    few additional features.

    Add a driver for this.

    Signed-off-by: Simon Glass

    Simon Glass
     

06 Feb, 2020

1 commit


15 Dec, 2019

1 commit

  • At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
    is included in SPL/TPL without any control for boards. Some boards may
    want to disable this to reduce code size where GPIOs are not needed in
    SPL or TPL.

    Add a new Kconfig option to permit this. Default it to 'y' so that
    existing boards work correctly.

    Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
    preserve the current behaviour. Also update the 74x164 GPIO driver since
    it cannot build with SPL.

    This allows us to remove the hacks in config_uncmd_spl.h and
    Makefile.uncmd_spl (eventually those files should be removed).

    Signed-off-by: Simon Glass
    Reviewed-by: Bin Meng

    Simon Glass
     

03 Dec, 2019

1 commit

  • We have an existing U-Boot header for the one function that this defines.
    Use that instead of the linux/ one. Move over the nice comment.

    Signed-off-by: Simon Glass
    Reviewed-by: Tom Rini

    Simon Glass
     

15 Oct, 2019

1 commit


12 Jul, 2019

1 commit

  • The TPM specification says that the EXPECT_DATA bit is not valid until
    the VALID bit is set. Wait for that bit to be set. Fixes problems with
    Ifineon SPI TPM.

    Signed-off-by: Roman Kapl

    Roman Kapl
     

30 Nov, 2018

1 commit

  • At present these functions are not accessible outside the TPM library, but
    in some cases we need to call them. Export them in the header file and add
    a define for the SHA1 digest size.

    Also adjust tpm_open() to call tpm_close() first so that the TPM is in a
    known state before opening (e.g. by a previous phase of U-Boot).

    Signed-off-by: Simon Glass

    Simon Glass
     

21 Nov, 2018

1 commit


09 Oct, 2018

5 commits


14 Aug, 2018

2 commits

  • The recv variable in sandbox_tpm2_fill_buf() is a pointer on a pointer
    of a char array. It means accessing *recv is the char array pointer
    itself while **recv is the first character of that array. There is no
    need for such indirection here, so simplify the code.

    Simplifying things will make the last assignment right: "*recv = NULL"
    is now correct. The issue has been found by the following Coverity
    Scan report:

    CID 183371: Incorrect expression (UNUSED_VALUE)
    Assigning value "4UL" to "*recv" here, but that stored value is overwritten before it can be used.
    232 *recv += sizeof(rc);
    233
    234 /* Add trailing \0 */
    235 *recv = NULL;

    While at simplifying things, use '\0' instead of NULL when adding an
    empty char at the end of the buffer.

    Reported-by: Tom Rini
    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass

    Miquel Raynal
     
  • The second check on pcr_map in sandbox_tpm2_xfer() is wrong. It should
    check for pcr_map not being empty. Instead, it is a pure copy/paste of
    the first check which is redundant.

    This has been found thanks to a Coverity Scan report:

    CID 183370: Memory - illegal accesses (UNINIT)
    Using uninitialized value "pcr_index".
    put_unaligned_be32(tpm->pcr_extensions[pcr_index], recv);

    This is because pcr_index is initialized only if the user input is
    correct, ie. at least one valid bit is set in pcr_map.

    Fix the second check and also initialize pcr_index to 0 (which is
    harmless in case of error) to make Coverity Scan happy.

    Reported-by: Tom Rini
    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass

    Miquel Raynal
     

28 Jul, 2018

4 commits

  • TPM_V1 was already compiled by default. Now that both can be compiled
    at the same time, compiled them both by default.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass

    Miquel Raynal
     
  • While there is probably no reason to do so in a real life situation, it
    will allow to compile test both stacks with the same sandbox defconfig.

    As we cannot define two 'tpm' commands at the same time, the command for
    TPM v1 is still called 'tpm' and the one for TPM v2 'tpm2'. While this
    is the exact command name that must be written into eg. test files, any
    user already using the TPM v2 stack can continue to do so by just writing
    'tpm' because as long as TPM v1 support is not compiled, U-Boot prompt
    will search for the closest command named after 'tpm'.

    The command set can also be changed at runtime (not supported yet, but
    ready to be), but as one can compile only either one stack or the other,
    there is still one spot in the code where conditionals are used: to
    retrieve the v1 or v2 command set.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass
    [trini: In sandbox_tpm2_fill_buf() use NULL not \0 to ensure NULL
    terminated string due to LLVM warning]
    Signed-off-by: Tom Rini

    Miquel Raynal
     
  • The TPM_DRIVER_SELECTED symbol was used in one of the initial series
    about TPMv2 but its use has been dropped, making these selects
    useless, remove them.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass

    Miquel Raynal
     
  • When Sandbox and the TPM stack are both selected, compile Sandbox TPM
    driver by default.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass

    Miquel Raynal
     

26 May, 2018

6 commits

  • This driver can emulate all the basic functionalities of a TPMv2.x
    chip and should behave like them during regular testing.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass
    Reviewed-by: Tom Rini

    Miquel Raynal
     
  • On some designs, the reset line could not be connected to the SoC reset
    line, in this case, request the GPIO and ensure the chip gets reset.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass

    Miquel Raynal
     
  • Add the tpm2_tis_spi driver that should support any TPMv2 compliant
    (SPI) module.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Tom Rini
    Reviewed-by: Simon Glass

    Miquel Raynal
     
  • Choice between v1 and v2 compliant functions is done with the
    configuration.

    Create the various files that will receive TPMv2-only code on the same
    scheme as for the TPMv1 code.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass
    Reviewed-by: Tom Rini

    Miquel Raynal
     
  • There are no changes in this commit but a new organization of the code
    as follow.

    * cmd/ directory:
    > move existing code from cmd/tpm.c in cmd/tpm-common.c
    > move specific code in cmd/tpm-v1.c
    > create a specific header file with generic definitions for
    commands only called cmd/tpm-user-utils.h

    * lib/ directory:
    > move existing code from lib/tpm.c in lib/tpm-common.c
    > move specific code in lib/tpm-v1.c
    > create a specific header file with generic definitions for
    the library itself called lib/tpm-utils.h

    * include/ directory:
    > move existing code from include/tpm.h in include/tpm-common.h
    > move specific code in include/tpm-v1.h

    Code designated as 'common' is compiled if TPM are used. Code designated
    as 'specific' is compiled only if the right specification has been
    selected.

    All files include tpm-common.h.
    Files in cmd/ include tpm-user-utils.h.
    Files in lib/ include tpm-utils.h.
    Depending on the specification, files may include either (not both)
    tpm-v1.h or tpm-v2.h.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Tom Rini
    [trini: Fix a few more cases of tpm.h -> tpm-v1.h, some Kconfig logic]
    Signed-off-by: Tom Rini

    Miquel Raynal
     
  • Because both major revisions are not compatible at all, let's make them
    mutually exclusive in Kconfig. This way we will be sure, when using a
    command or a library function that it is supported by the right
    revision.

    Current drivers are currently prefixed by "tpm_", we will prefix TPMv2.x
    files by "tpm2_" to make the distinction without moving everything.

    The Kconfig menu about TPM drivers is now divided into two sections, one
    for each specification. Compliant drivers with one specification will
    only show up if this specification _only_ has been selected, otherwise a
    comment is displayed.

    Once a driver is selected by the user, it selects automatically a
    boolean value, that is needed in order to activate the TPM commands.
    Selecting the TPM commands will automatically select the right
    command/library files.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass
    Reviewed-by: Tom Rini
    [trini: Rework deps as TPM_V1 and TPM_V2 depend on TPM,
    drop TPM_DRIVER_SELECTED]
    Signed-off-by: Tom Rini

    Miquel Raynal
     

25 May, 2018

1 commit

  • TPM are shipped with a few read-only register from which we can retrieve
    for instance:
    - vendor ID
    - product ID
    - revision ID

    Product and vendor ID share the same register and are already referenced
    in the tpm_chip structure. Add the revision ID entry which is missing.

    Signed-off-by: Miquel Raynal
    Reviewed-by: Simon Glass
    Reviewed-by: Tom Rini

    Miquel Raynal
     

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
     

28 Apr, 2018

1 commit


09 Mar, 2018

1 commit

  • The @gdsys.cc addresses are supposed to be used for mailing lists.
    Switch all occurrences of @gdsys.de mail addresses to their @gdsys.cc
    equivalent.

    Also, Dirk's address was wrong in one place; fix that as well.

    Signed-off-by: Mario Six

    Mario Six
     

05 Mar, 2018

3 commits


06 Nov, 2017

1 commit


04 Oct, 2017

1 commit

  • U-Boot widely uses error() as a bit noisier variant of printf().

    This macro causes name conflict with the following line in
    include/linux/compiler-gcc.h:

    # define __compiletime_error(message) __attribute__((error(message)))

    This prevents us from using __compiletime_error(), and makes it
    difficult to fully sync BUILD_BUG macros with Linux. (Notice
    Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

    Let's convert error() into now treewide-available pr_err().

    Done with the help of Coccinelle, excluing tools/ directory.

    The semantic patch I used is as follows:

    //
    @@@@
    -error
    +pr_err
    (...)
    //

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Simon Glass
    [trini: Re-run Coccinelle]
    Signed-off-by: Tom Rini

    Masahiro Yamada
     

01 Jun, 2017

1 commit

  • These support the flat device tree. We want to use the dev_read_..()
    prefix for functions that support both flat tree and live tree. So rename
    the existing functions to avoid confusion.

    In the end we will have:

    1. dev_read_addr...() - works on devices, supports flat/live tree
    2. devfdt_get_addr...() - current functions, flat tree only
    3. of_get_address() etc. - new functions, live tree only

    All drivers will be written to use 1. That function will in turn call
    either 2 or 3 depending on whether the flat or live tree is in use.

    Note this involves changing some dead code - the imx_lpi2c.c file.

    Signed-off-by: Simon Glass

    Simon Glass
     

27 Mar, 2017

2 commits

  • It is sometimes convenient to know how many and/or which resources are
    currently loaded into a TPG, e.g. to test is a flush operation succeeded.

    Hence, we add a command that lists the resources of a given type currently
    loaded into the TPM.

    Signed-off-by: Mario Six
    Reviewed-by: Simon Glass

    mario.six@gdsys.cc
     
  • If we want to load a key into a TPM, we need to know the designated parent
    key's handle, so that the TPM is able to insert the key at the correct place in
    the key hierarchy.

    However, if we want to load a key whose designated parent key we also
    previously loaded ourselves, we first need to memorize this parent key's handle
    (since the handles for the key are chosen at random when they are inserted into
    the TPM). If we are, however, unable to do so, for example if the parent key is
    loaded into the TPM during production, and its child key during the actual
    boot, we must find a different mechanism to identify the parent key.

    To solve this problem, we add a function that allows U-Boot to load a key into
    the TPM using their designated parent key's SHA1 hash, and the corresponding
    auth data.

    Signed-off-by: Mario Six
    Reviewed-by: Simon Glass

    mario.six@gdsys.cc
     

01 Feb, 2017

1 commit


03 Dec, 2016

1 commit