[v9,05/22] boot/ti-k3-r5-loader: bump to version 2024.01

All in-tree configs with the ti-k3-r5 bootloader use a custom version,
so this patch is mostly for the menuconfig default version

Suggested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

no changes since v4

Added in v4

 boot/ti-k3-r5-loader/Config.in            | 4 ++--
 boot/ti-k3-r5-loader/ti-k3-r5-loader.hash | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
  

Dario, All,

On 2024-03-04 16:32 +0100, Dario Binacchi spake thusly:
> All in-tree configs with the ti-k3-r5 bootloader use a custom version,
> so this patch is mostly for the menuconfig default version
> 
> Suggested-by: Romain Naour <romain.naour@smile.fr>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
[--SNIP--]
> diff --git a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> index c5d1cb8e09f0..fbe5d215409d 100644
> --- a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> +++ b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> @@ -1,3 +1,3 @@
>  # Locally computed:
> -sha256  50b4482a505bc281ba8470c399a3c26e145e29b23500bc35c50debd7fa46bdf8  u-boot-2022.10.tar.bz2

Removing this hash means that defconfigs that still reference the
2022.10 version, no longer have a hash to validate the download against,
which make it susceptible to CVE-2023-43608 [0] [1].

That was already the case for the two ti-am6?x defconfig in the the two
previous patches, as they already used a custom kernel, a custm ATF, a
custom u-boot: the hashes can't be checked for those versions, so the
two ti am?x defconfigs already hit CVE-2023-43608.

We already fixed another defconfig for a similar issue, see commit
9ebbfeff387 (configs/rock5b: add hash for custom kernel).

Could you look into doing the same for those to TI am6?x defconfig,
please?

In the meantime, I kept the hash for 2022.10 for ti-k3-r5-loader
(really, for uboot), to abvoid the issue at least for ti-k3-r5-loader.

Speaking of that, by the way, ti-k3-r5-loader really is uboot, so I
think that it should share:

 1. the same DL_DIR:   TI_K3_R5_LOADER_DL_SUBDIR = uboot

 2. the same hash file:  have ti-k3-r5-loader.hash be a symlink to
    uboot.hash  (and have a xomment at the top of that hash file that it
    is shared and that old hashes should/can be kept)

Do you think that makes sense? If so, would you like to look into it?

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-43608
[1] https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844

Regards,
Yann E. MORIN.

> +sha256  b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3  u-boot-2024.01.tar.bz2
>  sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  Licenses/gpl-2.0.txt
> -- 
> 2.43.0
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
  

Hi Yann,

On Tue, Mar 19, 2024 at 11:09:32PM +0100, Yann E. MORIN wrote:
> Dario, All,
> 
> On 2024-03-04 16:32 +0100, Dario Binacchi spake thusly:
> > All in-tree configs with the ti-k3-r5 bootloader use a custom version,
> > so this patch is mostly for the menuconfig default version
> > 
> > Suggested-by: Romain Naour <romain.naour@smile.fr>
> > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> [--SNIP--]
> > diff --git a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > index c5d1cb8e09f0..fbe5d215409d 100644
> > --- a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > +++ b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > @@ -1,3 +1,3 @@
> >  # Locally computed:
> > -sha256  50b4482a505bc281ba8470c399a3c26e145e29b23500bc35c50debd7fa46bdf8  u-boot-2022.10.tar.bz2
> 
> Removing this hash means that defconfigs that still reference the
> 2022.10 version, no longer have a hash to validate the download against,
> which make it susceptible to CVE-2023-43608 [0] [1].
> 
> That was already the case for the two ti-am6?x defconfig in the the two
> previous patches, as they already used a custom kernel, a custm ATF, a
> custom u-boot: the hashes can't be checked for those versions, so the
> two ti am?x defconfigs already hit CVE-2023-43608.
> 
> We already fixed another defconfig for a similar issue, see commit
> 9ebbfeff387 (configs/rock5b: add hash for custom kernel).
> 
> Could you look into doing the same for those to TI am6?x defconfig,
> please?
> 
> In the meantime, I kept the hash for 2022.10 for ti-k3-r5-loader
> (really, for uboot), to abvoid the issue at least for ti-k3-r5-loader.
> 
> Speaking of that, by the way, ti-k3-r5-loader really is uboot, so I
> think that it should share:
> 
>  1. the same DL_DIR:   TI_K3_R5_LOADER_DL_SUBDIR = uboot
> 
>  2. the same hash file:  have ti-k3-r5-loader.hash be a symlink to
>     uboot.hash  (and have a xomment at the top of that hash file that it
>     is shared and that old hashes should/can be kept)
>

The entire boot chain for TI K3 devices (like all of AM62x) comprising
what's known as ti-k3-r5-loaer in Buildroot as well as U-Boot SPL/U-Boot
[proper] should _always_ be built from the same U-Boot source commit, as
this is how it's developed, tested, and used by pretty much everybody.
So your suggestion to more closely tie those things together makes a lot
of sense IMHO.

--
Andreas Dannenberg
Texas Instruments Inc



> Do you think that makes sense? If so, would you like to look into it?
> 
> [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-43608
> [1] https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844
> 
> Regards,
> Yann E. MORIN.
> 
> > +sha256  b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3  u-boot-2024.01.tar.bz2
> >  sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  Licenses/gpl-2.0.txt
> > -- 
> > 2.43.0
> > 
> > _______________________________________________
> > buildroot mailing list
> > buildroot@buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot
> 
> -- 
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
  

Andreas, All,

On 2024-03-19 21:18 -0500, Andreas Dannenberg via buildroot spake thusly:
> On Tue, Mar 19, 2024 at 11:09:32PM +0100, Yann E. MORIN wrote:
> > On 2024-03-04 16:32 +0100, Dario Binacchi spake thusly:
> > > All in-tree configs with the ti-k3-r5 bootloader use a custom version,
> > > so this patch is mostly for the menuconfig default version
[--SNIP--]
> > Speaking of that, by the way, ti-k3-r5-loader really is uboot, so I
> > think that it should share:
> >  1. the same DL_DIR:   TI_K3_R5_LOADER_DL_SUBDIR = uboot
> >  2. the same hash file:  have ti-k3-r5-loader.hash be a symlink to
> >     uboot.hash  (and have a xomment at the top of that hash file that it
> >     is shared and that old hashes should/can be kept)
> The entire boot chain for TI K3 devices (like all of AM62x) comprising
> what's known as ti-k3-r5-loaer in Buildroot as well as U-Boot SPL/U-Boot
> [proper] should _always_ be built from the same U-Boot source commit, as
> this is how it's developed, tested, and used by pretty much everybody.
> So your suggestion to more closely tie those things together makes a lot
> of sense IMHO.

Ah, interesting, thanks for the feedback.

So, it looks like for the situation for ti-k3-r5-loaer vs. U-Boot is
very similar to the one for barebox: it can build a "base" barebox, and
an "aux" barebox; they both share the same implementation (the
barebox-package mini-infra), they each provide their own (def|.)config
file, and they each have their own set of (Buildroot) options (the aux
one has fewer options).

So it looks like this is what we should have done for ti-k3-r5-loaer,
no?

Also, does it make sense to use ti-k3-r5-loaer without U-Boot?

Regards,
Yann E. MORIN.
  

Hi Yann,

On Wed, Mar 20, 2024 at 07:14:06AM +0100, Yann E. MORIN wrote:
> Andreas, All,
> 
> On 2024-03-19 21:18 -0500, Andreas Dannenberg via buildroot spake thusly:
> > On Tue, Mar 19, 2024 at 11:09:32PM +0100, Yann E. MORIN wrote:
> > > On 2024-03-04 16:32 +0100, Dario Binacchi spake thusly:
> > > > All in-tree configs with the ti-k3-r5 bootloader use a custom version,
> > > > so this patch is mostly for the menuconfig default version
> [--SNIP--]
> > > Speaking of that, by the way, ti-k3-r5-loader really is uboot, so I
> > > think that it should share:
> > >  1. the same DL_DIR:   TI_K3_R5_LOADER_DL_SUBDIR = uboot
> > >  2. the same hash file:  have ti-k3-r5-loader.hash be a symlink to
> > >     uboot.hash  (and have a xomment at the top of that hash file that it
> > >     is shared and that old hashes should/can be kept)
> > The entire boot chain for TI K3 devices (like all of AM62x) comprising
> > what's known as ti-k3-r5-loaer in Buildroot as well as U-Boot SPL/U-Boot
> > [proper] should _always_ be built from the same U-Boot source commit, as
> > this is how it's developed, tested, and used by pretty much everybody.
> > So your suggestion to more closely tie those things together makes a lot
> > of sense IMHO.
> 
> Ah, interesting, thanks for the feedback.
> 
> So, it looks like for the situation for ti-k3-r5-loaer vs. U-Boot is
> very similar to the one for barebox: it can build a "base" barebox, and
> an "aux" barebox; they both share the same implementation (the
> barebox-package mini-infra), they each provide their own (def|.)config
> file, and they each have their own set of (Buildroot) options (the aux
> one has fewer options).
> 
> So it looks like this is what we should have done for ti-k3-r5-loaer,
> no?

I'm not familiar with barebox but what you are describing looks similar.
Note that ti-k3-r5-loader (building the initial boot binary) is building
for 32-bit ARMv7, and the next boot stages (U-Boot SPL, U-Boot) are all
64-bit ARMv8, so this might complicate any possible unification efforts.
 
> Also, does it make sense to use ti-k3-r5-loaer without U-Boot?

Yes, you could do "Falcon Boot" where the ti-k3-r5-loader would directly
load the Linux kernel, greatly simplifing the boot flow and booting much
MUCH faster. Actually it's a much-requested feature from our customers
(you know, the real world use cases :) so I wrote a technical note [1]
about that last year on how to set this up manually but it would be
great if we could bring this into Buildroot as a package/option somehow
at some point, after we get the base support accepted into the tree.

[1]
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1205638/faq-am625-how-to-boot-from-r5-u-boot-spl-directly-into-the-linux-kernel-skipping-a53-spl-and-a53-u-boot-falcon-mode


--
Andreas Dannenberg
Texas Instruments Inc




> 
> Regards,
> Yann E. MORIN.
> 
> -- 
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
  

Hi Yann,

On Tue, Mar 19, 2024 at 11:09 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Dario, All,
>
> On 2024-03-04 16:32 +0100, Dario Binacchi spake thusly:
> > All in-tree configs with the ti-k3-r5 bootloader use a custom version,
> > so this patch is mostly for the menuconfig default version
> >
> > Suggested-by: Romain Naour <romain.naour@smile.fr>
> > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> [--SNIP--]
> > diff --git a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > index c5d1cb8e09f0..fbe5d215409d 100644
> > --- a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > +++ b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > @@ -1,3 +1,3 @@
> >  # Locally computed:
> > -sha256  50b4482a505bc281ba8470c399a3c26e145e29b23500bc35c50debd7fa46bdf8  u-boot-2022.10.tar.bz2
>
> Removing this hash means that defconfigs that still reference the
> 2022.10 version, no longer have a hash to validate the download against,
> which make it susceptible to CVE-2023-43608 [0] [1].
>
> That was already the case for the two ti-am6?x defconfig in the the two
> previous patches, as they already used a custom kernel, a custm ATF, a
> custom u-boot: the hashes can't be checked for those versions, so the
> two ti am?x defconfigs already hit CVE-2023-43608.
>
> We already fixed another defconfig for a similar issue, see commit
> 9ebbfeff387 (configs/rock5b: add hash for custom kernel).
>
> Could you look into doing the same for those to TI am6?x defconfig,
> please?

Thanks for the info.
Yes I will add a patch for this point in version 10 of the series.

>
> In the meantime, I kept the hash for 2022.10 for ti-k3-r5-loader
> (really, for uboot), to abvoid the issue at least for ti-k3-r5-loader.
>
> Speaking of that, by the way, ti-k3-r5-loader really is uboot, so I
> think that it should share:
>
>  1. the same DL_DIR:   TI_K3_R5_LOADER_DL_SUBDIR = uboot
>
>  2. the same hash file:  have ti-k3-r5-loader.hash be a symlink to
>     uboot.hash  (and have a xomment at the top of that hash file that it
>     is shared and that old hashes should/can be kept)
>
> Do you think that makes sense? If so, would you like to look into it?

I think like you that where possible it is better not to replicate code.
This series has been ongoing since November 2023, started to fix the
compilation for the HS_FS device for the ti_am62x_sk_defconfig configuration.
During the review process, it has added additional patches
(ti_am64x_sk_defconfig,
and removal of the ti-k3-image-gen package) which still today have not
allowed the
series to be merged and therefore to fix the issue.
So, I would prefer to address this aspect in a separate series from
this one in order
not to further slow it down.
Do you agree?

Thanks and regards,
Dario
>
> [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-43608
> [1] https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844
>
> Regards,
> Yann E. MORIN.
>
> > +sha256  b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3  u-boot-2024.01.tar.bz2
> >  sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  Licenses/gpl-2.0.txt
> > --
> > 2.43.0
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot@buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
  

Hi Yann,

On Sun, Mar 24, 2024 at 05:22:33PM +0100, Dario Binacchi wrote:
> Hi Yann,
> 
> On Tue, Mar 19, 2024 at 11:09 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >
> > Dario, All,
> >
> > On 2024-03-04 16:32 +0100, Dario Binacchi spake thusly:
> > > All in-tree configs with the ti-k3-r5 bootloader use a custom version,
> > > so this patch is mostly for the menuconfig default version
> > >
> > > Suggested-by: Romain Naour <romain.naour@smile.fr>
> > > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > [--SNIP--]
> > > diff --git a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > > index c5d1cb8e09f0..fbe5d215409d 100644
> > > --- a/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > > +++ b/boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> > > @@ -1,3 +1,3 @@
> > >  # Locally computed:
> > > -sha256  50b4482a505bc281ba8470c399a3c26e145e29b23500bc35c50debd7fa46bdf8  u-boot-2022.10.tar.bz2
> >
> > Removing this hash means that defconfigs that still reference the
> > 2022.10 version, no longer have a hash to validate the download against,
> > which make it susceptible to CVE-2023-43608 [0] [1].
> >
> > That was already the case for the two ti-am6?x defconfig in the the two
> > previous patches, as they already used a custom kernel, a custm ATF, a
> > custom u-boot: the hashes can't be checked for those versions, so the
> > two ti am?x defconfigs already hit CVE-2023-43608.
> >
> > We already fixed another defconfig for a similar issue, see commit
> > 9ebbfeff387 (configs/rock5b: add hash for custom kernel).
> >
> > Could you look into doing the same for those to TI am6?x defconfig,
> > please?
> 
> Thanks for the info.
> Yes I will add a patch for this point in version 10 of the series.
> 
> >
> > In the meantime, I kept the hash for 2022.10 for ti-k3-r5-loader
> > (really, for uboot), to abvoid the issue at least for ti-k3-r5-loader.
> >
> > Speaking of that, by the way, ti-k3-r5-loader really is uboot, so I
> > think that it should share:
> >
> >  1. the same DL_DIR:   TI_K3_R5_LOADER_DL_SUBDIR = uboot
> >
> >  2. the same hash file:  have ti-k3-r5-loader.hash be a symlink to
> >     uboot.hash  (and have a xomment at the top of that hash file that it
> >     is shared and that old hashes should/can be kept)
> >
> > Do you think that makes sense? If so, would you like to look into it?
> 
> I think like you that where possible it is better not to replicate code.
> This series has been ongoing since November 2023, started to fix the
> compilation for the HS_FS device for the ti_am62x_sk_defconfig configuration.
> During the review process, it has added additional patches
> (ti_am64x_sk_defconfig,
> and removal of the ti-k3-image-gen package) which still today have not
> allowed the
> series to be merged and therefore to fix the issue.
> So, I would prefer to address this aspect in a separate series from
> this one in order
> not to further slow it down.

I'd like to finish GPU support for AM6xx too and push this here, but as
long as we don't have base support I'm kind of blocked on this. And
that's probably just one example. I think as long as there are no
regressions in what this series is trying to do why not agree to merge &
iterate to get the base support out of the way. But definitely
appreciating all your great feedback here for further improvement so
please don't mis-interpret my comment.

--
Andreas Dannenberg
Texas Instruments Inc



> Do you agree?
> 
> Thanks and regards,
> Dario
> >
> > [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-43608
> > [1] https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844
> >
> > Regards,
> > Yann E. MORIN.
> >
> > > +sha256  b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3  u-boot-2024.01.tar.bz2
> > >  sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  Licenses/gpl-2.0.txt
> > > --
> > > 2.43.0
> > >
> > > _______________________________________________
> > > buildroot mailing list
> > > buildroot@buildroot.org
> > > https://lists.buildroot.org/mailman/listinfo/buildroot
> >
> > --
> > .-----------------.--------------------.------------------.--------------------.
> > |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> > | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> > | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> > '------------------------------^-------^------------------^--------------------'
> 
> 
> 
> -- 
> 
> Dario Binacchi
> 
> Senior Embedded Linux Developer
> 
> dario.binacchi@amarulasolutions.com
> 
> __________________________________
> 
> 
> Amarula Solutions SRL
> 
> Via Le Canevare 30, 31100 Treviso, Veneto, IT
> 
> T. +39 042 243 5310
> info@amarulasolutions.com
> 
> www.amarulasolutions.com