public inbox for docs@lists.yoctoproject.org
 help / color / mirror / Atom feed
From: "Antonin Godard" <antonin.godard@bootlin.com>
To: <adrian.freihofer@gmail.com>, <docs@lists.yoctoproject.org>
Cc: "Adrian Freihofer" <adrian.freihofer@siemens.com>
Subject: Re: [docs] [PATCH v4] ref-manual: variable FIT_SIGN_INDIVIDUAL mix-and-match attacks
Date: Tue, 11 Mar 2025 10:44:25 +0100	[thread overview]
Message-ID: <D8DC94EMPAUY.3ASDHXXPWWW8C@bootlin.com> (raw)
In-Reply-To: <20250310205619.8884-1-adrian.freihofer@siemens.com>

Hi Adrian,

On Mon Mar 10, 2025 at 9:56 PM CET, Adrian Freihofer via lists.yoctoproject.org wrote:
> Incorporate the lessons learned from a regression introduced with commit
>   OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e
>                u-boot: kernel-fitimage: Fix dependency loop if
>                UBOOT_SIGN_ENABLE and UBOOT_ENV enabled
> and fixed with commit
>   OE-Core rev: 0106e5efab99c8016836a2ab71e2327ce58a9a9d
>                u-boot: kernel-fitimage: Restore FIT_SIGN_INDIVIDUAL="1"
>                behavior
> into the documentation.
>
> The use of the variable FIT_SIGN_INDIVIDUAL is explicitly discouraged.
> It is also noted that this variable may be removed. It is important that
> we try to simplify the implementation of the FIT image as much as
> possible. Adding appropriate notes to the documentation is a first step
> towards this direction.
>
> Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
> ---
>  documentation/ref-manual/variables.rst | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 861b04eaab1..aa8a894bfd2 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -3174,9 +3174,27 @@ system and gives an overview of their function and contents.
>        class will sign the kernel, dtb and ramdisk images individually in addition
>        to signing the FIT image itself. This could be useful if you are
>        intending to verify signatures in another context than booting via
> -      U-Boot.
> +      U-Boot. This variable is set to "0" by default.
>  
> -      This variable is set to "0" by default.
> +      If :term:`UBOOT_SIGN_ENABLE` is set to "1" and :term:`FIT_SIGN_INDIVIDUAL`
> +      is left at its default value of "0", only the configurations are signed.
> +      However, the configuration signatures include the hashes of the referenced
> +      nodes. This means that the integrity of the entire FIT image is ensured
> +      because each hash is compared against a runtime-computed hash for each
> +      node.
> +      Further information can be found in the U-Boot documentation:
> +      `U-Boot fit signature <https://docs.u-boot.org/en/latest/usage/fit/signature.html>`__
> +      and more specifically at:
> +      `U-Boot signed configurations <https://docs.u-boot.org/en/latest/usage/fit/signature.html#signed-configurations>`__.
> +
> +      If :term:`UBOOT_SIGN_ENABLE` is set to "1" and :term:`FIT_SIGN_INDIVIDUAL`
> +      is set to "1", then the FIT image is signed twice, which is redundant.
> +      As this leads to additional complexity without providing any obvious
> +      advantage, this feature will likely be removed in a future version.
> +
> +      Signing only the image nodes is intentionally not implemented by
> +      :term:`OpenEmbedded-Core (OE-Core)`, as it is vulnerable to mix-and-match
> +      attacks.
>  
>     :term:`FIT_SIGN_NUMBITS`
>        Size of the private key used in the FIT image, in number of bits.

Looking good, thanks

Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>

Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


      reply	other threads:[~2025-03-11  9:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 20:56 [PATCH v4] ref-manual: variable FIT_SIGN_INDIVIDUAL mix-and-match attacks Adrian Freihofer
2025-03-11  9:44 ` Antonin Godard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D8DC94EMPAUY.3ASDHXXPWWW8C@bootlin.com \
    --to=antonin.godard@bootlin.com \
    --cc=adrian.freihofer@gmail.com \
    --cc=adrian.freihofer@siemens.com \
    --cc=docs@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox