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
