[U-Boot] efi_loader: implementing non-volatile UEFI variables

[Wolfgang Denk]

Dear Takahiro,

In message <20190627051518.GB19527 at 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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made machine language; all the rest is the work of man.