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

[Ilias Apalodimas]

Dear Wolfgang, Akashi-san,
On Thu, Jun 27, 2019 at 02:15:19PM +0900, AKASHI Takahiro wrote:
> Wolfgang,
> 
> I think that we are getting much closer than a few days ago,
> but first let me explain one point that I'm afraid that you
> might misunderstand somehow:
> 
> On Wed, Jun 26, 2019 at 11:44:03AM +0200, Wolfgang Denk wrote:
> > Dear Ilias,
> > 
> > In message <CAC_iWjLqouCEb=kcpomhHwDiM9Cdb_mOQDMTUAZ0G_dP9SuDxg at 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?
> 
I think you are are trying to suggest a common way for U-Boot to
support that, we are not.
The plan for us was to split UEFI and U-Boot variables and let StMM
deal will *all* UEFI variables (since that's what the application
does). As Takahiro nicely explained the vast majority of UEFI variables are not
Authenticated variables.

> 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.
> 
> More specifically to say,
> * each authenticated variable's data is composed of signature + value,
>   where the data format is well defined in UEFI specification.
> * signing algorithm is RSA2048, so there should be a pair of
>   private key and public key.
>   (I hope that you are familiar with those crypto concepts.)
> * Certificates or keys (public keys) to be used for authentication
>   are also stored as authenticated variables:
>   PK: Platform Key to be used for verifying signature of KEK 
>   KEK: Key Enabling Key to be used for verifying signature of db
>   db: Signature/Certificate database to be used for verifying signature
>       of PE image
>   (there are couples more, but we can ignore them for now.)
> 
> On the other hand,
> * 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 you follow me?
> 
> 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.
> 
> With the secure storage solution (for instance, dedicated OP-TEE app),
> all those verification stuff would be done securely (in secure world)
> and U-Boot doesn't have to know of public key, neither.
> 
> One big advantage of this solution is that, even if the system (in
> non-secure world) would be compromised, malware could not modify or
> destroy these signature database (PK, KEK or db).
> In another word, we can provide tamper-resistant storage.
> 
> Therefore, you claim above doesn't apply to our case (UEFI).
> 
> > > 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.
> 
> I have a different opinion here, but don't care now.
> I have not mentioned "secure" aspect of UEFI variables in my patch,
> but I didn't do so intentionally because I believe that it is an orthogonal
> issue to be discussed separately.
> 
> > 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:
> > > 1. 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).
> > 
> > > 2. 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.
> 
> 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.
> 
Same here b) is orthogonal to the rest imho
> @Ilias, please don't call my patch *emulation*. I'm always doing best
> to keep the implementation fully UEFI-compliant :)
Fair enough. The 'emulation' was not referring to the quality of the patch, 
but explain it will offer offer limited security compared to what running all 
these in secure world.


Thanks
/Ilias