| Message ID | 20240304153253.732708-6-dario.binacchi@amarulasolutions.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
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
diff --git a/boot/ti-k3-r5-loader/Config.in b/boot/ti-k3-r5-loader/Config.in index 8c8368a1a5a8..5f86c045c99f 100644 --- a/boot/ti-k3-r5-loader/Config.in +++ b/boot/ti-k3-r5-loader/Config.in @@ -16,7 +16,7 @@ choice here as it is used to build the main U-Boot package. config BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION - bool "2022.10" + bool "2024.01" config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION bool "Custom version" @@ -60,7 +60,7 @@ endif config BR2_TARGET_TI_K3_R5_LOADER_VERSION string - default "2022.10" if BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION + default "2024.01" if BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION_VALUE \ if BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION default "custom" if BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL 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 +sha256 b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3 u-boot-2024.01.tar.bz2 sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 Licenses/gpl-2.0.txt
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(-)