From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Fri, 14 May 2021 16:13:56 +0900 Subject: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing In-Reply-To: <75d6f7c5-5300-4abc-3c78-02dc062f094c@gmx.de> References: <6876a081-8f16-e747-6036-471b48f60318@gmx.de> <20210513065054.GF16848@laputa> <0686AB79-8431-43A2-8EF6-7853DD29524B@gmx.de> <20210513072359.GI16848@laputa> <9d698932-ede5-eeea-b3d4-d2342675ac04@gmx.de> <20210514061949.GE15502@laputa> <75d6f7c5-5300-4abc-3c78-02dc062f094c@gmx.de> Message-ID: <20210514071356.GA28950@laputa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, May 14, 2021 at 08:59:38AM +0200, Heinrich Schuchardt wrote: > On 5/14/21 8:19 AM, AKASHI Takahiro wrote: > > On Thu, May 13, 2021 at 08:25:56PM +0200, Heinrich Schuchardt wrote: > > > On 5/13/21 10:18 AM, 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. > > > > ----------------- > > > > > > IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED bit is a property of the FMP driver. > > > > Yes, it is. But if the attribute is not changeable at all, > > why do we need this flag? > > Why does a "firmware image descriptor" hold two distinct > > member fields, "AttributesSupported" and "AttributesSetting"? > > What does "Setting" mean? Who sets what, and when? > > "Setting" means value here. None of these flags is set by the user. It > is the FMP driver that keeps track of the update state and sets the > flags accordingly. > > AttributesSupported indicates which bits in AttributesSetting contain > accurate information: > > 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 > Some bits indicate a property of the installed image, e.g. > IMAGE_ATTRIBUTE_UEFI_IMAGE. > > Some bits indicate a system state. E.g. IMAGE_ATTRIBUTE_IN_USE indicates > if the information reported by the FMP driver is for the currently used > image. This bit might be 0 in AttributesSetting if you have not yet > executed a reset after installing the new image and 1 after the reset. > > Best regards > > Heinrich > > > > > > > > > > > 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 > > > > > > > > Anyway, since this behavior follows the specification, it should be > > > > kept by default, > > > > but also IMHO, there should be a CONFIG option to enforce capsule > > > > authentication always. > > > > > > > > Thank you, > > > > > > > > > > > > > > > >