From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by mx.groups.io with SMTP id smtpd.web09.589.1659120015105313479 for ; Fri, 29 Jul 2022 11:40:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=USEbkSf3; spf=pass (domain: gmail.com, ip: 209.85.218.52, mailfrom: rafaelrodrigues.machado@gmail.com) Received: by mail-ej1-f52.google.com with SMTP id ez10so9954506ejc.13 for ; Fri, 29 Jul 2022 11:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y6ikLbIHYSBxPXEnhKAWTguzqrLmft+ym2WPMVjkvm8=; b=USEbkSf3oYWGqCHgNQpIHypSaXeOgrstREBFE8GpRSY6KvsQmt+wyAg0qGAEqTVcbU 6bUqToC8xRhaEAubE2WMmCx/xvlf6vN4aLpbA03o80jgkYKjC1LcrGICkyubqYREOhou ssuBFEBY0bWFys2VpZ1C3QjhziAOuFPDqEOEL3bCWs3oUr69tkIkjuhCyeSUzw9TI8kv wWrRthh1OvBrX/Fl2FiiHGoNOME3wrq2hO4UEcRV44eZ2q/vmBeD0352DeNYhPk94+yW vUeJwAftA2krVe2tKJkoc5AwHtXAY4nGAgh4sTAbXyLLt1bhNVwqUyaG/BshokKbcC4R 1qTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y6ikLbIHYSBxPXEnhKAWTguzqrLmft+ym2WPMVjkvm8=; b=Qk9j03vDGIYyPETkL+Uu4wYW2mMx0dkKq0q3E7XwC8ihmZt9Fjo8oNiVfO6zUQDBZi /s0SGwj08WMng+ci5u7jOhow4rQsvbs4caQfyKG9FUNY7BnG58z90NJje1PE491eLW1d pVRvMZdpR7zO34XxfAXrOQn2czKDQoCzWf2oBy72lDdgJSIOaBeXVPYH+P5cO4tFCd7E RKGPb8lROMqiml2KQ+fVlOYTL5FPzhWBwRmBQXFjVMz47j+PnfKQGmGhlYxTFrRA28Ud 2npVMy/XPw9M4YwYmtf5+ynj3HZbdgSY75wdK1u8ghYu/vmhPEGNBXInLuwxXxHAnJ8D NlNQ== X-Gm-Message-State: AJIora933FiZfgtoYT+A9oMKOzDZEY//TjBKUmuMXbPRBgyV/6lrtZme 4vZpHsOVsCB4QXZ5e+D7563180UdVmxHuDj/BrY= X-Google-Smtp-Source: AGRyM1tFB+0DB0fiKiM2MRmcuxRIiMoGvf451/j1MjG9tt3mYG6JTREf99LFO6fXfh6bs5yobqyYkQC4HQJ1HSTyv+c= X-Received: by 2002:a17:907:724c:b0:72e:e6fe:5ea4 with SMTP id ds12-20020a170907724c00b0072ee6fe5ea4mr3952748ejc.421.1659120013241; Fri, 29 Jul 2022 11:40:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Rafael Machado" Date: Fri, 29 Jul 2022 15:40:00 -0300 Message-ID: Subject: Re: [edk2-devel] Question about signed uefi vars at OS level To: James Bottomley Cc: devel@edk2.groups.io Content-Type: multipart/alternative; boundary="00000000000007700205e4f5fbfb" --00000000000007700205e4f5fbfb Content-Type: text/plain; charset="UTF-8" Hi James, thanks for the answer. I will try to explain my scenario in simple words. In my case, what I would like to do is to create a runtime uefi var, that would be changed only by one .exe I have developed. So other .exe would not be able to perform changes at this uefi var. Any ideia? Thanks Rafael On Tue, Jul 26, 2022, 10:17 AM James Bottomley < James.Bottomley@hansenpartnership.com> wrote: > 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 > > > --00000000000007700205e4f5fbfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi James, thanks for the answer.

I will try to explain my scenario in simple words.
In my case, what I would like to do is to create a runt= ime uefi var, that would be changed only by one .exe I have developed.=C2= =A0
So other .exe would not be able to perform chang= es at this uefi var.

Any= ideia?

Thanks
Rafael


On Tue, Jul 26, 2022, 10:17 AM James Bottomley <James.Bottomley@hansenpartnership.c= om> wrote:
On Tue, 2022-07-2= 6 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<= br> > 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<= br> > and that can be changed, by authorized person only, from OS level
> without the need of embedding my secret at the OS application (.exe)?<= br>
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.=C2=A0 If you want your=
application to make arbitrary updates while it's running, you probably<= br> don't want to be using signed variables.

James


--00000000000007700205e4f5fbfb--