Date   

Re: [edk2-devel] [RFC] Secure boot default key

Laszlo Ersek
 

On 04/29/21 09:17, Grzegorz Bernacki wrote:
Hi Laszlo,

Please find diff at following link:
https://drive.google.com/file/d/1ZEzNUjaz9PiQPnQlIfsHYiJ6ZCda_szD/view?usp=sharing
Thank you; the updates look fine to me.

Laszlo


thanks,
greg

śr., 28 kwi 2021 o 18:55 Laszlo Ersek <lersek@redhat.com> napisał(a):

Hi Greg,

On 04/28/21 12:50, Grzegorz Bernacki wrote:
Hi,

Thanks a lot for reviewing my previous document. Please see below link to
updated design:
https://drive.google.com/file/d/11yNJJ2x8WXYZRg1nZWrr4C4Hq89Izn1D/view?usp=sharing

Changes:
- remove unnecessary description of default variables
- add macros to specify default keys files
- add fdf include file
- add UI to reset the content of the keys to default values
the master format for this document seems to be LaTeX (from the "pdf
properties" window in evince), which is fantastic: can you please post a
diff between the v1 and v2 LaTeX sources?

I can only deal with incremental reviews for v2 and later postings. Most
WYSIWYG document editors nowadays support one form of change tracking or
another. Working with a plaintext source format such as LaTeX is always
best, of course. My only request is then, "diffs please".

The rendered format is absolutely welcome in addition to the diffs, of
course.

Thanks
Laszlo



Please let me know if you have any questions/comments/concerns.
thanks,
greg

pon., 19 kwi 2021 o 11:07 Grzegorz Bernacki <gjb@semihalf.com>
napisał(a):

Hi Laszlo,

Thanks a lot for your review. I will wait some time for more comments
and I will send an updated design.
thanks,
greg

pt., 16 kwi 2021 o 14:16 Laszlo Ersek <lersek@redhat.com> napisał(a):

On 04/16/21 14:10, Laszlo Ersek wrote:
On 04/15/21 13:59, Grzegorz Bernacki wrote:
Hello,

I would like to ask you to review the proposal for new application
for
enrolling Secure Boot keys. The application uses content of
PKDefault,
KEKDefault, dbDefault, dbtDefault and dbxDefault to set Secure Boot
key. Default variables are initialized based on keys embedded in
flash
binary file. Please find details in following document:

https://drive.google.com/file/d/1rC6BjRWKODdXPdAa5cIeBG8_ye2L8aSZ/view?usp=sharing

- A new platform DXE driver (which need not even stay resident), for
locating some FFS files and their sections, and for copying their
contents into PKDefault and friends, seems like a good / useful idea
to me.

- Regarding the following sentence:

However there is no need to keep these variables as non-volatile in
order to avoid unnecessary bloating of the consumed non-volatile
storage space.
This is valid, but redundant (or at least somewhat redundantly
expressed), IMO. The UEFI spec already marks PKDefault as "BS, RT"
(section 3.3).

- The setting of PK from PKDefault (and similarly for the other
variables) is indeed a separate action. The UEFI spec says this is
primarily an OS action (again section 3.3), but I agree having a
dedicated UEFI app for this may be useful.

- Regarding the following sentence:

In case when default variables are already initialized a warning
message will be printed and variables will not be changed.

A warning is possible perhaps via status code reporting, or DEBUG. A
platform DXE driver is not supposed to write to the console.

- The idea as a whole looks good to me. I agree it should be testable
with OVMF, provided the FDF file(s) are modified as needed; however, I
wouldn't like to have that in the FDF file(s) permanently -- or at
least
it should be gated with a new build time feature test macro.

The

SECTION RAW = ...

statements in the FDF files could perhaps refer to macros as well (for
the pathnames). So a user building a platform with this feature
enabled
would have to pass a -D flag (boolean) for enabling the feature in
general (enabling the necessary lines in both the DSC and the FDF
file(s)), and then further -D flags for specifying the pathnames.
You could perhaps introduce DSC and FDF snippets (include files) too,
under SecurityPkg, so that any platform utilizing this feature do so
through identical macro names.

Thanks
Laszlo




RFC: UEFI ECR to clarify NVMe device path EUI-64 byte order

Samer El-Haj-Mahmoud
 

All,

+ MdePkg maintainers

Would like your input on the following UEFI spec ECR:

Clarify NVMe and Infiniband device path EUI-64 byte order
https://bugzilla.tianocore.org/show_bug.cgi?id=3338

(Thanks to Laszlo for reviewing already)

Thanks,
--Samer
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

Samer El-Haj-Mahmoud
 

Any further comments on the ACPI ECR documented in: https://bugzilla.tianocore.org/show_bug.cgi?id=3335 ?

I already have comments from Jeremey and Andrew saying it looks good. If there are no objections, I will let ASWG know to approve the ECR for future ACPI spec publication.

Thanks,
--Samer




From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io
Sent: Tuesday, April 13, 2021 12:45 PM
To: Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Jeremy Linton <Jeremy.Linton@arm.com>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; pete@akeo.ie; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

I just got to this thread. Apologies for the delay.

I went through the ACPI spec. Here is what I see:

https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#qwordmemory-qword-memory-resource-descriptor-macro


"ResourceUsage specifies whether the Memory range is consumed by this device (ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed."



https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access



" It specifies the ranges the bus controller (bridge) decodes on the child-side of its interface. (This is analogous to the _CRS object, which describes the resources that the bus controller decodes on the parent-side of its interface.) Any ranges described in the resources of a _DMA object can be used by child devices for DMA or bus master transactions.."



The way I read the spec, this wording in the _DMA definition "Any ranges described in the resources of a _DMA object can be used by child devices.." suggests that this should be a ResourceProducer, per the QWordMemory resource descriptor definition above


The _DMA example in section 6.2.4 uses a "ResourceConsumer", when it should really be "ResourceProducer" according to these definitions: It describes , the child devices view of the address range, so the "translation" added is the CPU's view of the same range.



I submitted a "code first" ECR to correct the ACPI spec example (here : https://bugzilla.tianocore.org/show_bug.cgi?id=3335). Please provide feedback on the BZ (or this thread) whether you agree or not, so we can take this to ASWG/UEFI Forum for discussion and approval



Thanks,

--Samer





From: Andrei Warkentin <awarkentin@vmware.com<mailto:awarkentin@vmware.com>>
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton <Jeremy.Linton@arm.com<mailto:Jeremy.Linton@arm.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com<mailto:Ard.Biesheuvel@arm.com>>; leif@nuviainc.com<mailto:leif@nuviainc.com>; pete@akeo.ie<mailto:pete@akeo.ie>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com<mailto:Samer.El-Haj-Mahmoud@arm.com>>
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

I don't know... the ACPI spec is weird.

https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access

...lists ResourceConsumer for _DMA.

A

________________________________
From: Jeremy Linton <jeremy.linton@arm.com<mailto:jeremy.linton@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>
Cc: ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com> <ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com>>; leif@nuviainc.com<mailto:leif@nuviainc.com> <leif@nuviainc.com<mailto:leif@nuviainc.com>>; pete@akeo.ie<mailto:pete@akeo.ie> <pete@akeo.ie<mailto:pete@akeo.ie>>; samer.el-haj-mahmoud@arm.com<mailto:samer.el-haj-mahmoud@arm.com> <samer.el-haj-mahmoud@arm.com<mailto:samer.el-haj-mahmoud@arm.com>>; Andrei Warkentin <awarkentin@vmware.com<mailto:awarkentin@vmware.com>>; Jeremy Linton <jeremy.linton@arm.com<mailto:jeremy.linton@arm.com>>
Subject: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com<mailto:jeremy.linton@arm.com>>
---
Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..32cd5fc9f9 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
// Only the first GB is available.

// Bus 0xC0000000 -> CPU 0x00000000.

//

- QWordMemory (ResourceConsumer,

+ QWordMemory (ResourceProducer,

,

MinFixed,

MaxFixed,

diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 179dd3ecdb..0fbc2a79ea 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -32,7 +32,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)
}



Name (_DMA, ResourceTemplate() {

- QWordMemory (ResourceConsumer,

+ QWordMemory (ResourceProducer,

,

MinFixed,

MaxFixed,

--
2.13.7
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: RFC: Boot Discovery Policy

Sunny Wang
 

For Ard, Pete, and Leif's reference, this is the follow-up to my Fast Boot related commit https://github.com/tianocore/edk2-platforms/commit/efdc159ef7c9f15581a0f63d755a1530ff475156. We want to add the setup option to the core code instead of the platform code so that we can easily solve similar problems that are related to Fast boot in other platforms as well. Therefore, I think RPI should be fine with this design.

Best Regards,
Sunny Wang

-----Original Message-----
From: Grzegorz Bernacki <gjb@semihalf.com>
Sent: Thursday, April 29, 2021 9:43 PM
To: rfc@edk2.groups.io; Grzegorz Bernacki <gjb@semihalf.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Sunny Wang <Sunny.Wang@arm.com>; Marcin Wojtas <mw@semihalf.com>; zhichao.gao@intel.co; ray.ni@intel.com; pete@akeo.ie; leif@nuviainc.com; ardb+tianocore@kernel.org
Subject: Re: [edk2-rfc] RFC: Boot Discovery Policy

Adding RPI maintainers...
Ard, Leif, Pete,
Can I ask you for you comments on the design?

thanks,
greg

czw., 29 kwi 2021 o 13:19 Grzegorz Bernacki via groups.io <gjb=semihalf.com@groups.io> napisał(a):

Adding reviewers and ARM into the loop...

Ray, Zhichao,
Can I ask you to review the design and let me know if you got any comments.

thanks
greg


czw., 29 kwi 2021 o 10:11 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):

Hi,

I would like to ask you for review of following proposal. It will
allow the user to specify which devices should be connected at the
boot. User selection will be saved in variable and Boot Manager
Policy Protocol will be used to connect specified devices.
Design can be found at:
https://drive.google.com/file/d/1OiQrXuQT9wfr8hPahzXcPj6mMszGPQUw/vi
ew?usp=sharing

thanks,
greg



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: RFC: Boot Discovery Policy

Grzegorz Bernacki
 

Adding RPI maintainers...
Ard, Leif, Pete,
Can I ask you for you comments on the design?

thanks,
greg

czw., 29 kwi 2021 o 13:19 Grzegorz Bernacki via groups.io
<gjb=semihalf.com@groups.io> napisał(a):


Adding reviewers and ARM into the loop...

Ray, Zhichao,
Can I ask you to review the design and let me know if you got any comments.

thanks
greg


czw., 29 kwi 2021 o 10:11 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):

Hi,

I would like to ask you for review of following proposal. It will
allow the user to specify which devices should be connected at the
boot. User selection will be saved in variable and Boot Manager Policy
Protocol will be used to connect specified devices.
Design can be found at:
https://drive.google.com/file/d/1OiQrXuQT9wfr8hPahzXcPj6mMszGPQUw/view?usp=sharing

thanks,
greg




Re: RFC: Boot Discovery Policy

Grzegorz Bernacki
 

Hi Ray,
Thanks a lot for review. Regarding comment #1. I proposed two options:
1) Change directly MdeModulePkg/Library/BootMaintenanceManagerUiLib
and add an Boot Discovery Policy entry in 'Boot Maintenance Manager'
menu
or
2) Add a new library which uses EFI_IFR_BOOT_MAINTENANCE_GUID
classguid and allow Boot Maintanance Manager to connect it via
BmmListThirdPartyDrivers(). However, drawback of that solution is
creation of a new form with Boot Discovery Policy drop-down list

Second option uses separate library. What is your opinion on above?
thanks,
greg

czw., 29 kwi 2021 o 14:58 Ni, Ray <ray.ni@intel.com> napisał(a):


greg,
I reviewed your design and learned several points:
1. UiApp adds an option to let user select which class to connect
[ray] can you explain which UiApp your design changes? the one in MdeModulePkg? can you investigate whether it's doable to produce such setup option through another driver?

2. bcfg adds an option to let user select which class to connect
[ray] you need to discuss with USWG on the bcfg shell command change.

3. The option added above controls the PlatformBootManagerLib behavior
[ray] This lib belongs to platform scope so you can freely change it as long as the platform owner agrees.

Thanks,
ray

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Grzegorz Bernacki
Sent: Thursday, April 29, 2021 7:19 PM
To: rfc@edk2.groups.io
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Sunny Wang <Sunny.Wang@arm.com>; Marcin Wojtas
<mw@semihalf.com>; zhichao.gao@intel.co; Ni, Ray <ray.ni@intel.com>
Subject: Re: [edk2-rfc] RFC: Boot Discovery Policy

Adding reviewers and ARM into the loop...

Ray, Zhichao,
Can I ask you to review the design and let me know if you got any comments.

thanks
greg


czw., 29 kwi 2021 o 10:11 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):

Hi,

I would like to ask you for review of following proposal. It will
allow the user to specify which devices should be connected at the
boot. User selection will be saved in variable and Boot Manager Policy
Protocol will be used to connect specified devices.
Design can be found at:
https://drive.google.com/file/d/1OiQrXuQT9wfr8hPahzXcPj6mMszGPQUw/view?usp=sharing

thanks,
greg







Re: RFC: Boot Discovery Policy

Ni, Ray
 

greg,
I reviewed your design and learned several points:
1. UiApp adds an option to let user select which class to connect
[ray] can you explain which UiApp your design changes? the one in MdeModulePkg? can you investigate whether it's doable to produce such setup option through another driver?

2. bcfg adds an option to let user select which class to connect
[ray] you need to discuss with USWG on the bcfg shell command change.

3. The option added above controls the PlatformBootManagerLib behavior
[ray] This lib belongs to platform scope so you can freely change it as long as the platform owner agrees.

Thanks,
ray

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Grzegorz Bernacki
Sent: Thursday, April 29, 2021 7:19 PM
To: rfc@edk2.groups.io
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Sunny Wang <Sunny.Wang@arm.com>; Marcin Wojtas
<mw@semihalf.com>; zhichao.gao@intel.co; Ni, Ray <ray.ni@intel.com>
Subject: Re: [edk2-rfc] RFC: Boot Discovery Policy

Adding reviewers and ARM into the loop...

Ray, Zhichao,
Can I ask you to review the design and let me know if you got any comments.

thanks
greg


czw., 29 kwi 2021 o 10:11 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):

Hi,

I would like to ask you for review of following proposal. It will
allow the user to specify which devices should be connected at the
boot. User selection will be saved in variable and Boot Manager Policy
Protocol will be used to connect specified devices.
Design can be found at:
https://drive.google.com/file/d/1OiQrXuQT9wfr8hPahzXcPj6mMszGPQUw/view?usp=sharing

thanks,
greg



Re: RFC: Boot Discovery Policy

Grzegorz Bernacki
 

Adding reviewers and ARM into the loop...

Ray, Zhichao,
Can I ask you to review the design and let me know if you got any comments.

thanks
greg


czw., 29 kwi 2021 o 10:11 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):


Hi,

I would like to ask you for review of following proposal. It will
allow the user to specify which devices should be connected at the
boot. User selection will be saved in variable and Boot Manager Policy
Protocol will be used to connect specified devices.
Design can be found at:
https://drive.google.com/file/d/1OiQrXuQT9wfr8hPahzXcPj6mMszGPQUw/view?usp=sharing

thanks,
greg


RFC: Boot Discovery Policy

Grzegorz Bernacki
 

Hi,

I would like to ask you for review of following proposal. It will
allow the user to specify which devices should be connected at the
boot. User selection will be saved in variable and Boot Manager Policy
Protocol will be used to connect specified devices.
Design can be found at:
https://drive.google.com/file/d/1OiQrXuQT9wfr8hPahzXcPj6mMszGPQUw/view?usp=sharing

thanks,
greg


Re: [edk2-devel] [RFC] Secure boot default key

Grzegorz Bernacki
 

Hi Laszlo,

Please find diff at following link:
https://drive.google.com/file/d/1ZEzNUjaz9PiQPnQlIfsHYiJ6ZCda_szD/view?usp=sharing

thanks,
greg

śr., 28 kwi 2021 o 18:55 Laszlo Ersek <lersek@redhat.com> napisał(a):

Hi Greg,

On 04/28/21 12:50, Grzegorz Bernacki wrote:
Hi,

Thanks a lot for reviewing my previous document. Please see below link to
updated design:
https://drive.google.com/file/d/11yNJJ2x8WXYZRg1nZWrr4C4Hq89Izn1D/view?usp=sharing

Changes:
- remove unnecessary description of default variables
- add macros to specify default keys files
- add fdf include file
- add UI to reset the content of the keys to default values
the master format for this document seems to be LaTeX (from the "pdf
properties" window in evince), which is fantastic: can you please post a
diff between the v1 and v2 LaTeX sources?

I can only deal with incremental reviews for v2 and later postings. Most
WYSIWYG document editors nowadays support one form of change tracking or
another. Working with a plaintext source format such as LaTeX is always
best, of course. My only request is then, "diffs please".

The rendered format is absolutely welcome in addition to the diffs, of
course.

Thanks
Laszlo



Please let me know if you have any questions/comments/concerns.
thanks,
greg

pon., 19 kwi 2021 o 11:07 Grzegorz Bernacki <gjb@semihalf.com>
napisał(a):

Hi Laszlo,

Thanks a lot for your review. I will wait some time for more comments
and I will send an updated design.
thanks,
greg

pt., 16 kwi 2021 o 14:16 Laszlo Ersek <lersek@redhat.com> napisał(a):

On 04/16/21 14:10, Laszlo Ersek wrote:
On 04/15/21 13:59, Grzegorz Bernacki wrote:
Hello,

I would like to ask you to review the proposal for new application
for
enrolling Secure Boot keys. The application uses content of
PKDefault,
KEKDefault, dbDefault, dbtDefault and dbxDefault to set Secure Boot
key. Default variables are initialized based on keys embedded in
flash
binary file. Please find details in following document:

https://drive.google.com/file/d/1rC6BjRWKODdXPdAa5cIeBG8_ye2L8aSZ/view?usp=sharing

- A new platform DXE driver (which need not even stay resident), for
locating some FFS files and their sections, and for copying their
contents into PKDefault and friends, seems like a good / useful idea
to me.

- Regarding the following sentence:

However there is no need to keep these variables as non-volatile in
order to avoid unnecessary bloating of the consumed non-volatile
storage space.
This is valid, but redundant (or at least somewhat redundantly
expressed), IMO. The UEFI spec already marks PKDefault as "BS, RT"
(section 3.3).

- The setting of PK from PKDefault (and similarly for the other
variables) is indeed a separate action. The UEFI spec says this is
primarily an OS action (again section 3.3), but I agree having a
dedicated UEFI app for this may be useful.

- Regarding the following sentence:

In case when default variables are already initialized a warning
message will be printed and variables will not be changed.

A warning is possible perhaps via status code reporting, or DEBUG. A
platform DXE driver is not supposed to write to the console.

- The idea as a whole looks good to me. I agree it should be testable
with OVMF, provided the FDF file(s) are modified as needed; however, I
wouldn't like to have that in the FDF file(s) permanently -- or at
least
it should be gated with a new build time feature test macro.

The

SECTION RAW = ...

statements in the FDF files could perhaps refer to macros as well (for
the pathnames). So a user building a platform with this feature
enabled
would have to pass a -D flag (boolean) for enabling the feature in
general (enabling the necessary lines in both the DSC and the FDF
file(s)), and then further -D flags for specifying the pathnames.
You could perhaps introduce DSC and FDF snippets (include files) too,
under SecurityPkg, so that any platform utilizing this feature do so
through identical macro names.

Thanks
Laszlo




Re: [edk2-devel] [RFC] Secure boot default key

Laszlo Ersek
 

Hi Greg,

On 04/28/21 12:50, Grzegorz Bernacki wrote:
Hi,

Thanks a lot for reviewing my previous document. Please see below link to
updated design:
https://drive.google.com/file/d/11yNJJ2x8WXYZRg1nZWrr4C4Hq89Izn1D/view?usp=sharing

Changes:
- remove unnecessary description of default variables
- add macros to specify default keys files
- add fdf include file
- add UI to reset the content of the keys to default values
the master format for this document seems to be LaTeX (from the "pdf
properties" window in evince), which is fantastic: can you please post a
diff between the v1 and v2 LaTeX sources?

I can only deal with incremental reviews for v2 and later postings. Most
WYSIWYG document editors nowadays support one form of change tracking or
another. Working with a plaintext source format such as LaTeX is always
best, of course. My only request is then, "diffs please".

The rendered format is absolutely welcome in addition to the diffs, of
course.

Thanks
Laszlo



Please let me know if you have any questions/comments/concerns.
thanks,
greg

pon., 19 kwi 2021 o 11:07 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):

Hi Laszlo,

Thanks a lot for your review. I will wait some time for more comments
and I will send an updated design.
thanks,
greg

pt., 16 kwi 2021 o 14:16 Laszlo Ersek <lersek@redhat.com> napisał(a):

On 04/16/21 14:10, Laszlo Ersek wrote:
On 04/15/21 13:59, Grzegorz Bernacki wrote:
Hello,

I would like to ask you to review the proposal for new application for
enrolling Secure Boot keys. The application uses content of PKDefault,
KEKDefault, dbDefault, dbtDefault and dbxDefault to set Secure Boot
key. Default variables are initialized based on keys embedded in flash
binary file. Please find details in following document:

https://drive.google.com/file/d/1rC6BjRWKODdXPdAa5cIeBG8_ye2L8aSZ/view?usp=sharing

- A new platform DXE driver (which need not even stay resident), for
locating some FFS files and their sections, and for copying their
contents into PKDefault and friends, seems like a good / useful idea
to me.

- Regarding the following sentence:

However there is no need to keep these variables as non-volatile in
order to avoid unnecessary bloating of the consumed non-volatile
storage space.
This is valid, but redundant (or at least somewhat redundantly
expressed), IMO. The UEFI spec already marks PKDefault as "BS, RT"
(section 3.3).

- The setting of PK from PKDefault (and similarly for the other
variables) is indeed a separate action. The UEFI spec says this is
primarily an OS action (again section 3.3), but I agree having a
dedicated UEFI app for this may be useful.

- Regarding the following sentence:

In case when default variables are already initialized a warning
message will be printed and variables will not be changed.

A warning is possible perhaps via status code reporting, or DEBUG. A
platform DXE driver is not supposed to write to the console.

- The idea as a whole looks good to me. I agree it should be testable
with OVMF, provided the FDF file(s) are modified as needed; however, I
wouldn't like to have that in the FDF file(s) permanently -- or at
least
it should be gated with a new build time feature test macro.

The

SECTION RAW = ...

statements in the FDF files could perhaps refer to macros as well (for
the pathnames). So a user building a platform with this feature enabled
would have to pass a -D flag (boolean) for enabling the feature in
general (enabling the necessary lines in both the DSC and the FDF
file(s)), and then further -D flags for specifying the pathnames.
You could perhaps introduce DSC and FDF snippets (include files) too,
under SecurityPkg, so that any platform utilizing this feature do so
through identical macro names.

Thanks
Laszlo




Re: [edk2-devel] [RFC] Secure boot default key

Grzegorz Bernacki
 

Hi,

Thanks a lot for reviewing my previous document. Please see below link to
updated design:
https://drive.google.com/file/d/11yNJJ2x8WXYZRg1nZWrr4C4Hq89Izn1D/view?usp=sharing

Changes:
- remove unnecessary description of default variables
- add macros to specify default keys files
- add fdf include file
- add UI to reset the content of the keys to default values

Please let me know if you have any questions/comments/concerns.
thanks,
greg

pon., 19 kwi 2021 o 11:07 Grzegorz Bernacki <gjb@semihalf.com> napisał(a):

Hi Laszlo,

Thanks a lot for your review. I will wait some time for more comments
and I will send an updated design.
thanks,
greg

pt., 16 kwi 2021 o 14:16 Laszlo Ersek <lersek@redhat.com> napisał(a):

On 04/16/21 14:10, Laszlo Ersek wrote:
On 04/15/21 13:59, Grzegorz Bernacki wrote:
Hello,

I would like to ask you to review the proposal for new application for
enrolling Secure Boot keys. The application uses content of PKDefault,
KEKDefault, dbDefault, dbtDefault and dbxDefault to set Secure Boot
key. Default variables are initialized based on keys embedded in flash
binary file. Please find details in following document:

https://drive.google.com/file/d/1rC6BjRWKODdXPdAa5cIeBG8_ye2L8aSZ/view?usp=sharing

- A new platform DXE driver (which need not even stay resident), for
locating some FFS files and their sections, and for copying their
contents into PKDefault and friends, seems like a good / useful idea
to me.

- Regarding the following sentence:

However there is no need to keep these variables as non-volatile in
order to avoid unnecessary bloating of the consumed non-volatile
storage space.
This is valid, but redundant (or at least somewhat redundantly
expressed), IMO. The UEFI spec already marks PKDefault as "BS, RT"
(section 3.3).

- The setting of PK from PKDefault (and similarly for the other
variables) is indeed a separate action. The UEFI spec says this is
primarily an OS action (again section 3.3), but I agree having a
dedicated UEFI app for this may be useful.

- Regarding the following sentence:

In case when default variables are already initialized a warning
message will be printed and variables will not be changed.

A warning is possible perhaps via status code reporting, or DEBUG. A
platform DXE driver is not supposed to write to the console.

- The idea as a whole looks good to me. I agree it should be testable
with OVMF, provided the FDF file(s) are modified as needed; however, I
wouldn't like to have that in the FDF file(s) permanently -- or at
least
it should be gated with a new build time feature test macro.

The

SECTION RAW = ...

statements in the FDF files could perhaps refer to macros as well (for
the pathnames). So a user building a platform with this feature enabled
would have to pass a -D flag (boolean) for enabling the feature in
general (enabling the necessary lines in both the DSC and the FDF
file(s)), and then further -D flags for specifying the pathnames.
You could perhaps introduce DSC and FDF snippets (include files) too,
under SecurityPkg, so that any platform utilizing this feature do so
through identical macro names.

Thanks
Laszlo


Re: [RFC] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle Wang
 

Hi Dandan,

Thank you for your feedback. Yes I think we need an interface between HII modules and Browser in UEFI specification.

I think we may mention the optional hot key service for browser implementation in UEFI spec and describe the purpose and use case clearly in Spec
Sounds a good idea. Thanks.

Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Dandan Bi
Sent: Wednesday, April 28, 2021 10:29 AM
To: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; gaoliming <gaoliming@byosoft.com.cn>; rfc@edk2.groups.io; lersek@redhat.com
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] [RFC] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hi Nickle,

I also think Liming's suggest is good that add EFI_BROWSER_ACTION_REQUEST_XXX in UEFI spec to enable the communication between HII modules and Browser for the hot key status.
And each Browser can enable/disable hot key as its own way if it has the capability.
I think we may mention the optional hot key service for browser implementation in UEFI spec and describe the purpose and use case clearly in Spec if we add the new EFI_BROWSER_ACTION_REQUEST_XXX In UEFI spec for hot key related.



Thanks,
Dandan
-----Original Message-----
From: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
Sent: Tuesday, April 27, 2021 11:59 AM
To: gaoliming <gaoliming@byosoft.com.cn>; rfc@edk2.groups.io;
lersek@redhat.com; Bi, Dandan <dandan.bi@intel.com>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Wang,
Nickle (HPS SW) <nickle.wang@hpe.com>
Subject: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hi Liming,

Thank you very much for your feedback. I agree with your idea and it
would be good to address this issue from UEFI interface instead of EDK2 interface.
However, since there is nothing about HII hotkey in UEFI specification now.
This will bring HII hotkey as standard HII interface in UEFI
specification. I am expecting more efforts than doing this in EDK2 interface.

Hi Dandan,

May I have your comments about this? We had talked about this before
and we think HII hotkey is only EDK2 browser implementation. If we
want to have HII hotkey defined in UEFI specification, do you see any objection to this?

For now, I suggest OptionRom driver adds some information in its
help
message to display them in Setup page. It can notify the user that it
doesn't support HotKey. For long term, I propose to introduce new
EFI_BROWSER_ACTION type in UEFI spec for the communication between
Browser and HII module. When HII module page open, it can return its
status of system hot key to Browser, then browser can control whether
enable hotkey.

This is good suggestion, Thanks! And the idea of new
EFI_BROWSER_ACTION looks good to me too. I will check and see how to do this.

Thanks,
Nickle

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Tuesday, April 27, 2021 11:32 AM
To: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; rfc@edk2.groups.io;
lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle:
Sorry for the late response. In fact, there is no UEFI interface
between system browser and single HII module.
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL is edk2 implementation.
This is not UEFI interface. OptionRom card needs to follow UEFI, and
work on UEFI system. So, I don't suggest that HII module consumes
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL. For now, I suggest OptionRom
driver adds some information in its help message to display them in
Setup page. It can notify the user that it doesn't support HotKey. For
long term, I propose to introduce new EFI_BROWSER_ACTION type in UEFI
spec for the communication between Browser and HII module. When HII
module page open, it can return its status of system hot key to
Browser, then browser can control whether enable hotkey.

Thanks
Liming
-----邮件原件-----
发件人: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
发送时间: 2021年4月26日 11:15
收件人: rfc@edk2.groups.io; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>;
gaoliming@byosoft.com.cn; lersek@redhat.com
抄送: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Hello Liming,

Just a friendly reminder in case you miss this email. It seems to me
that if we do not create the interface to disable HII hotkey, we
still need some improvement to HII in order to address the issues
that I mentioned. What do you think about this?

Thanks,
Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Nickle
Wang
Sent: Friday, April 16, 2021 4:13 PM
To: rfc@edk2.groups.io; gaoliming@byosoft.com.cn; lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Hi Liming,



Thanks for your comments. I got a chance to talk to option card
vendor and they share two cases that HII driver is not able to support hotkey.



1) Driver cannot support hotkey to load defaults.



Form EDK2 display engine driver
(MdeModulePkg\Universal\DisplayEngineDxe), it binds load default
hotkey to standard default.



[cid:image001.png@01D732D8.521D5DE0]



However, there is no interface for option card driver to see what
default type that hotkey support. When option card driver supports
OEM defaults or the defaults other than display engine sets, nothing
will happen. And different IBV may support different default setting
with hotkey. So option card driver has to implement their own HII
button to
address this interoperability Issue.



2) Driver needs user to submit data before user leaves certain HII menu.
Hotkey does not work in this way.



This is the example from EDK2 iSCSI driver again. Below are the
steps to add iSCSI Attempt:



[cid:image003.png@01D732D9.C4F71C60]



Due to the design of iSCSI HII driver, user has to submit data at
step
3 before user goes back to step 2 and select another network
interface. If user does not submit data at step 3, all user’s input
may be lost after user selects another network interface. However,
we have no way to force user to press
F10 hotkey here. By EDK2 design, hotkey works in form-set scope.
User can press hotkey at anywhere when user finish the
configuration. As the result, option card driver has to disable
hotkey and force user to use HII button to submit data.



So, what do you think about above two cases?



Thanks,

Nickle



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, March 30, 2021 9:16 AM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>;
lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support



Nickle:



-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Nickle Wang

发送时间: 2021年3月26日 12:05
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
lersek@redhat.com<mailto:lersek@redhat.com>

抄送: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Thanks for your feedback, Liming. Please see my comment below.
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of
gaoliming

Sent: Friday, March 26, 2021 9:51 AM
To: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

lersek@redhat.com<mailto:lersek@redhat.com>
Cc: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
Nickle:
-----邮件原件-----
发件人: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>

发送时间: 2021年3月25日 15:41
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;

lersek@redhat.com<mailto:lersek@redhat.com>
抄送: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of

gaoliming
Sent: Thursday, March 25, 2021 11:40 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
lersek@redhat.com<mailto:lersek@redhat.com>; Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
Cc: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Laszlo

Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>

抄送: Dandan Bi
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable
hotkey

support
On 03/24/21 09:21, Nickle Wang wrote:
Hi All,
I am having trouble to disable hotkey support in HII
browser
with existing
interface. I am wondering if we could have new interface
to
disable hotkey support in form browser extension2 protocol.
1. Background:
In some HII driver, there is no need to have hotkey
support
in certain HII
menu due to its design. The examples are EDK2 iSCSI
driver,
secure boot configuration and Tls auth configuration driver.
In these HII menus, there is HII button to do submit or
discard job and they do not answer to hotkey action. I
also
see this design in 3rd party option card driver. In this
case,
user feels confused because it dose not do anything while
pressing hotkey. The only way to save or discard data is
by
pressing the button on HII menu. So, we need to disable
hotkey
support and force user to use HII button.
I agree with the problem statement. I've noticed this too,
and
found it confusing.
I wonder if there are HII guidelines or best known
practices
to deal with it -- I assume that one desirable solution
might
be if we could control the hotkeys just from the VFR, one
way
or another. But indeed I don't know if that's feasible by design.
UEFI driver write guide 12.6.1 Minimize callbacks section
defines the guide line.
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-D
ri
ve
r-
Writer%27s-Guide
But, some HII drivers still like to control
submit/discard/exit
in its form by Callback function.
Hotkey way is to consume HII driver ConfigAccess protocol
RouteConfig() function for data saving.
So, HotKey doesn't work on those drivers.
For this proposal, I want to understand when new interface
will
be trigged and what module calls this new API.
The module to call this new API is the HII driver which has no
hotkey support in its HII menu. The HII driver could also be
option card
driver.

As for when the new interface will be triggered, there are two
cases in my
mind:
1. Driver wants to disable hotkey support for entire HII form-set.
1.1 Driver will call new interface in ExtractConfig()
function
with Scope "FormSetLevel".
1.2 Driver calls new interface in Callback() function when
Action is set to EFI_BROWSER_ACTION_FORM_OPEN. With Scope "
FormLevel",
this
will disable hotkey for every HII menu.
2. Driver only disable hotkey support for certain HII menu.
2. Same as 1.2 but driver have condition check to see if
this is
target HII menu or not. The Scope is set to " FormLevel" and
the
hotkey support is restored automatically by display engine
when
user
leaves this HII menu.
So, your proposal is to let HII driver call new API to disable
or
enable Hotkey on its page.
There are still some issues here.
1. UEFI option rom driver is the independent driver. It refers
to
the standard UEFI interface.
But, form browser extension2 protocol is edk2 extension. Other
UEFI
implementation may not provide this protocol.
It would be good if we could have HII hotkey definition in UEFI
specification.

But it looks like the HII hotkey support is just EDK2 form browser
implementation specific. So I would like to address the issue from
EDK2 protocol.
As far as I know, option card vendor has chance to support edk2
protocol because edk2 is kind like the industrial UEFI implementation.
And it is also easy to know if this system supports form browser
extension2
protocol or not.

Option card driver could code its behaviour accordingly


Browser implementation may be different. Please see the message
INVALID URI REMOVED
11__;!!NpxR!wupnCRk9oRVDzLRnKKZ37ZViIaEVk29Pp5op9BRoPlUqTws1e2Zf
FHMl8x
V5F-0$



2. Browser may have the different Hotkey. UEFI driver doesn't
know
to disable which Hotkey.
Yes, I also noticed this. So the new interface accept "Action" of
hotkey as parameter. So that UEFI driver does not need to know
which
hotkey he has to disable. For example, browser may define F9 for
BROWSER_ACTION_SUBMIT and F10 to do BROWSER_ACTION_DEFAULT.
Then, no

matter what hotkey that browser defines for submit and default
job,
UEFI driver can disable them by below calls:
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_SUBMIT, FormLevel);
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_DEFAULT, FormLevel);
Then browser will disable the hotkey that is binding to above actions.
UEFI driver does not need to know the specific hotkey to disable.
Instead, UEFI driver disable the action that he does not want to
support
through hotkey.

When UEFI driver provides their own HII button for these actions,
he
would understand what action that they do not want hotkey support.


So, you mean in form open callback to disable hotkey in form level.
Once exit this form, Browser will restore original hotkey. Right?



In fact, UEFI spec defines HII ConfigAccess protocol for data
read and
write.

HII driver should follow this way.
I am not the owner of EDK2 iSCSI driver but I expect that there
might
be some trouble to support hotkey to save iSCSI attempt setting.
My
guess is: iSCSI attempt menu is not one-to-one mapping between
iSCSI
attempt setting and HII option. iSCSI attempt menu is shared
between
multiple network interfaces.

In this design, there might be difficulty to do this through HII
hotkey. And this also applies to secure boot key enrolment case
and
TLS certificate enrolment case in EDK2 drivers.


HII driver doesn't require the display data and save data are 1:1 mapping.

HII driver can convert the display data to the saved data. For
example, the display information is the string, but the saved data
is the
value.



If HII driver doesn't use this way, it can't be handled by Browser.
I think this
is
the expected behavior.
We don't need to introduce new API for it.
Yes it is expected behavior. But from my point of view, as I
mentioned
above, there might be some trouble to support it so HII driver
does
not follow this way. I can see cases in EDK2 driver.
I agree some Edk2 module may not be a good example.



Thanks

Liming



Thanks,
Nickle
Thanks,
Nickle
Thanks
Liming
Thanks
Laszlo
2. Issue:
Currently we have
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.RegisterHotKey
to

create or
delete hotkey support. With value 0 in "Action", we can
delete
corresponding hotkey.
typedef
EFI_STATUS
(EFIAPI *REGISTER_HOT_KEY) (
IN EFI_INPUT_KEY *KeyData,
IN UINT32 Action,
IN UINT16 DefaultId,
IN EFI_STRING HelpString OPTIONAL
);
However, there are some troubles for driver or option
card
driver to use it
and delete hotkey support.
* Usually, display engine is the one who creates hotkey in HII
browser.
So driver has no information about the key data. And there
is
no way to get these hotkey information programmatically.
* If driver tries to delete hotkey for its HII menu, it requires
driver
to
restore hokey support when user leaves its HII menu. This
could easily break the hotkey support in HII browser
because
display engine has no control to this.
3. Proposal:
I would like to propose new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL so that driver
can

temporarily
disable hotkey support for certain HII menu in its own form-set.
And display engine will handle the hotkey support accordingly.
struct EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL {
...
REGISTER_HOT_KEY RegisterHotKey;
DISABLE_HOT_KEY DisableHotKey;
...
};
/**
Disable the hotkey by given its browser action.
@param[in] Action Action value to disable corresponding
hotkey.
@param[in] Scope Hotkey scope level to be disabled.
@retval EFI_SUCCESS Hotkey is disabled.
@retval EFI_NOT_FOUND Hotkey with given Action is not
found.
**/
typedef
EFI_STATUS
(EFIAPI *DISABLE_HOT_KEY) (
IN UINT32 Action,
IN BROWSER_SETTING_SCOPE Scope );
May I have your comment about this? Is this good idea
for
driver to disable
hotkey support?
Thanks,
Nickle




















Re: [RFC] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Dandan Bi <dandan.bi@...>
 

Hi Nickle,

I also think Liming's suggest is good that add EFI_BROWSER_ACTION_REQUEST_XXX in UEFI spec to enable the communication between HII modules and Browser for the hot key status.
And each Browser can enable/disable hot key as its own way if it has the capability.
I think we may mention the optional hot key service for browser implementation in UEFI spec and describe the purpose and use case clearly in Spec if we add the new EFI_BROWSER_ACTION_REQUEST_XXX In UEFI spec for hot key related.



Thanks,
Dandan

-----Original Message-----
From: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
Sent: Tuesday, April 27, 2021 11:59 AM
To: gaoliming <gaoliming@byosoft.com.cn>; rfc@edk2.groups.io;
lersek@redhat.com; Bi, Dandan <dandan.bi@intel.com>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>;
Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
Subject: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hi Liming,

Thank you very much for your feedback. I agree with your idea and it would
be good to address this issue from UEFI interface instead of EDK2 interface.
However, since there is nothing about HII hotkey in UEFI specification now.
This will bring HII hotkey as standard HII interface in UEFI specification. I am
expecting more efforts than doing this in EDK2 interface.

Hi Dandan,

May I have your comments about this? We had talked about this before and
we think HII hotkey is only EDK2 browser implementation. If we want to have
HII hotkey defined in UEFI specification, do you see any objection to this?

For now, I suggest OptionRom driver adds some information in its help
message to display them in Setup page. It can notify the user that it doesn't
support HotKey. For long term, I propose to introduce new
EFI_BROWSER_ACTION type in UEFI spec for the communication between
Browser and HII module. When HII module page open, it can return its status
of system hot key to Browser, then browser can control whether enable
hotkey.

This is good suggestion, Thanks! And the idea of new EFI_BROWSER_ACTION
looks good to me too. I will check and see how to do this.

Thanks,
Nickle

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Tuesday, April 27, 2021 11:32 AM
To: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; rfc@edk2.groups.io;
lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle:
Sorry for the late response. In fact, there is no UEFI interface between
system browser and single HII module.
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL is edk2 implementation.
This is not UEFI interface. OptionRom card needs to follow UEFI, and work on
UEFI system. So, I don't suggest that HII module consumes
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL. For now, I suggest
OptionRom driver adds some information in its help message to display them
in Setup page. It can notify the user that it doesn't support HotKey. For long
term, I propose to introduce new EFI_BROWSER_ACTION type in UEFI spec
for the communication between Browser and HII module. When HII module
page open, it can return its status of system hot key to Browser, then
browser can control whether enable hotkey.

Thanks
Liming
-----邮件原件-----
发件人: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
发送时间: 2021年4月26日 11:15
收件人: rfc@edk2.groups.io; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>;
gaoliming@byosoft.com.cn; lersek@redhat.com
抄送: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Hello Liming,

Just a friendly reminder in case you miss this email. It seems to me
that if we do not create the interface to disable HII hotkey, we still
need some improvement to HII in order to address the issues that I
mentioned. What do you think about this?

Thanks,
Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Nickle Wang
Sent: Friday, April 16, 2021 4:13 PM
To: rfc@edk2.groups.io; gaoliming@byosoft.com.cn; lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Hi Liming,



Thanks for your comments. I got a chance to talk to option card vendor
and they share two cases that HII driver is not able to support hotkey.



1) Driver cannot support hotkey to load defaults.



Form EDK2 display engine driver
(MdeModulePkg\Universal\DisplayEngineDxe), it binds load default
hotkey to standard default.



[cid:image001.png@01D732D8.521D5DE0]



However, there is no interface for option card driver to see what
default type that hotkey support. When option card driver supports OEM
defaults or the defaults other than display engine sets, nothing will
happen. And different IBV may support different default setting with
hotkey. So option card driver has to implement their own HII button to
address this interoperability Issue.



2) Driver needs user to submit data before user leaves certain HII menu.
Hotkey does not work in this way.



This is the example from EDK2 iSCSI driver again. Below are the steps
to add iSCSI Attempt:



[cid:image003.png@01D732D9.C4F71C60]



Due to the design of iSCSI HII driver, user has to submit data at step
3 before user goes back to step 2 and select another network
interface. If user does not submit data at step 3, all user’s input
may be lost after user selects another network interface. However, we
have no way to force user to press
F10 hotkey here. By EDK2 design, hotkey works in form-set scope. User
can press hotkey at anywhere when user finish the configuration. As
the result, option card driver has to disable hotkey and force user to
use HII button to submit data.



So, what do you think about above two cases?



Thanks,

Nickle



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, March 30, 2021 9:16 AM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>;
lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support



Nickle:



-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Nickle Wang

发送时间: 2021年3月26日 12:05
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
lersek@redhat.com<mailto:lersek@redhat.com>

抄送: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Thanks for your feedback, Liming. Please see my comment below.
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of gaoliming

Sent: Friday, March 26, 2021 9:51 AM
To: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

lersek@redhat.com<mailto:lersek@redhat.com>
Cc: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
Nickle:
-----邮件原件-----
发件人: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>

发送时间: 2021年3月25日 15:41
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;

lersek@redhat.com<mailto:lersek@redhat.com>
抄送: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of

gaoliming
Sent: Thursday, March 25, 2021 11:40 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
lersek@redhat.com<mailto:lersek@redhat.com>; Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
Cc: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Laszlo

Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>

抄送: Dandan Bi
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable
hotkey

support
On 03/24/21 09:21, Nickle Wang wrote:
Hi All,
I am having trouble to disable hotkey support in HII
browser
with existing
interface. I am wondering if we could have new interface to
disable hotkey support in form browser extension2 protocol.
1. Background:
In some HII driver, there is no need to have hotkey
support
in certain HII
menu due to its design. The examples are EDK2 iSCSI driver,
secure boot configuration and Tls auth configuration driver.
In these HII menus, there is HII button to do submit or
discard job and they do not answer to hotkey action. I also
see this design in 3rd party option card driver. In this
case,
user feels confused because it dose not do anything while
pressing hotkey. The only way to save or discard data is by
pressing the button on HII menu. So, we need to disable
hotkey
support and force user to use HII button.
I agree with the problem statement. I've noticed this too,
and
found it confusing.
I wonder if there are HII guidelines or best known practices
to deal with it -- I assume that one desirable solution
might
be if we could control the hotkeys just from the VFR, one
way
or another. But indeed I don't know if that's feasible by design.
UEFI driver write guide 12.6.1 Minimize callbacks section
defines the guide line.
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Dri
ve
r-
Writer%27s-Guide
But, some HII drivers still like to control
submit/discard/exit
in its form by Callback function.
Hotkey way is to consume HII driver ConfigAccess protocol
RouteConfig() function for data saving.
So, HotKey doesn't work on those drivers.
For this proposal, I want to understand when new interface
will
be trigged and what module calls this new API.
The module to call this new API is the HII driver which has no
hotkey support in its HII menu. The HII driver could also be
option card
driver.

As for when the new interface will be triggered, there are two
cases in my
mind:
1. Driver wants to disable hotkey support for entire HII form-set.
1.1 Driver will call new interface in ExtractConfig() function
with Scope "FormSetLevel".
1.2 Driver calls new interface in Callback() function when
Action is set to EFI_BROWSER_ACTION_FORM_OPEN. With Scope "
FormLevel",
this
will disable hotkey for every HII menu.
2. Driver only disable hotkey support for certain HII menu.
2. Same as 1.2 but driver have condition check to see if this
is
target HII menu or not. The Scope is set to " FormLevel" and the
hotkey support is restored automatically by display engine when
user
leaves this HII menu.
So, your proposal is to let HII driver call new API to disable or
enable Hotkey on its page.
There are still some issues here.
1. UEFI option rom driver is the independent driver. It refers to
the standard UEFI interface.
But, form browser extension2 protocol is edk2 extension. Other
UEFI
implementation may not provide this protocol.
It would be good if we could have HII hotkey definition in UEFI
specification.

