From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by mx.groups.io with SMTP id smtpd.web10.6467.1658841468046365380 for ; Tue, 26 Jul 2022 06:17:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=xmoix2EH; spf=pass (domain: hansenpartnership.com, ip: 96.44.175.130, mailfrom: james.bottomley@hansenpartnership.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1658841467; bh=iK6+26+XrZNLb2wTXTS8OzUf5UC6izLEBUXMEIG7sMw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=xmoix2EH6v+w1RTQXuR70s/SIsfIXwSZSWnUGwexOLHdZBN6VbyalYki2HLkWpTjE l0wpLd6VYryiPWVMr5MOw/QPYwHBjtRf4VkgVZavDI0QswweDNK2IO3rA/fjw3XMDQ UOISJhzxd+88z/J8twcNhGtMG6zN4i85OGgC5muY= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 49EBE1287930; Tue, 26 Jul 2022 09:17:47 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu0ZL-lDIQDd; Tue, 26 Jul 2022 09:17:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1658841467; bh=iK6+26+XrZNLb2wTXTS8OzUf5UC6izLEBUXMEIG7sMw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=xmoix2EH6v+w1RTQXuR70s/SIsfIXwSZSWnUGwexOLHdZBN6VbyalYki2HLkWpTjE l0wpLd6VYryiPWVMr5MOw/QPYwHBjtRf4VkgVZavDI0QswweDNK2IO3rA/fjw3XMDQ UOISJhzxd+88z/J8twcNhGtMG6zN4i85OGgC5muY= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4300:c551:a71:90ff:fec2:f05b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id BA39C128791F; Tue, 26 Jul 2022 09:17:46 -0400 (EDT) Message-ID: Subject: Re: [edk2-devel] Question about signed uefi vars at OS level From: "James Bottomley" To: devel@edk2.groups.io, rafaelrodrigues.machado@gmail.com Date: Tue, 26 Jul 2022 09:17:45 -0400 In-Reply-To: References: User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2022-07-26 at 10:09 -0300, Rafael Machado wrote: > Hey everyone > > I have a question for the experts. > > Suppose I have a BIOS feature that can be set from the OS via some OS > application (.exe) that calls the runtime services set variable (). > > To set this feature I have a UEFI var, that during DXE is processed > by some uefi module. > > In case I define this UEFI var as signed var > (EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS or > EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCES), at my OS > application I will have to add the signing key, so it would be > possible to create new signed data to change the uefi variable as > needed from the OS level. > > So my question is: > What is the correct way of creating a UEFI variable that is protected > and that can be changed, by authorized person only, from OS level > without the need of embedding my secret at the OS application (.exe)? You don't give your use case, so it's hard to answer the above. However, the signing process of the update must be guarded because of the need to keep the key secret, so update bundles are usually created away from the system to be updated to preserve this. If you want your application to make arbitrary updates while it's running, you probably don't want to be using signed variables. James