[U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal
Breno Matheus Lima
brenomatheus at gmail.com
Tue Apr 30 16:06:01 UTC 2019
Hi Bryan,
Em ter, 30 de abr de 2019 às 05:13, Bryan O'Donoghue
<bryan.odonoghue at linaro.org> escreveu:
>
>
>
> On 30/04/2019 02:28, Bryan O'Donoghue wrote:
> >
> >
> > On 25/04/2019 04:24, Breno Matheus Lima wrote:
> >> I couldn't get encrypted boot working in my first attempt, doing the
> >> exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl:
> >> assign job-rings to non-TrustZone") reverted works fine.
> >
> > Hi Breno,
> >
> > I noticed another patch from you re: dek blob, does that address this
> > issue for you are is this still a live thing ?
No, the patch I have recently submitted does not address the JR
TrustZone issue we are currently seeing with DEK blob decapsulation at
ROM level. I was not following AN12056 when I tried so I couldn't see
this other issue at first moment.
> >
> > If you are running in secure-world, and the BootROM dek blob stuff
> > validates job-ring ownership it _should_ be possible to flip the
> > ownership bits to what the BootROM expects and then back again.
> >
> > If its not working, presumably its because we aren't flipping ownership
> > at the right time.
>
> It occurred to me after I went to bed.
>
> The right thing to do is leave the BootROM settings up until we hand-off
> and then set the required post-boot settings.
>
> Something I reckon can be ~easily done in some sort of architectural
> handover preparation function.
>
> I'll spin that patchset.
Thanks for preparing a second version for this patchset, I see that
you have also replied to my other e-mail in "[PATCH 1/4] crypto/fsl:
Introduce API to save/restore job-ring context".
Your new proposal looks fine to me, I can test again.
Thanks,
Breno Lima
More information about the U-Boot
mailing list