But it looks like the HII hotkey support is just EDK2 form browser
implementation specific. So I would like to address the issue from
EDK2 protocol.
As far as I know, option card vendor has chance to support edk2
protocol because edk2 is kind like the industrial UEFI implementation.
And it is also easy to know if this system supports form browser
extension2
protocol or not.

Option card driver could code its behaviour accordingly


Browser implementation may be different. Please see the message
https://urldefense.com/v3/__https://edk2.groups.io/g/devel/message/735
11__;!!NpxR!wupnCRk9oRVDzLRnKKZ37ZViIaEVk29Pp5op9BRoPlUqTws1e2Zf
FHMl8x
V5F-0$



2. Browser may have the different Hotkey. UEFI driver doesn't know
to disable which Hotkey.
Yes, I also noticed this. So the new interface accept "Action" of
hotkey as parameter. So that UEFI driver does not need to know which
hotkey he has to disable. For example, browser may define F9 for
BROWSER_ACTION_SUBMIT and F10 to do BROWSER_ACTION_DEFAULT.
Then, no

matter what hotkey that browser defines for submit and default job,
UEFI driver can disable them by below calls:
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_SUBMIT, FormLevel);
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_DEFAULT, FormLevel);
Then browser will disable the hotkey that is binding to above actions.
UEFI driver does not need to know the specific hotkey to disable.
Instead, UEFI driver disable the action that he does not want to
support
through hotkey.

When UEFI driver provides their own HII button for these actions, he
would understand what action that they do not want hotkey support.


So, you mean in form open callback to disable hotkey in form level.
Once exit this form, Browser will restore original hotkey. Right?



In fact, UEFI spec defines HII ConfigAccess protocol for data read
and
write.

HII driver should follow this way.
I am not the owner of EDK2 iSCSI driver but I expect that there
might
be some trouble to support hotkey to save iSCSI attempt setting. My
guess is: iSCSI attempt menu is not one-to-one mapping between iSCSI
attempt setting and HII option. iSCSI attempt menu is shared between
multiple network interfaces.

In this design, there might be difficulty to do this through HII
hotkey. And this also applies to secure boot key enrolment case and
TLS certificate enrolment case in EDK2 drivers.


HII driver doesn't require the display data and save data are 1:1 mapping.

HII driver can convert the display data to the saved data. For
example, the display information is the string, but the saved data is the
value.



If HII driver doesn't use this way, it can't be handled by Browser.
I think this
is
the expected behavior.
We don't need to introduce new API for it.
Yes it is expected behavior. But from my point of view, as I
mentioned
above, there might be some trouble to support it so HII driver does
not follow this way. I can see cases in EDK2 driver.
I agree some Edk2 module may not be a good example.



Thanks

Liming



Thanks,
Nickle
Thanks,
Nickle
Thanks
Liming
Thanks
Laszlo
2. Issue:
Currently we have
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.RegisterHotKey
to

create or
delete hotkey support. With value 0 in "Action", we can
delete
corresponding hotkey.
typedef
EFI_STATUS
(EFIAPI *REGISTER_HOT_KEY) (
IN EFI_INPUT_KEY *KeyData,
IN UINT32 Action,
IN UINT16 DefaultId,
IN EFI_STRING HelpString OPTIONAL
);
However, there are some troubles for driver or option card
driver to use it
and delete hotkey support.
* Usually, display engine is the one who creates hotkey in HII
browser.
So driver has no information about the key data. And there
is
no way to get these hotkey information programmatically.
* If driver tries to delete hotkey for its HII menu, it requires
driver
to
restore hokey support when user leaves its HII menu. This
could easily break the hotkey support in HII browser because
display engine has no control to this.
3. Proposal:
I would like to propose new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL so that driver
can

temporarily
disable hotkey support for certain HII menu in its own form-set.
And display engine will handle the hotkey support accordingly.
struct EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL {
...
REGISTER_HOT_KEY RegisterHotKey;
DISABLE_HOT_KEY DisableHotKey;
...
};
/**
Disable the hotkey by given its browser action.
@param[in] Action Action value to disable corresponding
hotkey.
@param[in] Scope Hotkey scope level to be disabled.
@retval EFI_SUCCESS Hotkey is disabled.
@retval EFI_NOT_FOUND Hotkey with given Action is not
found.
**/
typedef
EFI_STATUS
(EFIAPI *DISABLE_HOT_KEY) (
IN UINT32 Action,
IN BROWSER_SETTING_SCOPE Scope );
May I have your comment about this? Is this good idea for
driver to disable
hotkey support?
Thanks,
Nickle




















Re: [EXTERNAL] Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe

Sami Mujawar <sami.mujawar@...>
 

Hi Rebecca,

I agree MdePkg/Library/BaseRngLib can be refactored to support both x86 and AArch64.
BaseRngLib would then be a RngLib instance that uses CPU instructions to provide random numbers.

Regards,

Sami Mujawar

From: Bret Barkelew <Bret.Barkelew@microsoft.com>
Date: Monday, 26 April 2021 at 22:45
To: devel@edk2.groups.io <devel@edk2.groups.io>, rebecca@nuviainc.com <rebecca@nuviainc.com>, Sami Mujawar <Sami.Mujawar@arm.com>, Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>, Ard Biesheuvel <Ard.Biesheuvel@arm.com>, leif@nuviainc.com <leif@nuviainc.com>
Cc: rfc@edk2.groups.io <rfc@edk2.groups.io>, Yao, Jiewen <jiewen.yao@intel.com>, Rahul Kumar <rahul1.kumar@intel.com>, nd <nd@arm.com>, Jose Marinho <Jose.Marinho@arm.com>
Subject: RE: [EXTERNAL] Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
I vote the latter.

- Bret

From: Rebecca Cran via groups.io<mailto:rebecca=nuviainc.com@groups.io>
Sent: Monday, April 26, 2021 2:29 PM
To: Sami Mujawar<mailto:Sami.Mujawar@arm.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@arm.com>; Ard Biesheuvel<mailto:Ard.Biesheuvel@arm.com>; leif@nuviainc.com<mailto:leif@nuviainc.com>
Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Yao, Jiewen<mailto:jiewen.yao@intel.com>; Rahul Kumar<mailto:rahul1.kumar@intel.com>; nd<mailto:nd@arm.com>; Jose Marinho<mailto:Jose.Marinho@arm.com>
Subject: [EXTERNAL] Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe

Hi Sami,

I've been looking through the design document again, and was wondering
if the work I previously did will just slot in?

Were you thinking the "RngLib|RNDR" would go into ArmPkg (since it's not
labeled as being in BaseRngLib)? Or would it still make sense to
refactor MdePkg/Library/BaseRngLib to support both x86 (using RDRAND)
and aarch64 (using RNDR)?

--
Rebecca Cran



On 4/22/21 3:30 AM, Sami Mujawar wrote:
Hi Rebecca,

I have been working on the following modules (See slide 11 in “EDKII -
Proposed update to RNG implementation.pdf
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0>”<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0%3e”>):

1. TrngLib|FwTrnglib (Arm Firmware TRNG)
2. DrbgLib stack – with support for DrbgAlgorithmLib|CRT_DRBG &
AesLib|ArmAesInstructionLib.

I plan to post patches for (a) in the next fortnight. Following this I
plan to update the proposal with the interface definitions for the
various library interfaces in the DrbgLib Stack.

I have not looked at RngLib|RNDR as I believe you were interested in
implementing the part. Kindly let me know if you plan to implement this
and the platform you would be using for testing. It looks like the
FVP_Base_AEMv8A-AEMv8A and the FVP-RevC models support RNDR, so these
could be used for testing as well. Please feel free to get in touch
should you need any help with the model parameters or if you face any
issues.

Regards,

Sami Mujawar

*From: *Rebecca Cran <rebecca@nuviainc.com>
*Date: *Tuesday, 20 April 2021 at 21:04
*To: *Sami Mujawar <Sami.Mujawar@arm.com>, devel@edk2.groups.io
<devel@edk2.groups.io>, Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@arm.com>, Ard Biesheuvel <Ard.Biesheuvel@arm.com>,
leif@nuviainc.com <leif@nuviainc.com>
*Cc: *rfc@edk2.groups.io <rfc@edk2.groups.io>, Jiewen Yao
<jiewen.yao@intel.com>, Rahul Kumar <rahul1.kumar@intel.com>, nd
<nd@arm.com>, Jose Marinho <Jose.Marinho@arm.com>
*Subject: *Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to
RngDxe

Hi Sami,

I was wondering if you're still collecting feedback on the design, or if
you have a plan and schedule for the implementation?

--
Rebecca Cran

On 1/15/21 7:51 PM, Sami Mujawar wrote:
> Hi All,
>
> I have shared some initial thoughts on the RNG implementation updates
at
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0>
>
> Kindly let me know your feedback or if you have any queries.
>
> Regards,
>
> Sami Mujawar
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Rebecca Cran via groups.io
> Sent: 14 January 2021 09:05 PM
> To: Sami Mujawar <Sami.Mujawar@arm.com>; devel@edk2.groups.io; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Ard Biesheuvel
<Ard.Biesheuvel@arm.com>; leif@nuviainc.com
> Cc: rfc@edk2.groups.io; Jiewen Yao <jiewen.yao@intel.com>; Rahul
Kumar <rahul1.kumar@intel.com>; nd <nd@arm.com>
> Subject: Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to
RngDxe
>
> On 12/10/20 4:26 AM, Sami Mujawar wrote:
>
>> I am working on the TRNG FW API interface and will share more details
>> for the discussion soon.
>>
>> We had some thoughts about streamlining the RngDxe implementations and
>> would like to share some diagrams for the discussion.
>>
>> My diagrams are in Visio that I can export as JPG images. However, I am
>> open to switching to any other suggested tool.
>
> Hi Sami,
>
> I don't see any further discussions on this. Have you made any progress
> with sharing the design documents or scheduling a review?
>


Re: [RFC] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle Wang
 

Hi Liming,

Thank you very much for your feedback. I agree with your idea and it would be good to address this issue from UEFI interface instead of EDK2 interface. However, since there is nothing about HII hotkey in UEFI specification now. This will bring HII hotkey as standard HII interface in UEFI specification. I am expecting more efforts than doing this in EDK2 interface.

Hi Dandan,

May I have your comments about this? We had talked about this before and we think HII hotkey is only EDK2 browser implementation. If we want to have HII hotkey defined in UEFI specification, do you see any objection to this?

For now, I suggest OptionRom driver adds some information in its help message to display them in Setup page. It can notify the user that it doesn't support HotKey. For long term, I propose to introduce new EFI_BROWSER_ACTION type in UEFI spec for the communication between Browser and HII module. When HII module page open, it can return its status of system hot key to Browser, then browser can control whether enable hotkey.
This is good suggestion, Thanks! And the idea of new EFI_BROWSER_ACTION looks good to me too. I will check and see how to do this.

Thanks,
Nickle

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Tuesday, April 27, 2021 11:32 AM
To: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; rfc@edk2.groups.io; lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle:
Sorry for the late response. In fact, there is no UEFI interface between system browser and single HII module. EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL is edk2 implementation. This is not UEFI interface. OptionRom card needs to follow UEFI, and work on UEFI system. So, I don't suggest that HII module consumes EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL. For now, I suggest OptionRom driver adds some information in its help message to display them in Setup page. It can notify the user that it doesn't support HotKey. For long term, I propose to introduce new EFI_BROWSER_ACTION type in UEFI spec for the communication between Browser and HII module. When HII module page open, it can return its status of system hot key to Browser, then browser can control whether enable hotkey.

Thanks
Liming
-----邮件原件-----
发件人: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
发送时间: 2021年4月26日 11:15
收件人: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>;
gaoliming@byosoft.com.cn; lersek@redhat.com
抄送: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hello Liming,

Just a friendly reminder in case you miss this email. It seems to me
that if we do not create the interface to disable HII hotkey, we still
need some improvement to HII in order to address the issues that I
mentioned. What do you think about this?

Thanks,
Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Nickle Wang
Sent: Friday, April 16, 2021 4:13 PM
To: rfc@edk2.groups.io; gaoliming@byosoft.com.cn; lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hi Liming,



Thanks for your comments. I got a chance to talk to option card vendor
and they share two cases that HII driver is not able to support hotkey.



1) Driver cannot support hotkey to load defaults.



Form EDK2 display engine driver
(MdeModulePkg\Universal\DisplayEngineDxe), it binds load default
hotkey to standard default.



[cid:image001.png@01D732D8.521D5DE0]



However, there is no interface for option card driver to see what
default type that hotkey support. When option card driver supports OEM
defaults or the defaults other than display engine sets, nothing will
happen. And different IBV may support different default setting with
hotkey. So option card driver has to implement their own HII button to address this interoperability Issue.



2) Driver needs user to submit data before user leaves certain HII menu.
Hotkey does not work in this way.



This is the example from EDK2 iSCSI driver again. Below are the steps
to add iSCSI Attempt:



[cid:image003.png@01D732D9.C4F71C60]



Due to the design of iSCSI HII driver, user has to submit data at step
3 before user goes back to step 2 and select another network
interface. If user does not submit data at step 3, all user’s input
may be lost after user selects another network interface. However, we
have no way to force user to press
F10 hotkey here. By EDK2 design, hotkey works in form-set scope. User
can press hotkey at anywhere when user finish the configuration. As
the result, option card driver has to disable hotkey and force user to
use HII button to submit data.



So, what do you think about above two cases?



Thanks,

Nickle



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, March 30, 2021 9:16 AM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>;
lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support



Nickle:



-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Nickle Wang

发送时间: 2021年3月26日 12:05
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
lersek@redhat.com<mailto:lersek@redhat.com>

抄送: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Thanks for your feedback, Liming. Please see my comment below.
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of gaoliming

Sent: Friday, March 26, 2021 9:51 AM
To: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

lersek@redhat.com<mailto:lersek@redhat.com>
Cc: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
Nickle:
-----邮件原件-----
发件人: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>

发送时间: 2021年3月25日 15:41
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;

lersek@redhat.com<mailto:lersek@redhat.com>
抄送: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of

gaoliming
Sent: Thursday, March 25, 2021 11:40 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
lersek@redhat.com<mailto:lersek@redhat.com>; Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
Cc: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Laszlo

Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>

抄送: Dandan Bi
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
On 03/24/21 09:21, Nickle Wang wrote:
Hi All,
I am having trouble to disable hotkey support in HII
browser
with existing
interface. I am wondering if we could have new interface to
disable hotkey support in form browser extension2 protocol.
1. Background:
In some HII driver, there is no need to have hotkey
support
in certain HII
menu due to its design. The examples are EDK2 iSCSI driver,
secure boot configuration and Tls auth configuration driver.
In these HII menus, there is HII button to do submit or
discard job and they do not answer to hotkey action. I also
see this design in 3rd party option card driver. In this
case,
user feels confused because it dose not do anything while
pressing hotkey. The only way to save or discard data is by
pressing the button on HII menu. So, we need to disable
hotkey
support and force user to use HII button.
I agree with the problem statement. I've noticed this too,
and
found it confusing.
I wonder if there are HII guidelines or best known practices
to deal with it -- I assume that one desirable solution
might
be if we could control the hotkeys just from the VFR, one
way
or another. But indeed I don't know if that's feasible by design.
UEFI driver write guide 12.6.1 Minimize callbacks section
defines the guide line.
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Dri
ve
r-
Writer%27s-Guide
But, some HII drivers still like to control
submit/discard/exit
in its form by Callback function.
Hotkey way is to consume HII driver ConfigAccess protocol
RouteConfig() function for data saving.
So, HotKey doesn't work on those drivers.
For this proposal, I want to understand when new interface
will
be trigged and what module calls this new API.
The module to call this new API is the HII driver which has no
hotkey support in its HII menu. The HII driver could also be
option card
driver.

As for when the new interface will be triggered, there are two
cases in my
mind:
1. Driver wants to disable hotkey support for entire HII form-set.
1.1 Driver will call new interface in ExtractConfig() function
with Scope "FormSetLevel".
1.2 Driver calls new interface in Callback() function when
Action is set to EFI_BROWSER_ACTION_FORM_OPEN. With Scope "
FormLevel",
this
will disable hotkey for every HII menu.
2. Driver only disable hotkey support for certain HII menu.
2. Same as 1.2 but driver have condition check to see if this
is
target HII menu or not. The Scope is set to " FormLevel" and the
hotkey support is restored automatically by display engine when
user
leaves this HII menu.
So, your proposal is to let HII driver call new API to disable or
enable Hotkey on its page.
There are still some issues here.
1. UEFI option rom driver is the independent driver. It refers to
the standard UEFI interface.
But, form browser extension2 protocol is edk2 extension. Other
UEFI
implementation may not provide this protocol.
It would be good if we could have HII hotkey definition in UEFI specification.
But it looks like the HII hotkey support is just EDK2 form browser
implementation specific. So I would like to address the issue from
EDK2 protocol.
As far as I know, option card vendor has chance to support edk2
protocol because edk2 is kind like the industrial UEFI implementation.
And it is also easy to know if this system supports form browser
extension2
protocol or not.

Option card driver could code its behaviour accordingly


Browser implementation may be different. Please see the message
INVALID URI REMOVED
11__;!!NpxR!wupnCRk9oRVDzLRnKKZ37ZViIaEVk29Pp5op9BRoPlUqTws1e2ZfFHMl8x
V5F-0$



2. Browser may have the different Hotkey. UEFI driver doesn't know
to disable which Hotkey.
Yes, I also noticed this. So the new interface accept "Action" of
hotkey as parameter. So that UEFI driver does not need to know which
hotkey he has to disable. For example, browser may define F9 for
BROWSER_ACTION_SUBMIT and F10 to do BROWSER_ACTION_DEFAULT.
Then, no

matter what hotkey that browser defines for submit and default job,
UEFI driver can disable them by below calls:
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_SUBMIT, FormLevel);
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_DEFAULT, FormLevel);
Then browser will disable the hotkey that is binding to above actions.
UEFI driver does not need to know the specific hotkey to disable.
Instead, UEFI driver disable the action that he does not want to
support
through hotkey.

When UEFI driver provides their own HII button for these actions, he
would understand what action that they do not want hotkey support.


So, you mean in form open callback to disable hotkey in form level.
Once exit this form, Browser will restore original hotkey. Right?



In fact, UEFI spec defines HII ConfigAccess protocol for data read
and
write.

HII driver should follow this way.
I am not the owner of EDK2 iSCSI driver but I expect that there
might
be some trouble to support hotkey to save iSCSI attempt setting. My
guess is: iSCSI attempt menu is not one-to-one mapping between iSCSI
attempt setting and HII option. iSCSI attempt menu is shared between
multiple network interfaces.

In this design, there might be difficulty to do this through HII
hotkey. And this also applies to secure boot key enrolment case and
TLS certificate enrolment case in EDK2 drivers.


HII driver doesn't require the display data and save data are 1:1 mapping.

HII driver can convert the display data to the saved data. For
example, the display information is the string, but the saved data is the value.



If HII driver doesn't use this way, it can't be handled by Browser.
I think this
is
the expected behavior.
We don't need to introduce new API for it.
Yes it is expected behavior. But from my point of view, as I
mentioned
above, there might be some trouble to support it so HII driver does
not follow this way. I can see cases in EDK2 driver.
I agree some Edk2 module may not be a good example.



Thanks

Liming



Thanks,
Nickle
Thanks,
Nickle
Thanks
Liming
Thanks
Laszlo
2. Issue:
Currently we have
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.RegisterHotKey
to

create or
delete hotkey support. With value 0 in "Action", we can
delete
corresponding hotkey.
typedef
EFI_STATUS
(EFIAPI *REGISTER_HOT_KEY) (
IN EFI_INPUT_KEY *KeyData,
IN UINT32 Action,
IN UINT16 DefaultId,
IN EFI_STRING HelpString OPTIONAL
);
However, there are some troubles for driver or option card
driver to use it
and delete hotkey support.
* Usually, display engine is the one who creates hotkey in HII
browser.
So driver has no information about the key data. And there
is
no way to get these hotkey information programmatically.
* If driver tries to delete hotkey for its HII menu, it requires
driver
to
restore hokey support when user leaves its HII menu. This
could easily break the hotkey support in HII browser because
display engine has no control to this.
3. Proposal:
I would like to propose new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL so that driver can
temporarily
disable hotkey support for certain HII menu in its own form-set.
And display engine will handle the hotkey support accordingly.
struct EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL {
...
REGISTER_HOT_KEY RegisterHotKey;
DISABLE_HOT_KEY DisableHotKey;
...
};
/**
Disable the hotkey by given its browser action.
@param[in] Action Action value to disable corresponding
hotkey.
@param[in] Scope Hotkey scope level to be disabled.
@retval EFI_SUCCESS Hotkey is disabled.
@retval EFI_NOT_FOUND Hotkey with given Action is not
found.
**/
typedef
EFI_STATUS
(EFIAPI *DISABLE_HOT_KEY) (
IN UINT32 Action,
IN BROWSER_SETTING_SCOPE Scope );
May I have your comment about this? Is this good idea for
driver to disable
hotkey support?
Thanks,
Nickle



















回复: [edk2-rfc] [RFC] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

gaoliming
 

Nickle:
Sorry for the late response. In fact, there is no UEFI interface between system browser and single HII module. EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL is edk2 implementation. This is not UEFI interface. OptionRom card needs to follow UEFI, and work on UEFI system. So, I don't suggest that HII module consumes EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL. For now, I suggest OptionRom driver adds some information in its help message to display them in Setup page. It can notify the user that it doesn't support HotKey. For long term, I propose to introduce new EFI_BROWSER_ACTION type in UEFI spec for the communication between Browser and HII module. When HII module page open, it can return its status of system hot key to Browser, then browser can control whether enable hotkey.

Thanks
Liming

-----邮件原件-----
发件人: Wang, Nickle (HPS SW) <nickle.wang@hpe.com>
发送时间: 2021年4月26日 11:15
收件人: rfc@edk2.groups.io; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>; gaoliming@byosoft.com.cn; lersek@redhat.com
抄送: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; Wang, Nickle (HPS SW)
<nickle.wang@hpe.com>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hello Liming,

Just a friendly reminder in case you miss this email. It seems to me that if we
do not create the interface to disable HII hotkey, we still need some
improvement to HII in order to address the issues that I mentioned. What do
you think about this?

Thanks,
Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Nickle Wang
Sent: Friday, April 16, 2021 4:13 PM
To: rfc@edk2.groups.io; gaoliming@byosoft.com.cn; lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hi Liming,



Thanks for your comments. I got a chance to talk to option card vendor and
they share two cases that HII driver is not able to support hotkey.



1) Driver cannot support hotkey to load defaults.



Form EDK2 display engine driver
(MdeModulePkg\Universal\DisplayEngineDxe), it binds load default hotkey to
standard default.



[cid:image001.png@01D732D8.521D5DE0]



However, there is no interface for option card driver to see what default type
that hotkey support. When option card driver supports OEM defaults or the
defaults other than display engine sets, nothing will happen. And different IBV
may support different default setting with hotkey. So option card driver has to
implement their own HII button to address this interoperability Issue.



2) Driver needs user to submit data before user leaves certain HII menu.
Hotkey does not work in this way.



This is the example from EDK2 iSCSI driver again. Below are the steps to add
iSCSI Attempt:



[cid:image003.png@01D732D9.C4F71C60]



Due to the design of iSCSI HII driver, user has to submit data at step 3 before
user goes back to step 2 and select another network interface. If user does
not submit data at step 3, all user’s input may be lost after user selects
another network interface. However, we have no way to force user to press
F10 hotkey here. By EDK2 design, hotkey works in form-set scope. User can
press hotkey at anywhere when user finish the configuration. As the result,
option card driver has to disable hotkey and force user to use HII button to
submit data.



So, what do you think about above two cases?



Thanks,

Nickle



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, March 30, 2021 9:16 AM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>;
lersek@redhat.com
Cc: 'Dandan Bi' <dandan.bi@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support



Nickle:



-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Nickle Wang

发送时间: 2021年3月26日 12:05
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
lersek@redhat.com<mailto:lersek@redhat.com>

抄送: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Thanks for your feedback, Liming. Please see my comment below.
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of gaoliming

Sent: Friday, March 26, 2021 9:51 AM
To: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

lersek@redhat.com<mailto:lersek@redhat.com>
Cc: 'Dandan Bi' <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Chang, Abner (HPS SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
Nickle:
-----邮件原件-----
发件人: Wang, Nickle (HPS SW)
<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>

发送时间: 2021年3月25日 15:41
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;

lersek@redhat.com<mailto:lersek@redhat.com>
抄送: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>;
Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----Original Message-----
From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of

gaoliming
Sent: Thursday, March 25, 2021 11:40 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
lersek@redhat.com<mailto:lersek@redhat.com>; Wang, Nickle (HPS SW)

<nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>
Cc: 'Dandan Bi'
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
-----邮件原件-----
发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Laszlo

Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;
nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>

抄送: Dandan Bi
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Chang, Abner (HPS
SW/FW

Technologist)
<abner.chang@hpe.com<mailto:abner.chang@hpe.com>>

主题: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support
On 03/24/21 09:21, Nickle Wang wrote:
Hi All,
I am having trouble to disable hotkey support in HII browser
with existing
interface. I am wondering if we could have new interface to
disable hotkey support in form browser extension2 protocol.
1. Background:
In some HII driver, there is no need to have hotkey support
in certain HII
menu due to its design. The examples are EDK2 iSCSI driver,
secure boot configuration and Tls auth configuration driver.
In these HII menus, there is HII button to do submit or
discard job and they do not answer to hotkey action. I also
see this design in 3rd party option card driver. In this case,
user feels confused because it dose not do anything while
pressing hotkey. The only way to save or discard data is by
pressing the button on HII menu. So, we need to disable hotkey
support and force user to use HII button.
I agree with the problem statement. I've noticed this too, and
found it confusing.
I wonder if there are HII guidelines or best known practices
to deal with it -- I assume that one desirable solution might
be if we could control the hotkeys just from the VFR, one way
or another. But indeed I don't know if that's feasible by design.
UEFI driver write guide 12.6.1 Minimize callbacks section
defines the guide line.
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Drive
r-
Writer%27s-Guide
But, some HII drivers still like to control submit/discard/exit
in its form by Callback function.
Hotkey way is to consume HII driver ConfigAccess protocol
RouteConfig() function for data saving.
So, HotKey doesn't work on those drivers.
For this proposal, I want to understand when new interface will
be trigged and what module calls this new API.
The module to call this new API is the HII driver which has no
hotkey support in its HII menu. The HII driver could also be option card
driver.

As for when the new interface will be triggered, there are two
cases in my
mind:
1. Driver wants to disable hotkey support for entire HII form-set.
1.1 Driver will call new interface in ExtractConfig() function
with Scope "FormSetLevel".
1.2 Driver calls new interface in Callback() function when
Action is set to EFI_BROWSER_ACTION_FORM_OPEN. With Scope "
FormLevel",
this
will disable hotkey for every HII menu.
2. Driver only disable hotkey support for certain HII menu.
2. Same as 1.2 but driver have condition check to see if this is
target HII menu or not. The Scope is set to " FormLevel" and the
hotkey support is restored automatically by display engine when
user
leaves this HII menu.
So, your proposal is to let HII driver call new API to disable or
enable Hotkey on its page.
There are still some issues here.
1. UEFI option rom driver is the independent driver. It refers to
the standard UEFI interface.
But, form browser extension2 protocol is edk2 extension. Other UEFI
implementation may not provide this protocol.
It would be good if we could have HII hotkey definition in UEFI specification.
But it looks like the HII hotkey support is just EDK2 form browser
implementation specific. So I would like to address the issue from
EDK2 protocol.
As far as I know, option card vendor has chance to support edk2
protocol because edk2 is kind like the industrial UEFI implementation.
And it is also easy to know if this system supports form browser extension2
protocol or not.

Option card driver could code its behaviour accordingly


Browser implementation may be different. Please see the message
https://edk2.groups.io/g/devel/message/73511



2. Browser may have the different Hotkey. UEFI driver doesn't know
to disable which Hotkey.
Yes, I also noticed this. So the new interface accept "Action" of
hotkey as parameter. So that UEFI driver does not need to know which
hotkey he has to disable. For example, browser may define F9 for
BROWSER_ACTION_SUBMIT and F10 to do BROWSER_ACTION_DEFAULT.
Then, no

matter what hotkey that browser defines for submit and default job,
UEFI driver can disable them by below calls:
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_SUBMIT, FormLevel);
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey
(BROWSER_ACTION_DEFAULT, FormLevel);
Then browser will disable the hotkey that is binding to above actions.
UEFI driver does not need to know the specific hotkey to disable.
Instead, UEFI driver disable the action that he does not want to support
through hotkey.

When UEFI driver provides their own HII button for these actions, he
would understand what action that they do not want hotkey support.


So, you mean in form open callback to disable hotkey in form level. Once exit
this form, Browser will restore original hotkey. Right?



In fact, UEFI spec defines HII ConfigAccess protocol for data read and
write.

HII driver should follow this way.
I am not the owner of EDK2 iSCSI driver but I expect that there might
be some trouble to support hotkey to save iSCSI attempt setting. My
guess is: iSCSI attempt menu is not one-to-one mapping between iSCSI
attempt setting and HII option. iSCSI attempt menu is shared between
multiple network interfaces.

In this design, there might be difficulty to do this through HII
hotkey. And this also applies to secure boot key enrolment case and
TLS certificate enrolment case in EDK2 drivers.


HII driver doesn't require the display data and save data are 1:1 mapping.

HII driver can convert the display data to the saved data. For example, the
display information is the string, but the saved data is the value.



If HII driver doesn't use this way, it can't be handled by Browser.
I think this
is
the expected behavior.
We don't need to introduce new API for it.
Yes it is expected behavior. But from my point of view, as I mentioned
above, there might be some trouble to support it so HII driver does
not follow this way. I can see cases in EDK2 driver.
I agree some Edk2 module may not be a good example.



Thanks

Liming



Thanks,
Nickle
Thanks,
Nickle
Thanks
Liming
Thanks
Laszlo
2. Issue:
Currently we have
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.RegisterHotKey
to

create or
delete hotkey support. With value 0 in "Action", we can delete
corresponding hotkey.
typedef
EFI_STATUS
(EFIAPI *REGISTER_HOT_KEY) (
IN EFI_INPUT_KEY *KeyData,
IN UINT32 Action,
IN UINT16 DefaultId,
IN EFI_STRING HelpString OPTIONAL
);
However, there are some troubles for driver or option card
driver to use it
and delete hotkey support.
* Usually, display engine is the one who creates hotkey in HII
browser.
So driver has no information about the key data. And there is
no way to get these hotkey information programmatically.
* If driver tries to delete hotkey for its HII menu, it requires
driver
to
restore hokey support when user leaves its HII menu. This
could easily break the hotkey support in HII browser because
display engine has no control to this.
3. Proposal:
I would like to propose new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL so that driver can
temporarily
disable hotkey support for certain HII menu in its own form-set.
And display engine will handle the hotkey support accordingly.
struct EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL {
...
REGISTER_HOT_KEY RegisterHotKey;
DISABLE_HOT_KEY DisableHotKey;
...
};
/**
Disable the hotkey by given its browser action.
@param[in] Action Action value to disable corresponding
hotkey.
@param[in] Scope Hotkey scope level to be disabled.
@retval EFI_SUCCESS Hotkey is disabled.
@retval EFI_NOT_FOUND Hotkey with given Action is not
found.
**/
typedef
EFI_STATUS
(EFIAPI *DISABLE_HOT_KEY) (
IN UINT32 Action,
IN BROWSER_SETTING_SCOPE Scope );
May I have your comment about this? Is this good idea for
driver to disable
hotkey support?
Thanks,
Nickle



















Re: [EXTERNAL] Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe

Bret Barkelew <bret.barkelew@...>
 

I vote the latter.

- Bret

From: Rebecca Cran via groups.io<mailto:rebecca=nuviainc.com@groups.io>
Sent: Monday, April 26, 2021 2:29 PM
To: Sami Mujawar<mailto:Sami.Mujawar@arm.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@arm.com>; Ard Biesheuvel<mailto:Ard.Biesheuvel@arm.com>; leif@nuviainc.com<mailto:leif@nuviainc.com>
Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Yao, Jiewen<mailto:jiewen.yao@intel.com>; Rahul Kumar<mailto:rahul1.kumar@intel.com>; nd<mailto:nd@arm.com>; Jose Marinho<mailto:Jose.Marinho@arm.com>
Subject: [EXTERNAL] Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe

Hi Sami,

I've been looking through the design document again, and was wondering
if the work I previously did will just slot in?

Were you thinking the "RngLib|RNDR" would go into ArmPkg (since it's not
labeled as being in BaseRngLib)? Or would it still make sense to
refactor MdePkg/Library/BaseRngLib to support both x86 (using RDRAND)
and aarch64 (using RNDR)?

--
Rebecca Cran



On 4/22/21 3:30 AM, Sami Mujawar wrote:
Hi Rebecca,

I have been working on the following modules (See slide 11 in “EDKII -
Proposed update to RNG implementation.pdf
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0>”<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0%3e”>):

1. TrngLib|FwTrnglib (Arm Firmware TRNG)
2. DrbgLib stack – with support for DrbgAlgorithmLib|CRT_DRBG &
AesLib|ArmAesInstructionLib.

I plan to post patches for (a) in the next fortnight. Following this I
plan to update the proposal with the interface definitions for the
various library interfaces in the DrbgLib Stack.

I have not looked at RngLib|RNDR as I believe you were interested in
implementing the part. Kindly let me know if you plan to implement this
and the platform you would be using for testing. It looks like the
FVP_Base_AEMv8A-AEMv8A and the FVP-RevC models support RNDR, so these
could be used for testing as well. Please feel free to get in touch
should you need any help with the model parameters or if you face any
issues.

Regards,

Sami Mujawar

*From: *Rebecca Cran <rebecca@nuviainc.com>
*Date: *Tuesday, 20 April 2021 at 21:04
*To: *Sami Mujawar <Sami.Mujawar@arm.com>, devel@edk2.groups.io
<devel@edk2.groups.io>, Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@arm.com>, Ard Biesheuvel <Ard.Biesheuvel@arm.com>,
leif@nuviainc.com <leif@nuviainc.com>
*Cc: *rfc@edk2.groups.io <rfc@edk2.groups.io>, Jiewen Yao
<jiewen.yao@intel.com>, Rahul Kumar <rahul1.kumar@intel.com>, nd
<nd@arm.com>, Jose Marinho <Jose.Marinho@arm.com>
*Subject: *Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to
RngDxe

Hi Sami,

I was wondering if you're still collecting feedback on the design, or if
you have a plan and schedule for the implementation?

--
Rebecca Cran

