Dear Ilias,
In message CAC_iWjLqouCEb=kcpomhHwDiM9Cdb_mOQDMTUAZ0G_dP9SuDxg@mail.gmail.com you wrote:
There have been thoughts about using signed environment storage before. This is manageable as long as your environment is read-only. But for writing ("env save") you need access to the private key to sign the new data. Do you have a good solution for this?
Not really, not anything secure anyway That's we we suggested letting the secure world deal with it.
Do you think this will work? When people who don;t know about U-Boot features and limitations try to come up with a solution it may simply not fit.
And the problem is a generic one: if you want to use secure boot with signed images (including the environment), you must make sure the device cannot be used to create new valid signed images, i. e. you must keep your private key strictly protectd and definitely not on the device. But then - how do you sign a new environment copy?
I understand the need for U-Boot to deal with volatile and non-volatile variables. I also know use-cases that would benefit from it (i.e the filesize you mentioned)
Adding that attribute on the the variables is fine. What is not fine is trying to apply UEFI semantics on the projects environmental variable subsystem, just because the volatile/non-volatile happens to be 'ok' for both UEFI/ENV variables. The attribute will only offer you some kind of UEFI variable "emulation".
Ok - but the patches that have been submitted modify (heavily) the U-Boot environment code.
So I see two options: a) we emulate UEFI variables using the existing U-Boot environment code to the extend possible; in this case I would prefer my proposal over the patches that have been submitted. Or b) UEFI data is handled completely separately, within it's own code base; in that case the patches should be ignored.
So what i'd ideally love to see is something like:
- UEFI variables get stored *somewhere* if a secure OS does not exist
and can't deal with Secure UEFI variables. We can then emulate the UEFI behavior with 0 security. In this scenario i can justify your proposal, which in fact makes sense.
Thanks - that would be case a).
- If A Secure OS runs (whether it's Arm/Intel/Whatever), we can
replace the read/store callbacks and have proper UEFI variables with full semantics for which, a secure world application will be responsible (and will be responsible for the storage as well)
That would be b) - in this case UEFI has to provide it's own code base, and no UEFI specific patches should impact the U-Boot environment handling.
I can understand that you want to have separate storage, and indeed it makes sense in other use cases as well. And actually I see this as one of the advantages of my proposal: you can have this as well easily, less intrusive and with less effort than the submitted patches. And with the additional benefit that it is usefoul for others as well.
Does my answer above cover this as well?
I think so - if my a) / b) separation above matches your understanding.
Thanks.
Best regards,
Wolfgang Denk