Date   

Re: removing CHAP-MD5 from IScsiDxe

Maciej Rabeda <maciej.rabeda@...>
 

Laszlo,

I do appreciate analysis - thorough as always :)

To points:

* 1, 2, 3 - That would be inevitable in order to properly introduce
other hash algorithms for CHAP. Adding multiple CHAP hash algorithms
opens more questions:
o Should CHAP algorithm be negotiated between initiator and target
automatically or should the user choose exactly which hash
algorithm should be used.
o First option requires some extra logic, but does not affect
iSCSI attempt variable structure.
o Second option touches iSCSI attempt variable structure (selected
algorithm has to be conveyed with the attempt), which opens up a
problem of dealing with already defined attempts after iSCSI
driver update.
* 4, 5, 6, 7 - I do agree with you, both options seem to be ugly.
NetworkPkg is self-contained and adding drivers from other packages
is not a good idea.
* 8 - A possibility would be to probe for EFI_HASH2_PROTOCOL. If it
was not found, iSCSI might not expose CHAP options via HII and
assume that CHAP is disabled.
o Open again: how to deal with already defined attempts configured
to use CHAP?

As for:

The first compat breakage does not disturb me. We've already agreed that
breaking RFC compat by not offering CHAP_A=5 is fine.


Is the decision on actually removing MD5 from EDKII a UEFI-wide decision or are we establishing it locally?
In the latter case, I am leaning towards MD5 opt-out with ENABLE_MD5_DEPRECATED_INTERFACES unless we have a consensus between iSCSI target providers that they support SHA* hash algorithms.

Thanks,
Maciej

On 07-Apr-21 14:48, Laszlo Ersek wrote:
Maciej,

On 04/01/21 16:24, Maciej Rabeda wrote:
Hi,

Sorry for the very late response.

Dropping iSCSI overall is a no-go - too many users + this is the only
remote block I/O we seem to support in EDKII.
As for RFC compliance vs EDKII policy on MD5... Naturally, CHAP with MD5
does not bring any security features due to MD5's vulnerability.
However, since MD5 is the only hash algorithm for CHAP supported by
IScsiDxe, removing MD5 implies removing CHAP-related code from IScsiDxe
overall, which I would be pretty hesitant to do.

RFC states that MD5 has to be supported, though I can see that CHAP
algorithm allows for different hash algorithms
(https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9).

We could support CHAP with SHA-x in IScsiDxe, which removes the MD5
dependency and keeps the CHAP-related code in iSCSI still in place.

The question is: do OS-based initiators support hash algorithms other
than MD5 for CHAP?
I am pretty sure RHEL does (controlled via /etc/iscsi/iscsid.conf), but
I am not sure about others: Windows, VMware, ...
Looking at the code for a few hours, I've had the following (roundabout)
thought process.

(1) The IScsiCHAP.[hc] files hardwire the MD5 dependency, including
direct MD5 API calls to BaseCryptLib. The idea is to generalize this to
a table of digest algos, indexed / matched by CHAP_A.

The first step would be to just turn the present MD5 support into such a
"hash algo lookup" form (with an eye towards adding a SHA256 entry to
the digest algo table later).

(2) Add a SHA256 entry to the table, using CHAP_A value 7, and using
pointers to the BaseCryptLib functions Sha256GetContextSize() and friends.

(3) Make the MD5 entry conditional on ENABLE_MD5_DEPRECATED_INTERFACES.

(4) Unfortunately, step (2) would more or less reproduce the "mHashInfo"
table we already have in "SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c"
(that is, in the implementation of EFI_HASH2_PROTOCOL).

Duplicating that table (especially with the function pointer typedefs,
for the members in the EFI_HASH_INFO record type) is ugly as heck.

Extracting said funcptr types is a PITA too -- they incorrectly use the
EFI_ prefix (ex. EFI_HASH_UPDATE), so simply moving them to a public
header file won't fly.

(5) Well, how about rebasing IScsiDxe from BaseCryptLib to
EFI_HASH2_PROTOCOL?

It turns out that IScsiDxe depends on BaseCryptLib -- what's more, on
CryptoPkg altogether! -- only for the MD5 APIs called in
IScsiCHAPCalculateResponse() [NetworkPkg/IScsiDxe/IScsiCHAP.c].
Therefore, the digest algo generalization should actually be started by
replacing the direct MD5 calls with EFI_HASH2_PROTOCOL usage, using the
standard GUID "gEfiHashAlgorithmMD5Guid".

(6) For this, a table would still be needed, but it would map CHAP_A
values to hash algo GUIDs *only* (so it'd be a much simpler table than
the one from (2)).

(7) However... using EFI_HASH2_PROTOCOL would break compatibility, for
two reasons.

The first reason is that our EFI_HASH2_PROTOCOL implementation does not
support MD5 at all, since commit 0a1b6d0be337
("SecurityPkg/Hash2DxeCrypto: Remove MD5 support", 2020-11-17). So
platforms could not opt in to MD5 even if they wanted to.

The second reason is that platforms may include IScsiDxe (via
NETWORK_ISCSI_ENABLE), but not Hash2DxeCrypto. On such platforms, CHAP
auth would always fail (the gBS->LocateProtocol() call for
EFI_HASH2_PROTOCOL would fail). The solution for this would be to either
(a) find all platforms in edk2 *and* edk2-platforms that expose
NETWORK_ISCSI_ENABLE, and make sure they include Hash2DxeCrypto too; or
(b) modify "NetworkComponents.dsc.inc", for including Hash2DxeCrypto
alongside IScsiDxe.

The first compat breakage does not disturb me. We've already agreed that
breaking RFC compat by not offering CHAP_A=5 is fine.

The second compat breakage does bother me: I'm very much not looking
forward to (a) extending umpteen DSC files in *edk2-platforms* for
including Hash2DxeCrypto, nor do I feel happy about (b) referring to
Hash2DxeCrypto from *SecurityPkg* in the *NetworkPkg* DSC include file.

I feel that the second compat breakage invalidates the whole
EFI_HASH2_PROTOCOL consumption idea, unfortunately.

(8) Ultimately, the simplest approach is to keep IScsiDxe self-contained
(= directly dependent on BaseCryptLib), and to *replace* MD5, as the
sole supported CHAP algo, with SHA256. IScsiDxe would remain
"single-digest", so to say; there would be no change to the control flow
anywhere.

ACK?

Thanks
Laszlo


Thanks,
Maciej

On 19-Mar-21 18:39, Desimone, Nathaniel L wrote:
I'm honestly surprised that the iSCSI RFC has not been updated to drop
CHAP-MD5 at this point. I realize that is probably a bigger effort but
it seems like something the industry should do. I agree that having a
FeaturePcd for CHAP MD5 and having it default to False is probably the
right thing to do.

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Samer El-Haj-
Mahmoud
Sent: Friday, March 19, 2021 10:08 AM
To: rfc@edk2.groups.io; simo@...; Laszlo Ersek
<lersek@...>
Cc: Maciej Rabeda <maciej.rabeda@...>; Wu, Jiaxin
<jiaxin.wu@...>; Fu, Siyuan <siyuan.fu@...>; Daniel P.
Berrangé <berrange@...>; Yash Mankad <ymankad@...>;
Pete Batard <pete@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
Subject: Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

When the RPi UEFI FW dropped iSCSI (because it was removed from
NetworkDefines.dsc.inc), we got multiple users complaining since they
had
existing use cases that depended on that. See for instance the RPi4 UEFI
reported bug: https://github.com/pftf/RPi4/issues/125

Some use-cases and user scenarios for iSCSI on RPi4:
https://blogs.vmware.com/arm/2020/10/17/esxi-arm-with-iscsi/
https://tech.xlab.si/blog/pxe-boot-raspberry-pi-iscsi/
https://www.virtuallyghetto.com/2020/07/two-methods-to-network-boot-
raspberry-pi-4.html

The RPi4 users preferred having iSCSI (without CHAP) than not having
it at all.
We resorted to enabling it out-of-tree using a build switch.

 From my experience, I think the EDK2 iScsiDxe software initiator is
being
wildly used on many servers (and OSes) across the industry (just google
"UEFI iSCSI"). Having it silently dropped from EDK2 is not optimal. I
like
Laszlo's idea of a PCD to break the RFC (and using an iSCSI boot
variant that
does not support CHAP), and I think it is a good compromise. The
alternative
is for downstream implementations to resort to enabling it (probably
just set
NETWORK_ISCSI_ENABLE=TRUE) to keep their users happy.

Thanks,
--Samer

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Simo Sorce
via groups.io
Sent: Friday, March 19, 2021 9:26 AM
To: Laszlo Ersek <lersek@...>; edk2-rfc-groups-io
<rfc@edk2.groups.io>
Cc: Maciej Rabeda <maciej.rabeda@...>; Jiaxin Wu
<jiaxin.wu@...>; Siyuan Fu <siyuan.fu@...>; Daniel P.
Berrangé <berrange@...>; Yash Mankad
<ymankad@...>
Subject: Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

On Fri, 2021-03-19 at 14:15 +0100, Laszlo Ersek wrote:
Hi,

RFC 7143 requires CHAP-MD5 as a mandatory option offered by an iscsi
client (initiator).

At the same time, edk2 has deprecated MD5 in general, as a
cryptographically weak hash algorithm.

Consequently, the "NetworkDefines.dsc.inc" file defines
NETWORK_ISCSI_ENABLE with default value FALSE (commit
4ecb1ba5efa3 /
TianoCore#3003). Platforms that want to include IScsiDxe need to opt
in consciously to the presence of CHAP-MD5 in the code.

We're not happy with this granularity. We'd prefer:

- explicitly breaking RFC 7143 conformance,
- removing CHAP-MD5,
- and using an IScsiDxe variant that is honest about having no
confidentiality / integrity.

IScsiDxe is safe on a trusted network, and only on a trusted network.
The presence of CHAP-MD5 suggests it may be safe on an untrusted
network too, and that implication (not the whole iscsi client
functionality) is what we should rid ourselves of.
Lazlo,
This sounds like the right direction to me.

My 2C,
Simo.

Are NetworkPkg maintainers open to breaking RFC 7143 conformance in
IScsiDxe (perhaps with a feature PCD?), or should we look into this
only downstream?

Downstream, we might decide to drop IScsiDxe altogether, in sync
with the upstream NETWORK_ISCSI_ENABLE=FALSE default -- that
decision has not been made yet. Now I'm just testing whether keeping
IScsiDxe enabled down-stream would require us to carry downstream-
only patches.
Thanks
Laszlo
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc







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] Documents under RedfishPkg

Abner Chang
 

Thanks Mike and Laszlo for the comments.
I would have the readme markdown under RedfishPkg with SVG for the complex diagrams. PlantUML is good to the porting guide markdown for easy review.
Abner

-----Original Message-----
From: Kinney, Michael D [mailto:michael.d.kinney@...]
Sent: Wednesday, April 7, 2021 4:30 AM
To: rfc@edk2.groups.io; lersek@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Kinney, Michael D
<michael.d.kinney@...>
Subject: RE: [edk2-rfc] [RFC] Documents under RedfishPkg

Hi Abner,

PlantUML is a way to embed some graphics in GitHub markdown text. Avoids
checking in SVG or BMP or PNG binaries.

INVALID URI REMOVED
3A__plantuml.com_&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6F
ZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=dopb0lYExPus6V854vF8a
pisNnwzidkdZGS2XDjtA14&s=9nCqxY2Suxl1CLUlz-
Azhi6FWaZORPo3oQLiTfq4fI0&e=

INVALID URI REMOVED
3A__plantuml.com_en_guide&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg
&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=dopb0lYExPus6
V854vF8apisNnwzidkdZGS2XDjtA14&s=EjaowDShCFlt013uCcS-
QiSe0br8c9eGeLYMQyGKG0o&e=


Here is an example of using PlatUML from a Wiki page with the PlantUML
source text file also checked in.

https://github.com/tianocore-docs/edk2-
TemplateSpecification/wiki/TianoCore-Documents-GitBook-
Overview#introduction

GitHub Markdown source line that uses PlantUML server to convert
PlantUML source to a SVG when the page is viewed.

![GitBookOverview](INVALID URI REMOVED
3A__www.plantuml.com_plantuml_proxy-3Fsrc-3Dhttps-
3A__raw.githubusercontent.com_wiki_tianocore-2Ddocs_edk2-
2DTemplateSpecification_plantuml_GitBookOverview.puml&d=DwIGaQ&c=
C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7
Z5q59A3E&m=dopb0lYExPus6V854vF8apisNnwzidkdZGS2XDjtA14&s=x2nZ6fZ
0N29Q5-WRynU6bf1vwK7pOrOID4cqIS41Rfw&e= )

PlantUML source file

INVALID URI REMOVED
3A__raw.githubusercontent.com_wiki_tianocore-2Ddocs_edk2-
2DTemplateSpecification_plantuml_GitBookOverview.puml&d=DwIGaQ&c=
C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7
Z5q59A3E&m=dopb0lYExPus6V854vF8apisNnwzidkdZGS2XDjtA14&s=ToF_Ks
UzwXf97ohi5HZhARPubr7s1zqqrPnlSiSXUks&e=


Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Tuesday, April 6, 2021 7:06 AM
To: rfc@edk2.groups.io; abner.chang@...
Subject: Re: [edk2-rfc] [RFC] Documents under RedfishPkg

On 03/26/21 16:42, Abner Chang wrote:
Hi edk2 Stewards,
Is that ok to put some EDK2 Redfish port guide or design block diagrams in
a folder under RedfishPkg? e.g.
RedfishPkg/Documents?
Any practices we have on the current edk2 repo?
If you can add the documents in some text-based representation (markup
or plaintext), where "reviewing patches" will make sense in the future,
then I welcome adding the documentation under RedfishPkg.

(If you have diagrams, I think SVG might be good for those.)

Other packages have introduced porting and other accompanying
documentation in the wiki, but I find that inferior. I don't like it
when documentation lives in a separate repository from the code that it
documents.

Thanks
Laszlo





Re: removing CHAP-MD5 from IScsiDxe

Laszlo Ersek
 

Maciej,

On 04/01/21 16:24, Maciej Rabeda wrote:
Hi,

Sorry for the very late response.

Dropping iSCSI overall is a no-go - too many users + this is the only
remote block I/O we seem to support in EDKII.
As for RFC compliance vs EDKII policy on MD5... Naturally, CHAP with MD5
does not bring any security features due to MD5's vulnerability.
However, since MD5 is the only hash algorithm for CHAP supported by
IScsiDxe, removing MD5 implies removing CHAP-related code from IScsiDxe
overall, which I would be pretty hesitant to do.

RFC states that MD5 has to be supported, though I can see that CHAP
algorithm allows for different hash algorithms
(https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9).

We could support CHAP with SHA-x in IScsiDxe, which removes the MD5
dependency and keeps the CHAP-related code in iSCSI still in place.

The question is: do OS-based initiators support hash algorithms other
than MD5 for CHAP?
I am pretty sure RHEL does (controlled via /etc/iscsi/iscsid.conf), but
I am not sure about others: Windows, VMware, ...
Looking at the code for a few hours, I've had the following (roundabout)
thought process.

(1) The IScsiCHAP.[hc] files hardwire the MD5 dependency, including
direct MD5 API calls to BaseCryptLib. The idea is to generalize this to
a table of digest algos, indexed / matched by CHAP_A.

The first step would be to just turn the present MD5 support into such a
"hash algo lookup" form (with an eye towards adding a SHA256 entry to
the digest algo table later).

(2) Add a SHA256 entry to the table, using CHAP_A value 7, and using
pointers to the BaseCryptLib functions Sha256GetContextSize() and friends.

(3) Make the MD5 entry conditional on ENABLE_MD5_DEPRECATED_INTERFACES.

(4) Unfortunately, step (2) would more or less reproduce the "mHashInfo"
table we already have in "SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c"
(that is, in the implementation of EFI_HASH2_PROTOCOL).

Duplicating that table (especially with the function pointer typedefs,
for the members in the EFI_HASH_INFO record type) is ugly as heck.

Extracting said funcptr types is a PITA too -- they incorrectly use the
EFI_ prefix (ex. EFI_HASH_UPDATE), so simply moving them to a public
header file won't fly.

(5) Well, how about rebasing IScsiDxe from BaseCryptLib to
EFI_HASH2_PROTOCOL?

It turns out that IScsiDxe depends on BaseCryptLib -- what's more, on
CryptoPkg altogether! -- only for the MD5 APIs called in
IScsiCHAPCalculateResponse() [NetworkPkg/IScsiDxe/IScsiCHAP.c].
Therefore, the digest algo generalization should actually be started by
replacing the direct MD5 calls with EFI_HASH2_PROTOCOL usage, using the
standard GUID "gEfiHashAlgorithmMD5Guid".

(6) For this, a table would still be needed, but it would map CHAP_A
values to hash algo GUIDs *only* (so it'd be a much simpler table than
the one from (2)).

(7) However... using EFI_HASH2_PROTOCOL would break compatibility, for
two reasons.

The first reason is that our EFI_HASH2_PROTOCOL implementation does not
support MD5 at all, since commit 0a1b6d0be337
("SecurityPkg/Hash2DxeCrypto: Remove MD5 support", 2020-11-17). So
platforms could not opt in to MD5 even if they wanted to.

The second reason is that platforms may include IScsiDxe (via
NETWORK_ISCSI_ENABLE), but not Hash2DxeCrypto. On such platforms, CHAP
auth would always fail (the gBS->LocateProtocol() call for
EFI_HASH2_PROTOCOL would fail). The solution for this would be to either
(a) find all platforms in edk2 *and* edk2-platforms that expose
NETWORK_ISCSI_ENABLE, and make sure they include Hash2DxeCrypto too; or
(b) modify "NetworkComponents.dsc.inc", for including Hash2DxeCrypto
alongside IScsiDxe.

The first compat breakage does not disturb me. We've already agreed that
breaking RFC compat by not offering CHAP_A=5 is fine.

The second compat breakage does bother me: I'm very much not looking
forward to (a) extending umpteen DSC files in *edk2-platforms* for
including Hash2DxeCrypto, nor do I feel happy about (b) referring to
Hash2DxeCrypto from *SecurityPkg* in the *NetworkPkg* DSC include file.

I feel that the second compat breakage invalidates the whole
EFI_HASH2_PROTOCOL consumption idea, unfortunately.

(8) Ultimately, the simplest approach is to keep IScsiDxe self-contained
(= directly dependent on BaseCryptLib), and to *replace* MD5, as the
sole supported CHAP algo, with SHA256. IScsiDxe would remain
"single-digest", so to say; there would be no change to the control flow
anywhere.

ACK?

Thanks
Laszlo


Thanks,
Maciej

On 19-Mar-21 18:39, Desimone, Nathaniel L wrote:
I'm honestly surprised that the iSCSI RFC has not been updated to drop
CHAP-MD5 at this point. I realize that is probably a bigger effort but
it seems like something the industry should do. I agree that having a
FeaturePcd for CHAP MD5 and having it default to False is probably the
right thing to do.

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Samer El-Haj-
Mahmoud
Sent: Friday, March 19, 2021 10:08 AM
To: rfc@edk2.groups.io; simo@...; Laszlo Ersek
<lersek@...>
Cc: Maciej Rabeda <maciej.rabeda@...>; Wu, Jiaxin
<jiaxin.wu@...>; Fu, Siyuan <siyuan.fu@...>; Daniel P.
Berrangé <berrange@...>; Yash Mankad <ymankad@...>;
Pete Batard <pete@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
Subject: Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

When the RPi UEFI FW dropped iSCSI (because it was removed from
NetworkDefines.dsc.inc), we got multiple users complaining since they
had
existing use cases that depended on that. See for instance the RPi4 UEFI
reported bug: https://github.com/pftf/RPi4/issues/125

Some use-cases and user scenarios for iSCSI on RPi4:
https://blogs.vmware.com/arm/2020/10/17/esxi-arm-with-iscsi/
https://tech.xlab.si/blog/pxe-boot-raspberry-pi-iscsi/
https://www.virtuallyghetto.com/2020/07/two-methods-to-network-boot-
raspberry-pi-4.html

The RPi4 users preferred having iSCSI (without CHAP) than not having
it at all.
We resorted to enabling it out-of-tree using a build switch.

 From my experience, I think the EDK2 iScsiDxe software initiator is
being
wildly used on many servers (and OSes) across the industry (just google
"UEFI iSCSI"). Having it silently dropped from EDK2 is not optimal. I
like
Laszlo's idea of a PCD to break the RFC (and using an iSCSI boot
variant that
does not support CHAP), and I think it is a good compromise. The
alternative
is for downstream implementations to resort to enabling it (probably
just set
NETWORK_ISCSI_ENABLE=TRUE) to keep their users happy.

Thanks,
--Samer

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Simo Sorce
via groups.io
Sent: Friday, March 19, 2021 9:26 AM
To: Laszlo Ersek <lersek@...>; edk2-rfc-groups-io
<rfc@edk2.groups.io>
Cc: Maciej Rabeda <maciej.rabeda@...>; Jiaxin Wu
<jiaxin.wu@...>; Siyuan Fu <siyuan.fu@...>; Daniel P.
Berrangé <berrange@...>; Yash Mankad
<ymankad@...>
Subject: Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

On Fri, 2021-03-19 at 14:15 +0100, Laszlo Ersek wrote:
Hi,

RFC 7143 requires CHAP-MD5 as a mandatory option offered by an iscsi
client (initiator).

At the same time, edk2 has deprecated MD5 in general, as a
cryptographically weak hash algorithm.

Consequently, the "NetworkDefines.dsc.inc" file defines
NETWORK_ISCSI_ENABLE with default value FALSE (commit
4ecb1ba5efa3 /
TianoCore#3003). Platforms that want to include IScsiDxe need to opt
in consciously to the presence of CHAP-MD5 in the code.

We're not happy with this granularity. We'd prefer:

- explicitly breaking RFC 7143 conformance,
- removing CHAP-MD5,
- and using an IScsiDxe variant that is honest about having no
confidentiality / integrity.

IScsiDxe is safe on a trusted network, and only on a trusted network.
The presence of CHAP-MD5 suggests it may be safe on an untrusted
network too, and that implication (not the whole iscsi client
functionality) is what we should rid ourselves of.
Lazlo,
This sounds like the right direction to me.

My 2C,
Simo.

Are NetworkPkg maintainers open to breaking RFC 7143 conformance in
IScsiDxe (perhaps with a feature PCD?), or should we look into this
only downstream?

Downstream, we might decide to drop IScsiDxe altogether, in sync
with the upstream NETWORK_ISCSI_ENABLE=FALSE default -- that
decision has not been made yet. Now I'm just testing whether keeping
IScsiDxe enabled down-stream would require us to carry downstream-
only patches.
Thanks
Laszlo
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc







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] Documents under RedfishPkg

Michael D Kinney
 

Hi Abner,

PlantUML is a way to embed some graphics in GitHub markdown text. Avoids checking in SVG or BMP or PNG binaries.

https://plantuml.com/

https://plantuml.com/en/guide


Here is an example of using PlatUML from a Wiki page with the PlantUML source text file also checked in.

https://github.com/tianocore-docs/edk2-TemplateSpecification/wiki/TianoCore-Documents-GitBook-Overview#introduction

GitHub Markdown source line that uses PlantUML server to convert PlantUML source to a SVG when the page is viewed.

![GitBookOverview](http://www.plantuml.com/plantuml/proxy?src=https://raw.githubusercontent.com/wiki/tianocore-docs/edk2-TemplateSpecification/plantuml/GitBookOverview.puml)

PlantUML source file

https://raw.githubusercontent.com/wiki/tianocore-docs/edk2-TemplateSpecification/plantuml/GitBookOverview.puml


Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Tuesday, April 6, 2021 7:06 AM
To: rfc@edk2.groups.io; abner.chang@...
Subject: Re: [edk2-rfc] [RFC] Documents under RedfishPkg

On 03/26/21 16:42, Abner Chang wrote:
Hi edk2 Stewards,
Is that ok to put some EDK2 Redfish port guide or design block diagrams in a folder under RedfishPkg? e.g.
RedfishPkg/Documents?
Any practices we have on the current edk2 repo?
If you can add the documents in some text-based representation (markup
or plaintext), where "reviewing patches" will make sense in the future,
then I welcome adding the documentation under RedfishPkg.

(If you have diagrams, I think SVG might be good for those.)

Other packages have introduced porting and other accompanying
documentation in the wiki, but I find that inferior. I don't like it
when documentation lives in a separate repository from the code that it
documents.

Thanks
Laszlo





Re: [edk2-devel] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Michael D Kinney
 

Hi Rebecca,

Thank you for the reminder. I have entered a BZ and sent a patch for review

https://bugzilla.tianocore.org/show_bug.cgi?id=3301

https://edk2.groups.io/g/devel/message/73744

Mike

-----Original Message-----
From: Rebecca Cran <rebecca@...>
Sent: Sunday, February 14, 2021 4:43 PM
To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; rfc@edk2.groups.io; 'Bret Barkelew'
<Bret.Barkelew@...>; Laszlo Ersek <lersek@...>; Gao, Liming <liming.gao@...>
Subject: Re: [edk2-devel] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

On 12/19/20 11:58 AM, Michael D Kinney wrote:
Hello,

There have been a few suggestions to create a mirror of cmocka in TianoCore
org in GitHub.

I have found a GitHub action that can do a repo sync.

https://github.com/marketplace/actions/github-repo-sync

I have created a temporary mirror of cmocka in my personal GitHub area that
uses this GitHub action to sync all branches and all tags once a day.

https://github.com/mdkinney/mirror-cmocka

Here is the GitHub workflow file. It must be in the default branch for the
repo using a branch name that is not present in the repo being mirrored.
In this case, I used a branch name of 'repo-sync'.

https://github.com/mdkinney/mirror-cmocka/blob/repo-sync/.github/workflows/repo-sync.yml

Please provide feedback on this approach. If we like this approach, then
I suggest we create a new repo in TianoCore called edk2-cmocka that is a
mirror that is synced once a day and we update the cmocka submodule in the
edk2 repo to use edk2-cmocka.
I just noticed this never got committed:
https://github.com/tianocore/edk2/blob/master/.gitmodules still shows
the old URL.

--
Rebecca Cran


Re: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

Bret Barkelew <bret.barkelew@...>
 

Let me see what I can find…

- Bret

From: Rabeda, Maciej<mailto:maciej.rabeda@...>
Sent: Tuesday, April 6, 2021 3:37 AM
To: Daniel P. Berrangé<mailto:berrange@...>
Cc: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@...>; simo@...<mailto:simo@...>; Laszlo Ersek<mailto:lersek@...>; Wu, Jiaxin<mailto:jiaxin.wu@...>; Fu, Siyuan<mailto:siyuan.fu@...>; Yash Mankad<mailto:ymankad@...>; Pete Batard<mailto:pete@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Sean Brogan<mailto:sean.brogan@...>; Jose Barreto<mailto:Jose.Barreto@...>
Subject: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

+Bret, Sean, Jose

Hi Sean, Bret,

In one of previous threads, Jose wrote that he pointed you to a
Microsoft person who should have more information on iSCSI on Windows.
I am wondering whether Windows iSCSI initiator supports CHAP hash
algorithms other than MD5.
Any chance we could reach out to that person and find it out?

Thanks,
Maciej

On 01-Apr-21 16:45, Daniel P. Berrangé wrote:
On Thu, Apr 01, 2021 at 04:24:27PM +0200, Rabeda, Maciej wrote:
Hi,

Sorry for the very late response.

Dropping iSCSI overall is a no-go - too many users + this is the only remote
block I/O we seem to support in EDKII.
As for RFC compliance vs EDKII policy on MD5... Naturally, CHAP with MD5
does not bring any security features due to MD5's vulnerability.
However, since MD5 is the only hash algorithm for CHAP supported by
IScsiDxe, removing MD5 implies removing CHAP-related code from IScsiDxe
overall, which I would be pretty hesitant to do.

RFC states that MD5 has to be supported, though I can see that CHAP
algorithm allows for different hash algorithms (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fppp-numbers%2Fppp-numbers.xhtml%23ppp-numbers-9&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7Cab8feb1e15994536427308d8f8e7ea2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637533022248147469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BlTgYNPfP3vJF7u6QcRLZvt8BobHpy7n3H%2B7tIqxLqo%3D&amp;reserved=0).
We could support CHAP with SHA-x in IScsiDxe, which removes the MD5
dependency and keeps the CHAP-related code in iSCSI still in place.

The question is: do OS-based initiators support hash algorithms other than
MD5 for CHAP?
I am pretty sure RHEL does (controlled via /etc/iscsi/iscsid.conf), but I am
not sure about others: Windows, VMware, ...
Linux kernel gained support for the SHA* family of hashes:

commit a572d24af4d16e70743feb0b4decb17aaae7ce43
Author: Maurizio Lombardi <mlombard@...>
Date: Mon Oct 28 13:38:20 2019 +0100

scsi: target: iscsi: CHAP: add support for SHA1, SHA256 and SHA3-256

This patch modifies the chap_server_compute_hash() function to make it
agnostic to the choice of hash algorithm that is used. It also adds
support to three new hash algorithms: SHA1, SHA256 and SHA3-256.

The chap_got_response() function has been removed because the digest type
validity is already checked by chap_server_open()

Link: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2F20191028123822.5864-2-mlombard%40redhat.com&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7Cab8feb1e15994536427308d8f8e7ea2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637533022248147469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZIUG2koYEF8gnAXpAQqIAEU0I2kS4F%2FFsGSMGPm7KxE%3D&amp;reserved=0
Signed-off-by: Maurizio Lombardi <mlombard@...>
Tested-by: Chris Leech <cleech@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>

NB SHA1 is just as undesirable as MD5 these days, so only the other two
are especially interesting/useful.

Regards,
Daniel


Re: [RFC] Documents under RedfishPkg

Laszlo Ersek
 

On 03/26/21 16:42, Abner Chang wrote:
Hi edk2 Stewards,
Is that ok to put some EDK2 Redfish port guide or design block diagrams in a folder under RedfishPkg? e.g. RedfishPkg/Documents?
Any practices we have on the current edk2 repo?
If you can add the documents in some text-based representation (markup
or plaintext), where "reviewing patches" will make sense in the future,
then I welcome adding the documentation under RedfishPkg.

(If you have diagrams, I think SVG might be good for those.)

Other packages have introduced porting and other accompanying
documentation in the wiki, but I find that inferior. I don't like it
when documentation lives in a separate repository from the code that it
documents.

Thanks
Laszlo


Re: removing CHAP-MD5 from IScsiDxe

Maciej Rabeda <maciej.rabeda@...>
 

+Bret, Sean, Jose

Hi Sean, Bret,

In one of previous threads, Jose wrote that he pointed you to a Microsoft person who should have more information on iSCSI on Windows.
I am wondering whether Windows iSCSI initiator supports CHAP hash algorithms other than MD5.
Any chance we could reach out to that person and find it out?

Thanks,
Maciej

On 01-Apr-21 16:45, Daniel P. Berrangé wrote:
On Thu, Apr 01, 2021 at 04:24:27PM +0200, Rabeda, Maciej wrote:
Hi,

Sorry for the very late response.

Dropping iSCSI overall is a no-go - too many users + this is the only remote
block I/O we seem to support in EDKII.
As for RFC compliance vs EDKII policy on MD5... Naturally, CHAP with MD5
does not bring any security features due to MD5's vulnerability.
However, since MD5 is the only hash algorithm for CHAP supported by
IScsiDxe, removing MD5 implies removing CHAP-related code from IScsiDxe
overall, which I would be pretty hesitant to do.

RFC states that MD5 has to be supported, though I can see that CHAP
algorithm allows for different hash algorithms (https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9).
We could support CHAP with SHA-x in IScsiDxe, which removes the MD5
dependency and keeps the CHAP-related code in iSCSI still in place.

The question is: do OS-based initiators support hash algorithms other than
MD5 for CHAP?
I am pretty sure RHEL does (controlled via /etc/iscsi/iscsid.conf), but I am
not sure about others: Windows, VMware, ...
Linux kernel gained support for the SHA* family of hashes:

commit a572d24af4d16e70743feb0b4decb17aaae7ce43
Author: Maurizio Lombardi <mlombard@...>
Date: Mon Oct 28 13:38:20 2019 +0100

scsi: target: iscsi: CHAP: add support for SHA1, SHA256 and SHA3-256
This patch modifies the chap_server_compute_hash() function to make it
agnostic to the choice of hash algorithm that is used. It also adds
support to three new hash algorithms: SHA1, SHA256 and SHA3-256.
The chap_got_response() function has been removed because the digest type
validity is already checked by chap_server_open()
Link: https://lore.kernel.org/r/20191028123822.5864-2-mlombard@redhat.com
Signed-off-by: Maurizio Lombardi <mlombard@...>
Tested-by: Chris Leech <cleech@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>

NB SHA1 is just as undesirable as MD5 these days, so only the other two
are especially interesting/useful.

Regards,
Daniel


Re: removing CHAP-MD5 from IScsiDxe

Daniel P. Berrangé <berrange@...>
 

On Thu, Apr 01, 2021 at 04:24:27PM +0200, Rabeda, Maciej wrote:
Hi,

Sorry for the very late response.

Dropping iSCSI overall is a no-go - too many users + this is the only remote
block I/O we seem to support in EDKII.
As for RFC compliance vs EDKII policy on MD5... Naturally, CHAP with MD5
does not bring any security features due to MD5's vulnerability.
However, since MD5 is the only hash algorithm for CHAP supported by
IScsiDxe, removing MD5 implies removing CHAP-related code from IScsiDxe
overall, which I would be pretty hesitant to do.

RFC states that MD5 has to be supported, though I can see that CHAP
algorithm allows for different hash algorithms (https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9).
We could support CHAP with SHA-x in IScsiDxe, which removes the MD5
dependency and keeps the CHAP-related code in iSCSI still in place.

The question is: do OS-based initiators support hash algorithms other than
MD5 for CHAP?
I am pretty sure RHEL does (controlled via /etc/iscsi/iscsid.conf), but I am
not sure about others: Windows, VMware, ...
Linux kernel gained support for the SHA* family of hashes:

commit a572d24af4d16e70743feb0b4decb17aaae7ce43
Author: Maurizio Lombardi <mlombard@...>
Date: Mon Oct 28 13:38:20 2019 +0100

scsi: target: iscsi: CHAP: add support for SHA1, SHA256 and SHA3-256

This patch modifies the chap_server_compute_hash() function to make it
agnostic to the choice of hash algorithm that is used. It also adds
support to three new hash algorithms: SHA1, SHA256 and SHA3-256.

The chap_got_response() function has been removed because the digest type
validity is already checked by chap_server_open()

Link: https://lore.kernel.org/r/20191028123822.5864-2-mlombard@redhat.com
Signed-off-by: Maurizio Lombardi <mlombard@...>
Tested-by: Chris Leech <cleech@...>
Signed-off-by: Martin K. Petersen <martin.petersen@...>

NB SHA1 is just as undesirable as MD5 these days, so only the other two
are especially interesting/useful.

Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|


Re: removing CHAP-MD5 from IScsiDxe

Maciej Rabeda <maciej.rabeda@...>
 

Hi,

Sorry for the very late response.

Dropping iSCSI overall is a no-go - too many users + this is the only remote block I/O we seem to support in EDKII.
As for RFC compliance vs EDKII policy on MD5... Naturally, CHAP with MD5 does not bring any security features due to MD5's vulnerability.
However, since MD5 is the only hash algorithm for CHAP supported by IScsiDxe, removing MD5 implies removing CHAP-related code from IScsiDxe overall, which I would be pretty hesitant to do.

RFC states that MD5 has to be supported, though I can see that CHAP algorithm allows for different hash algorithms (https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9).
We could support CHAP with SHA-x in IScsiDxe, which removes the MD5 dependency and keeps the CHAP-related code in iSCSI still in place.

The question is: do OS-based initiators support hash algorithms other than MD5 for CHAP?
I am pretty sure RHEL does (controlled via /etc/iscsi/iscsid.conf), but I am not sure about others: Windows, VMware, ...

Thanks,
Maciej

On 19-Mar-21 18:39, Desimone, Nathaniel L wrote:
I'm honestly surprised that the iSCSI RFC has not been updated to drop CHAP-MD5 at this point. I realize that is probably a bigger effort but it seems like something the industry should do. I agree that having a FeaturePcd for CHAP MD5 and having it default to False is probably the right thing to do.

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Samer El-Haj-
Mahmoud
Sent: Friday, March 19, 2021 10:08 AM
To: rfc@edk2.groups.io; simo@...; Laszlo Ersek
<lersek@...>
Cc: Maciej Rabeda <maciej.rabeda@...>; Wu, Jiaxin
<jiaxin.wu@...>; Fu, Siyuan <siyuan.fu@...>; Daniel P.
Berrangé <berrange@...>; Yash Mankad <ymankad@...>;
Pete Batard <pete@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
Subject: Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

When the RPi UEFI FW dropped iSCSI (because it was removed from
NetworkDefines.dsc.inc), we got multiple users complaining since they had
existing use cases that depended on that. See for instance the RPi4 UEFI
reported bug: https://github.com/pftf/RPi4/issues/125

Some use-cases and user scenarios for iSCSI on RPi4:
https://blogs.vmware.com/arm/2020/10/17/esxi-arm-with-iscsi/
https://tech.xlab.si/blog/pxe-boot-raspberry-pi-iscsi/
https://www.virtuallyghetto.com/2020/07/two-methods-to-network-boot-
raspberry-pi-4.html

The RPi4 users preferred having iSCSI (without CHAP) than not having it at all.
We resorted to enabling it out-of-tree using a build switch.

From my experience, I think the EDK2 iScsiDxe software initiator is being
wildly used on many servers (and OSes) across the industry (just google
"UEFI iSCSI"). Having it silently dropped from EDK2 is not optimal. I like
Laszlo's idea of a PCD to break the RFC (and using an iSCSI boot variant that
does not support CHAP), and I think it is a good compromise. The alternative
is for downstream implementations to resort to enabling it (probably just set
NETWORK_ISCSI_ENABLE=TRUE) to keep their users happy.

