[PATCH 1/4] tools: mkeficapsule: add firmwware image signing
Heinrich Schuchardt
xypron.glpk at gmx.de
Thu May 13 18:32:13 CEST 2021
On 5/13/21 6:12 PM, Masami Hiramatsu wrote:
> 2021年5月13日(木) 19:27 Ilias Apalodimas <ilias.apalodimas at linaro.org>:
>>
>> On Thu, May 13, 2021 at 05:38:51PM +0900, AKASHI Takahiro wrote:
>>> On Thu, May 13, 2021 at 05:18:36PM +0900, Masami Hiramatsu wrote:
>>>> 2021年5月13日(木) 16:24 AKASHI Takahiro <takahiro.akashi at linaro.org>:
>>>>
>>>>>>>>> BTW, IMHO, if u-boot.bin can not find the ESL in the device tree,
>>>>>>>>> it should skip authentication too.
>>>>>>>>
>>>>>>>> In this case the capsule should be rejected (if
>>>>>>>> CONFIG_EFI_CAPSULE_AUTHENTICATE=y).
>>>>>>>
>>>>>>> That's basically right.
>>>>>>> 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.
>>>>>
>>>>> The requirement that I mentioned above is clearly described
>>>>> in UEFI specification.
>>>>> If you think that it is a disaster, please discuss the topic
>>>>> in UEFI Forum first.
>>>>
>>>> I confirmed UEFI specification, version 2.7, Section.23.1
>>>> the last of EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo()
>>>>
>>>> -----------------
>>>> If IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED is supported and clear, then
>>>> authentication is not required to perform the firmware image operations.
>>>> -----------------
>>>
>>> Thank you for citing this.
>>>
>>>> Oh, this is really crazy because deciding whether to authenticate the
>>>> suspicious
>>>> package or not, depends on whether the package said "please
>>>> authenticate me" or not. :D
>>>
>>> Well, the attributes can been fetched with GetInfo API, but
>>> how it is managed depends on the implementation of FMP drivers.
>>>
>>> As I proposed somewhere else, those attributes should be
>>> maintained in a separate place (maybe as part of system's policy),
>>> presumably ESRT or platform-specific internal database?
>>
>> FWIW I personally don't think we should even have a config option. But even
>> if we did it certainly must not be dictated by a hardware config.
>>
>> When you install distro packages you accept whatever dependencies the
>> package has. mkeficapsule is a capsule creation and signing tool. I don't
>> see any reason for keeping the creation and signing apart.
>
> My question is, since the U-Boot binary is heavily dependent on the target
> platform, can we split the u-boot.bin creation (may include embedding keys)
> and the capsule file creation (including signing)?
Building U-Boot and creating a capsule are totally separate. Maybe you
get the first capsule years after you buy your board. But this should
not stop us from building mkeficapsule when building U-Boot.
If you want to build tools only, you can do so with 'make tools'. The
tools target must include mkeficapsule irrespective of configuration.
This line in tools/Makefile must be corrected:
-hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
+hostprogs-y += mkeficapsule
Best regards
Heinrich
More information about the U-Boot
mailing list