From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Thu, 13 May 2021 18:32:13 +0200 Subject: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing In-Reply-To: References: <20210513030839.GC16848@laputa> <6876a081-8f16-e747-6036-471b48f60318@gmx.de> <20210513065054.GF16848@laputa> <0686AB79-8431-43A2-8EF6-7853DD29524B@gmx.de> <20210513072359.GI16848@laputa> <20210513083851.GA35365@laputa> Message-ID: <7b18594e-a1d9-dce2-ba48-627688ff7169@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 5/13/21 6:12 PM, Masami Hiramatsu wrote: > 2021?5?13?(?) 19:27 Ilias Apalodimas : >> >> 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 : >>>> >>>>>>>>> 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