On Sun, Mar 11, 2018 at 03:36:16PM +0100, Stefano Babic wrote: > Hi Everybody, > > I have applied 1-2 as Fabio suggested. I have a couple of comments for > this, too: > > On 10/03/2018 02:10, Breno Matheus Lima wrote: > > Hi Bryan, > > > > 2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>: > >> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior > >> to calling HAB authenticate function.") makes the DCD field being NULL a > >> dependency. > >> > >> This change though will break loading and executing of existing pre-signed > >> binaries on a u-boot update i.e. if this change is deployed on a board you > >> will be forced to redo all images on that board to NULL out the DCD. > >> > >> There is no prior guidance from NXP that the DCD must be NULL similarly > >> public guidance on usage of the HAB doesn't call out this NULL dependency > >> (see boundary devices link). > >> > >> Since later SoCs will reject a non-NULL DCD there's no reason to make a > >> NULL DCD a requirement, however if there is an actual dependency for later > >> SoCs the appropriate fix would be to do SoC version checking. > >> > >> Earlier SoCs are capable (and happy) to authenticate images with non-NULL > >> DCDs, we should not be forcing this change on downstream users - > >> particularly if it means those users now must rewrite their build systems > >> and/or redeploy signed images in the field. > >> > >> Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior > >> to calling HAB authenticate function.") > > > > We understand the concern being raised however would prefer to leave > > this as an error, and selected users relying on images with DCD > > pointers can modify the code accordingly. This does not just apply to > > new SoC’s but also applies to existing SoC’s. > > Anyway, this is not so easy to identify. What we current know is that > older SOCs have no problem if the pointer is not set to Null. I agree > with Brian that if some constraint is coming, it should be defined with > a version checking as we currently do for a lot of things (is_soc() to > be clear). > > I am quite lost because I do not know which SOCs are affected and which > not. What does it hide under "later SOCSs" ? Or better which new version > of HAB ? I know HAB was updated due to other issues - are the > corresponding SOC involved ? > > If a not-null DCD pointer affects just future SOCs, we should fix it > when these SOCs will be available. This means both new SOSs (imx8x) as > new version of supported SOCs (mx5 / mx6 / mx7). > > > Users performing such an > > update should definitely test the image prior to making an OTA > > available. > > I think this is another topic and not what Brian is trying to address. I > hope as you that *any* update is tested before deploying. But this is > unrelated. > > > It has never been intended for DCD to be used in any post > > boot image and we realize the lack of documentation is a hindsight by > > us, and we are currently addressing that with updated guidance. > > > > ok, thanks for this, very appreciated. > > Anyway, I am facing what we should do with this patch for 2018.03. As I > said, I am not forcing anyone and I have just picked up 1/3 and 2/3. But > IMHO, if there are not good reason to say that not raising an error > breaks a lot of supplied device, this should flow into 2018.03, too. And > then we get enough time to better explore this issue.
And I need an answer to this final part, before I can release v2018.03. Thanks all! -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot