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@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:
- 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.
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