Dear Takahiro,
In message 20190627051518.GB19527@linaro.org you wrote:
In UEFI environment, *not* all the variables are to be authenticated, but just a few. The signature verification for such "authenticated" variables should be done *per* variable.
I see.
- authenticated variables can only be updated via UEFI API, SetVariable(u16 *variable_name, const efi_guid_t *vendor, u32 attributes, efi_uintn_t data_size, const void *data); where data must have been already formatted as I explained above.
- All UEFI does here are:
- decode data and retrieve a signature
- verify this signature with one of certificates in "db"
Do I understand correctly that the user who wants to change the value of such a authenticated variable, has to provide both the value plus the signature through the user interface?
So preparing data for authenticated variables are totally up to users, and U-Boot doesn't have to know about any private keys for signing. Once the system is properly constructed and installed with right cerficates, we will be able to store keys offline.
Understood. Thanks for the explanation.
That is the reason why I think b) is an orthogonal issue. Anyhow, there expected to be lots of platforms where users want to use UEFI U-Boot without requiring secure boot. Even on such platforms, my patch will provide more UEFI-compliant semantics of UEFI variables.
This is ok with me. But if this is really orthogonal, then it should be so also code-wise. I don't like such intrusive modifications of the U-Boot environment code for purposes that have nothing to do with U-Boot environment variables.
Either we store in (in the simple, non-secure) case UEFI variables a spart of the environment (see my proposal), then we don;t need your patches. Or you provide a separate UEFI data storage solution (which may be configred with or without secure boot support), but then this should be completely separate from the environment code.
Thanks!
Wolfgang Denk