On 1/15/21 7:51 PM, Sami Mujawar wrote:
> Hi All,
>
> I have shared some initial thoughts on the RNG implementation updates
at
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2021%2F0116%2FEDKII%2520-%2520Proposed%2520update%2520to%2520RNG%2520implementation.pdf&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C676a9101f67845dbdc8908d908fa4cd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550693569385394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Q8ka83ReO2aG8yTVrgpTAVxczJVjl2JBH3ksHo2%2BSHk%3D&amp;reserved=0>
>
> Kindly let me know your feedback or if you have any queries.
>
> Regards,
>
> Sami Mujawar
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Rebecca Cran via groups.io
> Sent: 14 January 2021 09:05 PM
> To: Sami Mujawar <Sami.Mujawar@arm.com>; devel@edk2.groups.io; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Ard Biesheuvel
<Ard.Biesheuvel@arm.com>; leif@nuviainc.com
> Cc: rfc@edk2.groups.io; Jiewen Yao <jiewen.yao@intel.com>; Rahul
Kumar <rahul1.kumar@intel.com>; nd <nd@arm.com>
> Subject: Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to
RngDxe
>
> On 12/10/20 4:26 AM, Sami Mujawar wrote:
>
>> I am working on the TRNG FW API interface and will share more details
>> for the discussion soon.
>>
>> We had some thoughts about streamlining the RngDxe implementations and
>> would like to share some diagrams for the discussion.
>>
>> My diagrams are in Visio that I can export as JPG images. However, I am
>> open to switching to any other suggested tool.
>
> Hi Sami,
>
> I don't see any further discussions on this. Have you made any progress
> with sharing the design documents or scheduling a review?
>


Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe

Rebecca Cran
 

Hi Sami,

I've been looking through the design document again, and was wondering if the work I previously did will just slot in?

Were you thinking the "RngLib|RNDR" would go into ArmPkg (since it's not labeled as being in BaseRngLib)? Or would it still make sense to refactor MdePkg/Library/BaseRngLib to support both x86 (using RDRAND) and aarch64 (using RNDR)?

--
Rebecca Cran

On 4/22/21 3:30 AM, Sami Mujawar wrote:
Hi Rebecca,
I have been working on the following modules (See slide 11 in “EDKII - Proposed update to RNG implementation.pdf <https://edk2.groups.io/g/devel/files/Designs/2021/0116/EDKII%20-%20Proposed%20update%20to%20RNG%20implementation.pdf>”):
1. TrngLib|FwTrnglib (Arm Firmware TRNG)
2. DrbgLib stack – with support for DrbgAlgorithmLib|CRT_DRBG &
AesLib|ArmAesInstructionLib.
I plan to post patches for (a) in the next fortnight. Following this I plan to update the proposal with the interface definitions for the various library interfaces in the DrbgLib Stack.
I have not looked at RngLib|RNDR as I believe you were interested in implementing the part. Kindly let me know if you plan to implement this and the platform you would be using for testing. It looks like the FVP_Base_AEMv8A-AEMv8A and the FVP-RevC models support RNDR, so these could be used for testing as well. Please feel free to get in touch should you need any help with the model parameters or if you face any issues.
Regards,
Sami Mujawar
*From: *Rebecca Cran <rebecca@nuviainc.com>
*Date: *Tuesday, 20 April 2021 at 21:04
*To: *Sami Mujawar <Sami.Mujawar@arm.com>, devel@edk2.groups.io <devel@edk2.groups.io>, Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>, Ard Biesheuvel <Ard.Biesheuvel@arm.com>, leif@nuviainc.com <leif@nuviainc.com>
*Cc: *rfc@edk2.groups.io <rfc@edk2.groups.io>, Jiewen Yao <jiewen.yao@intel.com>, Rahul Kumar <rahul1.kumar@intel.com>, nd <nd@arm.com>, Jose Marinho <Jose.Marinho@arm.com>
*Subject: *Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to RngDxe
Hi Sami,
I was wondering if you're still collecting feedback on the design, or if
you have a plan and schedule for the implementation?
--
Rebecca Cran
On 1/15/21 7:51 PM, Sami Mujawar wrote:
> Hi All,
>
> I have shared some initial thoughts on the RNG implementation updates
at https://edk2.groups.io/g/devel/files/Designs/2021/0116/EDKII%20-%20Proposed%20update%20to%20RNG%20implementation.pdf <https://edk2.groups.io/g/devel/files/Designs/2021/0116/EDKII%20-%20Proposed%20update%20to%20RNG%20implementation.pdf>
>
> Kindly let me know your feedback or if you have any queries.
>
> Regards,
>
> Sami Mujawar
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Rebecca Cran via groups.io
> Sent: 14 January 2021 09:05 PM
> To: Sami Mujawar <Sami.Mujawar@arm.com>; devel@edk2.groups.io; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com
> Cc: rfc@edk2.groups.io; Jiewen Yao <jiewen.yao@intel.com>; Rahul
Kumar <rahul1.kumar@intel.com>; nd <nd@arm.com>
> Subject: Re: [edk2-devel] RFC: Adding support for ARM (RNDR etc.) to
RngDxe
>
> On 12/10/20 4:26 AM, Sami Mujawar wrote:
>
>> I am working on the TRNG FW API interface and will share more details
>> for the discussion soon.
>>
>> We had some thoughts about streamlining the RngDxe implementations and
>> would like to share some diagrams for the discussion.
>>
>> My diagrams are in Visio that I can export as JPG images. However, I am
>> open to switching to any other suggested tool.
>
> Hi Sami,
>
> I don't see any further discussions on this. Have you made any progress
> with sharing the design documents or scheduling a review?
>


Re: [edk2-devel] [RFC] Secure boot default key

Ethin Probst
 

I agree with Laszlo on this. Duplicating functionality violates DRY
and also could introduce major inconsistencies between how the tool
functions and how the firmware does the same. The only way to
alleviate this problem is for us to (somehow) make the Python tool (or
Rust tool or whatever language we decide to write the tool in)
interface with the C code powering the DXE driver in the
firmware/Security PKG. I know that Python and Rust can do this, via
`ctypes` and `extern "C"` respectively, but that may not be possible
-- we'd need to build the library for both the host platform/operating
system/CPU architecture and the target architecture/UEFI.

On 4/26/21, Min Xu <min.m.xu@intel.com> wrote:
On April 26, 2021 4:15 PM, Sunny Wang wrote:
Hi Min Xu,

Yeah, the standalone tool is good and can bring the benefits you
mentioned,
but I'm still not clear on the standalone tool. Could you give us more
information about the standalone tool? Do you mean to have a standalone
tool to directly add/modify default secure boot keys in the pre-build Var
Store FD image/FV? If so, we thought about that. However, some platforms
like RPi4 don't have the pre-build Var Store FD image/FV and may not want
to add this to take additional flash space, so I think we can still go
with the
current proposal first to cover this case and generally cover all the
cases.
Then, we can separately work on the standalone tool. What do you guys
think?
Yes, a standalone tool I mean is the one that directly add/modify default
secure boot keys in the pre-build Var Store FV.
I also want to hear other people's opinions on this RFC.


Moreover, there is another thing I'm confused about. We found
https://github.com/jyao1/edk2-
staging/blob/TDVF/TdvfPkg/scripts/VarEnroll.py that is in the branch
owned
by you and Jiewen. Is VarEnroll.py the standalone tool you mentioned?
Yes, VarEnroll.py is the tool we used in TDVF (TDX Virtual Firmware) to
enroll secure boot keys.


Best Regards,
Sunny Wang

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Min Xu via
groups.io
Sent: Monday, April 26, 2021 10:18 AM
To: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Laszlo
Ersek <lersek@redhat.com>; rfc@edk2.groups.io; gjb@semihalf.com
Cc: Marcin Wojtas <mw@semihalf.com>; Sunny Wang
<Sunny.Wang@arm.com>; Paul Yang <Paul.Yang@arm.com>;
ardb+tianocore@kernel.org; Leif Lindholm <leif@nuviainc.com>; Wang, Jian
J
<jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Secure boot default key

Agree that it is a good idea to provide a mechanism to enroll the Secure
boot
keys.

But why not add a standalone tool in BaseTools? For example a Python
scripts to enroll the Secure Boot keys. I think there are below benefits:
- The usage of the tool can be flexible. For example, the developer,
validation guys can invoke this tool to enroll keys to do the test.
Even the CI can leverage this tool to enroll keys in post build phase.
- Secure Boot keys can be easily updated. Furthermore the tool can do
more checking on the keys, such as the cert format, key strength, etc.
- Keep EDK2 focusing on the key functions. Some other nice-to-have
functions can be implemented by the tools in BaseTools.

-----Original Message-----
From: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Sent: Saturday, April 17, 2021 3:00 AM
To: Laszlo Ersek <lersek@redhat.com>; rfc@edk2.groups.io;
gjb@semihalf.com
Cc: Marcin Wojtas <mw@semihalf.com>; Sunny Wang
<Sunny.Wang@arm.com>;
Paul Yang <Paul.Yang@arm.com>;
ardb+tianocore@kernel.org; Leif Lindholm <leif@nuviainc.com>; Xu, Min
ardb+M
<min.m.xu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao,
Jiewen <jiewen.yao@intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>
Subject: RE: [edk2-rfc] [edk2-devel] [RFC] Secure boot default key

Adding SecurityPkg and Arm maintainers



-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Friday, April 16, 2021 8:16 AM
To: rfc@edk2.groups.io; gjb@semihalf.com
Cc: Marcin Wojtas <mw@semihalf.com>; Samer El-Haj-Mahmoud
<Samer.El-
Haj-Mahmoud@arm.com>; Sunny Wang <Sunny.Wang@arm.com>; Paul
Yang
<Paul.Yang@arm.com>
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Secure boot default key

On 04/16/21 14:10, Laszlo Ersek wrote:
On 04/15/21 13:59, Grzegorz Bernacki wrote:
Hello,

I would like to ask you to review the proposal for new
application for enrolling Secure Boot keys. The application uses
content of PKDefault, KEKDefault, dbDefault, dbtDefault and
dbxDefault to set Secure Boot key. Default variables are
initialized based on keys embedded in flash binary file. Please
find
details in following document:

https://drive.google.com/file/d/1rC6BjRWKODdXPdAa5cIeBG8_ye2L8aSZ/v
ie
w?usp=sharing
- A new platform DXE driver (which need not even stay resident),
for locating some FFS files and their sections, and for copying
their contents into PKDefault and friends, seems like a good /
useful
idea to me.

- Regarding the following sentence:

However there is no need to keep these variables as non-volatile
in order to avoid unnecessary bloating of the consumed
non-volatile storage space.
This is valid, but redundant (or at least somewhat redundantly
expressed), IMO. The UEFI spec already marks PKDefault as "BS, RT"
(section 3.3).

- The setting of PK from PKDefault (and similarly for the other
variables) is indeed a separate action. The UEFI spec says this is
primarily an OS action (again section 3.3), but I agree having a
dedicated UEFI app for this may be useful.

- Regarding the following sentence:

In case when default variables are already initialized a warning
message will be printed and variables will not be changed.

A warning is possible perhaps via status code reporting, or DEBUG.
A platform DXE driver is not supposed to write to the console.

- The idea as a whole looks good to me. I agree it should be
testable with OVMF, provided the FDF file(s) are modified as
needed; however, I wouldn't like to have that in the FDF file(s)
permanently
-- or at least it should be gated with a new build time feature test
macro.

The

SECTION RAW = ...

statements in the FDF files could perhaps refer to macros as well
(for the pathnames). So a user building a platform with this
feature enabled would have to pass a -D flag (boolean) for
enabling the feature in general (enabling the necessary lines in
both the DSC and the FDF file(s)), and then further -D flags for
specifying the pathnames.

You could perhaps introduce DSC and FDF snippets (include files)
too, under SecurityPkg, so that any platform utilizing this feature
do so through identical macro names.

Thanks
Laszlo
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.




IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient,
please notify the sender immediately and do not disclose the contents to
any
other person, use it for any purpose, or store or copy the information in
any
medium. Thank you.




--
Signed,
Ethin D. Probst

81 - 100 of 713