1. 08 Sep, 2021 2 commits
    • Alexandru Gagniuc's avatar
      common: Move MD5 hash to hash_algo[] array. · fe54aeaa
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      MD5 is being called directly in some places, but it is not available
      via hash_lookup_algo("md5"). This is inconsistent with other hasing
      routines. To resolve this, add an "md5" entry to hash_algos[].
      The #ifdef clause looks funnier than those for other entries. This is
      because both MD5 and SPL_MD5 configs exist, whereas the other hashes
      do not have "SPL_" entries. The long term plan is to get rid of the
      ifdefs, so those should not be expected to survive much longer.
      The md5 entry does not have .hash_init/update/finish members. That's
      okay because hash_progressive_lookup_algo() will catch that, and
      return -EPROTONOSUPPORT, while hash_lookup_algo() will return the
      correct pointer.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [trini: Use CONFIG_IS_ENABLED not IS_ENABLED for MD5 check]
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
    • Alexandru Gagniuc's avatar
      common: Remove unused CONFIG_FIT_SHAxxx selectors · eb5171dd
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      Originally CONFIG_FIT_SHAxxx enabled specific SHA algos for and only
      for hash_calculate() in common/image-fit.c. However, since commit
       ("image: Drop IMAGE_ENABLE_SHAxxx"),
      the correct selector was changed to CONFIG_SHAxxx.
      The extra "_FIT_" variants are neither used, nor needed. Remove them.
      One defconfig disables FIT_SHA256, which is now changed to 'SHA256'.
      CMD_MVEBU_BUBT needs to select select SHA256 to avoid undefined
      references to "sha256_*()". bubt.c needs sha256, so this selection is
      correct. It is not clear why this problem did not manifest before.
      Note that SHA selection in SPL is broken for this exact reason. There
      is no corresponding SPL_SHAxxx. Fixing this is is beyond the scope of
      this change.
      Also note that we make CONFIG_FIT now imply SHA256, to make up for
      FIT_SHA256 previously being a default y option.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [trini: Add imply SHA256 to FIT]
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
  2. 16 Jul, 2021 11 commits
  3. 11 Jun, 2021 1 commit
  4. 22 Apr, 2021 1 commit
  5. 14 Apr, 2021 3 commits
  6. 27 Mar, 2021 1 commit
  7. 17 Mar, 2021 1 commit
  8. 18 Feb, 2021 1 commit
    • Alexandru Gagniuc's avatar
      image: Do not #if guard board_fit_image_post_process() prototype · 9e304239
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      There's no point in guarding function prototypes with #ifdefs. If a
      function is not defined, the linker will notice. Having the prototype
      does not affect code size.
      What the #if guard takes away is the ability to use IS_ENABLED:
      When the prototype is guarded, the above form cannot be used. This
      leads to the proliferation of #ifdefs, and unreadable code. The
      opportunity cost of the #if guard outweighs any benefits. Remove it.
      Since the original version of this patch, an empty definition was
      added by commit f14e6eec ("image: cleanup pre-processor usage").
      The empty definition can cause silent failures, when an implementation
      of board_fit_image_post_process() is expected because the linker will
      not catch the missing function. Thus this patch removes this empty
      inline declaration.
      Fixes: f14e6eec
       ("image: cleanup pre-processor usage")
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  9. 16 Feb, 2021 1 commit
  10. 11 Jan, 2021 1 commit
  11. 05 Jan, 2021 1 commit
  12. 30 Oct, 2020 1 commit
  13. 22 Oct, 2020 2 commits
  14. 13 Oct, 2020 1 commit
    • Philippe Reynes's avatar
      fit: cipher: aes: allow to store the IV in the FIT image · a6982a6f
      Philippe Reynes authored and Tom Rini's avatar Tom Rini committed
      Binaries may be encrypted in a FIT image with AES. This
      algo needs a key and an IV (Initialization Vector). The
      IV is provided in a file (pointer by iv-name-hint in the
      ITS file) when building the ITB file.
      This commits adds provide an alternative way to manage
      the IV. If the property iv-name-hint is not provided in
      the ITS file, the tool mkimage will generate an random
      IV and store it in the FIT image.
      Signed-off-by: default avatarPhilippe Reynes <philippe.reynes@softathome.com>
  15. 17 Jul, 2020 1 commit
    • Masahiro Yamada's avatar
      treewide: convert bd_t to struct bd_info by coccinelle · b75d8dc5
      Masahiro Yamada authored and Tom Rini's avatar Tom Rini committed
      The Linux coding style guide (Documentation/process/coding-style.rst)
      clearly says:
        It's a **mistake** to use typedef for structures and pointers.
      Besides, using typedef for structures is annoying when you try to make
      headers self-contained.
      Let's say you have the following function declaration in a header:
        void foo(bd_t *bd);
      This is not self-contained since bd_t is not defined.
      To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
        #include <asm/u-boot.h>
        void foo(bd_t *bd);
      Then, the include direcective pulls in more bloat needlessly.
      If you use 'struct bd_info' instead, it is enough to put a forward
      declaration as follows:
        struct bd_info;
        void foo(struct bd_info *bd);
      Right, typedef'ing bd_t is a mistake.
      I used coccinelle to generate this commit.
      The semantic patch that makes this change is as follows:
        typedef bd_t;
        +struct bd_info
      Signed-off-by: Masahiro Yamada ...
  16. 07 Jul, 2020 1 commit
  17. 12 Jun, 2020 1 commit
  18. 18 May, 2020 1 commit
    • Simon Glass's avatar
      command: Remove the cmd_tbl_t typedef · 09140113
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      We should not use typedefs in U-Boot. They cannot be used as forward
      declarations which means that header files must include the full header to
      access them.
      Drop the typedef and rename the struct to remove the _s suffix which is
      now not useful.
      This requires quite a few header-file additions.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  19. 17 Apr, 2020 1 commit
  20. 01 Apr, 2020 2 commits
  21. 12 Mar, 2020 3 commits
    • AKASHI Takahiro's avatar
      include: image.h: add key info to image_sign_info · a8fc3df8
      AKASHI Takahiro authored and Tom Rini's avatar Tom Rini committed
      For FIT verification, all the properties of a public key come from
      "control fdt" pointed to by fdt_blob. In UEFI secure boot, on the other
      hand, a public key is located and retrieved from dedicated signature
      database stored as UEFI variables.
      Added two fields may hold values of a public key if fdt_blob is NULL, and
      will be used in rsa_verify_with_pkey() to verify a signature in UEFI
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • AKASHI Takahiro's avatar
      lib: rsa: decouple rsa from FIT image verification · b983cc2d
      AKASHI Takahiro authored and Tom Rini's avatar Tom Rini committed
      Introduce new configuration, CONFIG_RSA_VERIFY which will decouple building
      RSA functions from FIT verification and allow for adding a RSA-based
      signature verification for other file formats, in particular PE file
      for UEFI secure boot.
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • Eugeniu Rosca's avatar
      image.h: isolate android_image_* functions from tooling · d08b16ed
      Eugeniu Rosca authored and Tom Rini's avatar Tom Rini committed
      On Feb. 16, 2020, Tom reported [1] build failure of U-Boot in-tree
      tooling after applying https://patchwork.ozlabs.org/cover/1229663/
      ("[v6,0/7] rsa: extend rsa_verify() for UEFI secure boot").
      Later on, Heinrich stressed the urgency of the issue in
       We should finalize the topic as it stops EFI patches from being merged
      On the surface, the problem is caused by U-Boot commits [2-3], which
      employed 'u32' in 'include/image.h', while historically U-Boot tooling
      stayed agnostic on the {u,s}{8,16,32} types.
      Thanks to Tom, Yamada-san and Heinrich, the following solutions have
      been put head-to-head ('+' pros, '-' cons):
       A. Use an equivalent fixed-size type, i.e. s/u32/uint32_t/ in both
          android function prototypes (image.h) and definitions (c file):
          + quick and low-line-count
          - creates a 'soup' of fixed-sized types in the Android C file
          - will confuse contributors
          - is going against Linux kernel best practices [4]
       B. Guard Android functions by '!defined(USE_HOSTCC)' in image.h:
          + quick and low-line-count
          + reflects the reality (no android function is used by tooling)
          + zero impact on other subsystems
          - ifdeffery may look annoying (pre-existing problem of image.h)
       C. Make {u8,u16,u32} available in U-Boot tooling:
          + quick and low-line-count
          + [Yamada-san][5]:
            * forbidding u32 for tools is questionable to me
            * Linux kernel and Barebox use {u8,u16,u32} for the tools space
          - breaks U-Boot tradition?
          - has larger impact than [A] and [B]
          - adds type complexity/inconsistency in the tooling space
       D. [Yamada-san] Refactor the headers to minimize the code shared
          between U-Boot space and tooling space:
          + probably the long-term solution
          - high effort
          - can be seen/done as an incremental update on top of [B]
      Looking at the above, [B] looks like the natural way to go forward.
      [1] https://patchwork.ozlabs.org/patch/1238245/#2363052
      [2] commit 7f253150 ("image: android: Add routine to get dtbo params")
      [3] commit c3bfad82 ("image: android: Add functions for handling dtb field")
      [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6176fa4728fb6d
          ("checkpatch: add --strict warning for c99 fixed size typedefs : int<size>_t")
      [5] https://patchwork.ozlabs.org/patch/1238245/#2363340
      Cc: Masahiro Yamada <masahiroy@kernel.org>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Sam Protsenko <joe.skb7@gmail.com>
      Cc: Lokesh Vutla <lokeshvutla@ti.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Reported-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      Signed-off-by: default avatarEugeniu Rosca <erosca@de.adit-jv.com>
      Tested-by: default avatarHeinrich Schuchardt <xpyron.glpk@gmx.de>
  22. 04 Feb, 2020 2 commits
    • Sam Protsenko's avatar
      image: android: Add routine to get dtbo params · 7f253150
      Sam Protsenko authored and Lokesh Vutla's avatar Lokesh Vutla committed
      Android Boot Image v1 adds "Recovery DTB" field in image header and
      associate payload in boot image itself [1]. Payload should be in
      Android DTB/DTBO format [2]. That "Recovery DTB" area should be only
      populated for non-A/B devices, and only in recovery image.
      Add function to get an address and size of that payload. That function
      can be further used e.g. in 'abootimg' command to provide the user a way
      to get the address of recovery dtbo from U-Boot shell, which can be
      further parsed using 'adtimg' command.
      [1] https://source.android.com/devices/bootloader/boot-image-header
      [2] https://source.android.com/devices/architecture/dto/partitions
      Signed-off-by: default avatarSam Protsenko <joe.skb7@gmail.com>
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
    • Sam Protsenko's avatar
      image: android: Add functions for handling dtb field · c3bfad82
      Sam Protsenko authored and Lokesh Vutla's avatar Lokesh Vutla committed
      Android Boot Image v2 adds "DTB" payload (and corresponding field in the
      image header). Provide functions for its handling:
        - android_image_get_dtb_by_index(): Obtain DTB blob from "DTB" part of
          boot image, by blob's index
        - android_image_print_dtb_contents(): Iterate over all DTB blobs in
          "DTB" part of boot image and print those blobs info
      "DTB" payload might be in one of the following formats:
        1. concatenated DTB blobs
        2. Android DTBO format
      The latter requires "android-image-dt.c" functionality, so this commit
      selects that file for building for CONFIG_ANDROID_BOOT_IMAGE option.
      Right now this new functionality isn't used, but it can be used further.
      As it's required to apply some specific dtbo blob(s) from "dtbo"
      partition, we can't automate this process inside of "bootm" command. But
      we can do next:
        - come up with some new command like "abootimg" to extract dtb blob
          from boot image (using functions from this patch)
        - extract desired dtbo blobs from "dtbo" partition using "adtimg"
        - merge dtbo blobs into dtb blob using "fdt apply" command
        - pass resulting dtb blob into bootm command in order to boot the
          Android kernel with Android ramdisk from boot image
      Signed-off-by: default avatarSam Protsenko <joe.skb7@gmail.com>
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>