On 18/05/2020 13:35, François Ozog wrote: [...]
> The problem with warmstart memory is that memory discovery or timing training using writes, or simply a firmware erasing all memory may result in failure. Warmstart memory does 100% require the platform reliably being able to preserve warmstart memory. I don't see that as any different from any of the other things we require the platform to do correctly. We've got influence over TF-A on up for a lot of these platforms. Warmboot requirements can be speced out, and platforms that are not capable must then not use a warmboot approach.Isn't this mean indirectly that we need a form of requirements equivalent to SBBR/SBSA ? -> EBBR/EBSA?
I think this remains in the EBBR domain. Arm does not have an equivalent of SBSA for the embedded space because we're not aiming in embedded for the level of standardization as required in the server world.
We do need to be careful about the warmboot language. It is an implementation option that won't always be needed:
- Secureworld had dedicated storage: runtime updates committed immediately - Secureworld uses eMMC/UFS RPMB: warmboot allows variable updates in ram to be committed after reboot. - Secureworld uses eMMC/UFS RPMB, but OP-TEE supplicant running: runtime updates committed immediately.
Are there any hardware that can be used as "mailboxes" between the past and next environments of a warm boot?
Possibly, but that is a very platform specific question. DRAM or SRAM would be the common case.
Would it be a TPM corner use case?
How much scratch ram is available in a TPM device? I didn't think TPMs exposed general purpose memory
A secure storage warmboot exchange area?
Depends on what code is committing the change. Alternatively it could be stored in normal world RAM as long as it get preserved over a warm reboot.
g.
> > Best regards > > Heinrich > >> >>> Takahiro Akashi last year presented alternative patches that would >>> enable reading variables at runtime. He recently suggested to use >>> capsule updates to update variables and has submitted patches for >>> capsule updates >>> (https://patchwork.ozlabs.org/project/uboot/list/?series=172907). >>> >>> If we do not have SetVariable() at runtime, I do not see much value >> in >>> QueryVariableInfo(). So we shouldn't make that service compulsory. >> >> Agreed >> >> Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at >> some point in the future, but leaving SetVariable()/QueryVariableInfo() >> >> optional. However, I won't do anything in this direction for the point >> release later this month. I'll just clean up the text to be a bit >> clearer. >> >> g. >> _______________________________________________ >> boot-architecture mailing list >> boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/boot-architecture > _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/boot-architecture-- François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog