Hi all,
I think it's time to summarize the topics on this thread.
1. tools/mkeficapsule, config options dependency - The tools, especially useful and distributable tools like mkeficapsule should not be changed by the target board configuration. - Since there are target boards which don't need capsule authentication, it should be configurable. That also can optimize the library dependency.
2. tools/mkeficapsule, revert -K/-D options - Since these options are for embedding a public key in the devicetree, that is not related to the capsule file. Also, the same feature can be provided by a simple shell script.
3. capsule authentication, key embedding method - Embedding key in the devicetree is too fragile, especially, the document says overwriting new device tree including key with fdt command. That is not for the product, only for proof of concept. - Such a key should be embedded in the U-Boot, or hardware secure storage so that the user can not change it. (BTW, I think there are more options, like embedding keys in SCP firmware, TF-A, or OP-TEE, outside of U-Boot)
4. capsule authentication, authentication enablement - The UEFI spec said IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED can be supported but cleared (for the current running firmware). This means it is possible that the authentication feature is supported, but not enabled. - For ensuring security, if U-Boot is compiled with CONFIG_EFI_CAPSULE_AUTHETICATE=y, IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED must always be set.
Are there any other topics on this thread? and any other comments on these topics?
Thank you,
2021年5月14日(金) 18:51 AKASHI Takahiro takahiro.akashi@linaro.org:
Heinrich,
Can you please reply to each of my replies? Otherwise, I don't know which one of my comments/opinions you agree to and which one not.
On Fri, May 14, 2021 at 10:45:48AM +0200, Heinrich Schuchardt wrote:
On 5/14/21 9:13 AM, AKASHI Takahiro wrote:
E.g for IMAGE_ATTRIBUTE_IN_USE
AttributesSupported | AttributesSetting | Meaning --------------------+-------------------+-------------------- 0 | 0 | state is unknown 0 | 1 | state is unknown 1 | 0 | image is not in use 1 | 1 | image is in use
We are discussing *_REQUIRED. Can you give me the same table for *_REQUIRED?
-Takahiro Akashi
IMAGE_ATTRIBUTE_RESET_REQUIRED
AttributesSupported | AttributesSetting | Meaning --------------------+-------------------+-------------------- 0 | 0 | state is unknown 0 | 1 | state is unknown 1 | 0 | reset is not needed | | to complete upgrade 1 | 1 | reset is needed | | to complete upgrade
IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED
AttributesSupported | AttributesSetting | Meaning --------------------+-------------------+-------------------- 0 | 0 | state is unknown 0 | 1 | state is unknown 1 | 0 | signed and unsigned | | capsules are accepted 1 | 1 | capsules are only | | accepted after | | checking the signature
So what? This table shows there is a case where the authentication will be skipped even if CONFIG_EFI_CAPSULE_AUTHETICATE is on and it is completely compliant with UEFI specification.
That is what I and Masami was discussing.
But as I mentioned in my comment against Sughosh's patch, the authentication process will be enforced only if the capsule has an attribute, IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED.
That would be a security desaster.
So I said that you should discuss the topic in UEFI forum first if you think so.
-Takahiro Akashi
For both bits AttributesSupported=0 does not make much sense.
IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED is a property of the current image and should only be deleted by installing a new capsule.
A vendor might send you a special firmware image for unlocking your device after registering as a developer. Xiaomi handled it like this for one of my routers.
Best regards
Heinrich
-- Masami Hiramatsu