Thanks,
--Samer

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Simo Sorce
via groups.io
Sent: Friday, March 19, 2021 9:26 AM
To: Laszlo Ersek <lersek@...>; edk2-rfc-groups-io
<rfc@edk2.groups.io>
Cc: Maciej Rabeda <maciej.rabeda@...>; Jiaxin Wu
<jiaxin.wu@...>; Siyuan Fu <siyuan.fu@...>; Daniel P.
Berrangé <berrange@...>; Yash Mankad
<ymankad@...>
Subject: Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

On Fri, 2021-03-19 at 14:15 +0100, Laszlo Ersek wrote:
Hi,

RFC 7143 requires CHAP-MD5 as a mandatory option offered by an iscsi
client (initiator).

At the same time, edk2 has deprecated MD5 in general, as a
cryptographically weak hash algorithm.

Consequently, the "NetworkDefines.dsc.inc" file defines
NETWORK_ISCSI_ENABLE with default value FALSE (commit
4ecb1ba5efa3 /
TianoCore#3003). Platforms that want to include IScsiDxe need to opt
in consciously to the presence of CHAP-MD5 in the code.

We're not happy with this granularity. We'd prefer:

- explicitly breaking RFC 7143 conformance,
- removing CHAP-MD5,
- and using an IScsiDxe variant that is honest about having no
confidentiality / integrity.

IScsiDxe is safe on a trusted network, and only on a trusted network.
The presence of CHAP-MD5 suggests it may be safe on an untrusted
network too, and that implication (not the whole iscsi client
functionality) is what we should rid ourselves of.
Lazlo,
This sounds like the right direction to me.

My 2C,
Simo.

Are NetworkPkg maintainers open to breaking RFC 7143 conformance in
IScsiDxe (perhaps with a feature PCD?), or should we look into this
only downstream?

Downstream, we might decide to drop IScsiDxe altogether, in sync
with the upstream NETWORK_ISCSI_ENABLE=FALSE default -- that
decision has not been made yet. Now I'm just testing whether keeping
IScsiDxe enabled down-stream would require us to carry downstream-
only patches.
Thanks
Laszlo
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc







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.



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

gaoliming
 

Nickle:

-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Nickle Wang
发送时间: 2021年3月26日 12:05
收件人: rfc@edk2.groups.io; gaoliming@...; lersek@...
抄送: 'Dandan Bi' <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Wang, Nickle (HPS SW)
<nickle.wang@...>
主题: 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 <rfc@edk2.groups.io> On Behalf Of gaoliming
Sent: Friday, March 26, 2021 9:51 AM
To: Wang, Nickle (HPS SW) <nickle.wang@...>; rfc@edk2.groups.io;
lersek@...
Cc: 'Dandan Bi' <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey
support

Nickle:

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


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



-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Laszlo
Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io; nickle.wang@...
抄送: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
主题: 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-Driver-
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























[RFC] Documents under RedfishPkg

Abner Chang
 

Hi edk2 Stewards,
Is that ok to put some EDK2 Redfish port guide or design block diagrams in a folder under RedfishPkg? e.g. RedfishPkg/Documents?
Any practices we have on the current edk2 repo?
Thanks
Abner


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

Nickle Wang
 

Thanks for your feedback, Liming. Please see my comment below.

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

Nickle:

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


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



-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Laszlo Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io; nickle.wang@...
抄送: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
主题: 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-Driver-
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

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.

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.

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.

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:

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


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



-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Laszlo Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io; nickle.wang@...
抄送: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
主题: 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-Driver-
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.
2. Browser may have the different Hotkey. UEFI driver doesn't know to disable which Hotkey.

In fact, UEFI spec defines HII ConfigAccess protocol for data read and write. HII driver should follow this way.
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.

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

Nickle Wang
 

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



-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Laszlo Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io; nickle.wang@...
抄送: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
主题: 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-Driver-
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.

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

Laszlo Ersek
 

On 03/25/21 04:26, Wang, Nickle (HPS SW) wrote:
Thanks for your feedback, Laszlo. I like the idea to support hotkey
from VFR level. However, I checked the UEFI driver writer guide and I
do not see anything about HII hotkey.

In terms of hotkey support from VFR, the efforts may be bigger than
doing it from EDK2 protocol. VFR file is compiled into IFR Opcodes
and IFR Opcodes are defined in UEFI specification. That means we have
to update UEFI specification to support HII hotkey. This also
includes the changes to VFR compiler, EDK2 setup browser driver and
all other codes that will parse IFR opcodes. I am not sure if it is
worth doing this.
Sure, I'm not pushing for that; just if it were possible with VFR out of
the box, it would be a good choice.

Thanks
Laszlo


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

gaoliming
 

-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Laszlo Ersek
发送时间: 2021年3月24日 19:37
收件人: rfc@edk2.groups.io; nickle.wang@...
抄送: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
主题: 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-Driver-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.

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

Nickle Wang
 

Thanks for your feedback, Laszlo. I like the idea to support hotkey from VFR level. However, I checked the UEFI driver writer guide and I do not see anything about HII hotkey.

In terms of hotkey support from VFR, the efforts may be bigger than doing it from EDK2 protocol. VFR file is compiled into IFR Opcodes and IFR Opcodes are defined in UEFI specification. That means we have to update UEFI specification to support HII hotkey. This also includes the changes to VFR compiler, EDK2 setup browser driver and all other codes that will parse IFR opcodes. I am not sure if it is worth doing this.

Thanks,
Nickle

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, March 24, 2021 7:37 PM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@...>
Cc: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: 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.

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

Laszlo Ersek
 

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.

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





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

Nickle Wang
 

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.

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

201 - 220 of 793