Dear Wolfgang, > > > > thanks a lot for the good online meeting this morning together with your > > colleague Suggan where we discussed the requirements for the > > implementation of non-volatile variables in U-Boot. > > > > Currently UEFI variables are stored in U-Boot variables. Saving the > > U-Boot variables will persist all UEFI variables in the environment both > > volatile and non-volatile. This does not conform the the UEFI standard. > > Is this the only problem of using the environment as storage? > No it's not. For UEFI secure variables you need authentication, signature checks amongst other things. > > To provide a secure storage Linaro is considering to implement an OP-TEE > > module for variable storage and as alternative to this OP-TEE module a > > standalone MM service which will be a BL32 ATF module. > > > > So in future we will have possibly three alternative drivers for UEFI > > variables: > > > > - U-Boot only implementation > > (what is now in lib/efi_loader/efi_variable.c) > > - OP-TEE module > > - standalone MM service > > > > And maybe a fourth dummy one implementing no variable service at all. > > Is this really a good idea? > > > If the volatile / non-volatile behaviour is the onlyh problem you > see with using environment variables, would it then not make much > more sense to extend the environment flags concept by adding a > "volatile" flag, with the meaing that such variables don;t get > written by "env save"? Yes but the volatile/non-volatile is the least of our problems
> > This would also make sense in some other places - for example, the > "filesize" variable is a perfect candidate to be flagged as > "volatile". There is absolutely no use in saving it persistently. > > > So such an extension would be useful for others, too, and might > eventually avoid so many different implementations for the same > task? Also, the implementation should be straightforward... You need Secure variables. That implies they should live in Non-Secure world nor you should store them is some NOr//NAND flash that you can manipulate under linux with fw_setenv. I personally think storing UEFI and U-Boot env variables in the *same* storage partition a bad idea. I also considering mixing apples and oranges. They are two completely different things. The fact that it was easy to use existing U-Boot primitives to make that happen does not make the approach correct. It just makes it easier. Rergards /Ilias _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
