Date   

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

Rebecca Cran <rebecca@...>
 

Thanks. Yes, I'll work on implementing the RngLib|RNDR part.
I'll be using Qemu's sbsa-ref platform for testing. I'll also look into using the FVP_Base_AEMv8A-AEMv8A too.

--
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

Sunny Wang
 

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?

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?

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.


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

Min Xu <min.m.xu@...>
 

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.


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

Laszlo Ersek
 

On 04/26/21 10:14, 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?

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?
In discussions where I've been present over the last several years, such
a tool has been brought up several times. I always resist the idea.
Here's why:

- Such a host-side program needs to duplicate the functionality of three
firmware drivers, composed. Namely: the low-level flash driver (which
includes flash size / location / structure), the FTW driver, and the
variable driver. It's a double maintenance nightmare. Of course if
someone other than myself is willing to maintain the python tool in
parallel to the edk2 drivers proper, then please be my guest.

- The expectation is usually "let me tweak the varstore at any point,
from the host side, not just for initial enrollment". That means the
tool may face a variable store that is not "clean". For example, power
loss during variable update. The FTW driver deals with this within the
firmware, but the same kind of journaling / rollback / spare area
handling / reclaim etc etc would have to be implemented in the host side
utility. Nah.

Thanks
Laszlo


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.


Re: removing CHAP-MD5 from IScsiDxe

Laszlo Ersek
 

On 04/23/21 16:41, Rabeda, Maciej wrote:
Hi Laszlo,

Based on the responses from Andrei and Bret (thanks!), MD5 should stay
as a supported option in IScsiDxe.
I do understand that having a table with hash algorithms in IscsiDxe is
a potential duplicate with Hash2DxeCrypto, but since Hash2DxeCrypto does
not serve our purpose (no MD5 + extra driver required in the platform),
I see no better way to go.
We will have to wash down the distaste of this solution with an adequate
amount of hoppy beverage :)
Thanks!
Laszlo


Re: removing CHAP-MD5 from IScsiDxe

Maciej Rabeda <maciej.rabeda@...>
 

Hi Laszlo,

Based on the responses from Andrei and Bret (thanks!), MD5 should stay as a supported option in IScsiDxe.
I do understand that having a table with hash algorithms in IscsiDxe is a potential duplicate with Hash2DxeCrypto, but since Hash2DxeCrypto does not serve our purpose (no MD5 + extra driver required in the platform), I see no better way to go.
We will have to wash down the distaste of this solution with an adequate amount of hoppy beverage :)

Thanks,
Maciej

On 13-Apr-21 11:37, Laszlo Ersek wrote:
On 04/12/21 14:36, Rabeda, Maciej wrote:
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?
Considering the origin of the idea, it comes from the Red Hat crypto
team, with regard to edk2 virtual firmware included RHEL9. So the origin
is as local as it gets. In turn, in order to avoid downstream-only
patches as much as possible ("upstream first"), we're trying to make
this change in upstream edk2, considering especially that MD5 has been
removed already from other parts of edk2. Taking it as far as UEFI spec
changes or iSCSI RFC changes, that's a bit too much for me, given the
huge delays and red tape it would mean.

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.
Unfortunately, this is not something I can act on. "Consensus between
iSCSI target providers" is not tangible. People in that loosely defined
set don't care about this mailing list, so this is the same as the
standardization path (USWG and/or IETF (RFC)), which is a black hole.

The alternative, MD5 opt-out, is technically doable, but the *least
ugly* option for that, namely duplicating the "mHashInfo" table from
"SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c", is *still* frickin' ugly.
I'm OK to do it, but I'd like you to confirm that you're OK with it.

Can you please advise so that I can start writing code?

Thanks
Laszlo

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@redhat.com; Laszlo Ersek
<lersek@redhat.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>; Wu, Jiaxin
<jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Daniel P.
Berrangé <berrange@redhat.com>; Yash Mankad <ymankad@redhat.com>;
Pete Batard <pete@akeo.ie>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>
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@redhat.com>; edk2-rfc-groups-io
<rfc@edk2.groups.io>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>; Jiaxin Wu
<jiaxin.wu@intel.com>; Siyuan Fu <siyuan.fu@intel.com>; Daniel P.
Berrangé <berrange@redhat.com>; Yash Mankad
<ymankad@redhat.com>
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] Have new interface in EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle Wang
 

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: [edk2-devel] [RFC] Secure boot default key

Min Xu <min.m.xu@...>
 

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 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.


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

Sami Mujawar <sami.mujawar@...>
 

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

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 <rebecca@...>
 

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
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

Grzegorz Bernacki
 

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

Samer El-Haj-Mahmoud
 

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/vie
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.


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

Laszlo Ersek
 

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
 

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.

Thanks,
Laszlo


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

Grzegorz Bernacki
 

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

Please let me know, if you have an questions, comments or doubts.
thanks,
Greg


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

Nickle Wang
 

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-rfc] removing CHAP-MD5 from IScsiDxe

Bret Barkelew <bret.barkelew@...>
 

Agreed. The feedback I got from the MS team that owns iSCSI is:
“MSFT iSCSI initiator only supports CHAP MD5”

- Bret

From: Andrei Warkentin<mailto:awarkentin@vmware.com>
Sent: Tuesday, April 13, 2021 2:21 PM
To: Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@arm.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; Rabeda, Maciej<mailto:maciej.rabeda@linux.intel.com>; Daniel P. Berrangé<mailto:berrange@redhat.com>
Cc: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; simo@redhat.com<mailto:simo@redhat.com>; Laszlo Ersek<mailto:lersek@redhat.com>; Wu, Jiaxin<mailto:jiaxin.wu@intel.com>; Fu, Siyuan<mailto:siyuan.fu@intel.com>; Yash Mankad<mailto:ymankad@redhat.com>; Pete Batard<mailto:pete@akeo.ie>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Jose Barreto<mailto:Jose.Barreto@microsoft.com>
Subject: Re: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

Hi everyone,

We do seemingly only support CHAP-MD5 and would prefer that support to be kept in edk2.

A

From: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Sent: Tuesday, April 13, 2021 4:19 PM
To: Bret Barkelew <Bret.Barkelew@microsoft.com>; Rabeda, Maciej <maciej.rabeda@linux.intel.com>; Daniel P. Berrangé <berrange@redhat.com>
Cc: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; rfc@edk2.groups.io <rfc@edk2.groups.io>; simo@redhat.com <simo@redhat.com>; Laszlo Ersek <lersek@redhat.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Yash Mankad <ymankad@redhat.com>; Pete Batard <pete@akeo.ie>; Sean Brogan <sean.brogan@microsoft.com>; Jose Barreto <Jose.Barreto@microsoft.com>; Andrei Warkentin <awarkentin@vmware.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: RE: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe


+ Andrei for VMware ESXi feedback on the iSCSI CHAP support. I know that UEFI iSCSI boot is supported and used by those users.





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



Let me see what I can find…



- Bret



From: Rabeda, Maciej<mailto:maciej.rabeda@linux.intel.com>
Sent: Tuesday, April 6, 2021 3:37 AM
To: Daniel P. Berrangé<mailto:berrange@redhat.com>
Cc: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@arm.com>; simo@redhat.com<mailto:simo@redhat.com>; Laszlo Ersek<mailto:lersek@redhat.com>; Wu, Jiaxin<mailto:jiaxin.wu@intel.com>; Fu, Siyuan<mailto:siyuan.fu@intel.com>; Yash Mankad<mailto:ymankad@redhat.com>; Pete Batard<mailto:pete@akeo.ie>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Jose Barreto<mailto:Jose.Barreto@microsoft.com>
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<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%7C7abd2f5b10ea461b9a5708d8fec22180%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539457031505064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uDVGHH1nPw3r5xpu5XoZotABucpnXaBJ8EfFi8GTwAk%3D&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@redhat.com<mailto:mlombard@redhat.com>>
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<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%7C7abd2f5b10ea461b9a5708d8fec22180%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539457031515021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=humaChgJFRRu7rln0vDSyxzsaE5qSkfgsUWuGTR%2Bmz4%3D&reserved=0>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com<mailto:mlombard@redhat.com>>
Tested-by: Chris Leech <cleech@redhat.com<mailto:cleech@redhat.com>>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com<mailto:martin.petersen@oracle.com>>

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

Regards,
Daniel

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: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

Andrei Warkentin <awarkentin@...>
 

Hi everyone,

We do seemingly only support CHAP-MD5 and would prefer that support to be kept in edk2.

A
________________________________
From: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Sent: Tuesday, April 13, 2021 4:19 PM
To: Bret Barkelew <Bret.Barkelew@microsoft.com>; Rabeda, Maciej <maciej.rabeda@linux.intel.com>; Daniel P. Berrangé <berrange@redhat.com>
Cc: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; rfc@edk2.groups.io <rfc@edk2.groups.io>; simo@redhat.com <simo@redhat.com>; Laszlo Ersek <lersek@redhat.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Yash Mankad <ymankad@redhat.com>; Pete Batard <pete@akeo.ie>; Sean Brogan <sean.brogan@microsoft.com>; Jose Barreto <Jose.Barreto@microsoft.com>; Andrei Warkentin <awarkentin@vmware.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: RE: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe


+ Andrei for VMware ESXi feedback on the iSCSI CHAP support. I know that UEFI iSCSI boot is supported and used by those users.





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



Let me see what I can find…



- Bret



From: Rabeda, Maciej<mailto:maciej.rabeda@linux.intel.com>
Sent: Tuesday, April 6, 2021 3:37 AM
To: Daniel P. Berrangé<mailto:berrange@redhat.com>
Cc: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@arm.com>; simo@redhat.com<mailto:simo@redhat.com>; Laszlo Ersek<mailto:lersek@redhat.com>; Wu, Jiaxin<mailto:jiaxin.wu@intel.com>; Fu, Siyuan<mailto:siyuan.fu@intel.com>; Yash Mankad<mailto:ymankad@redhat.com>; Pete Batard<mailto:pete@akeo.ie>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Jose Barreto<mailto:Jose.Barreto@microsoft.com>
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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fppp-numbers%2Fppp-numbers.xhtml%23ppp-numbers-9&data=04%7C01%7Cawarkentin%40vmware.com%7C473c92002e324bbfc8e108d8fec1de08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637539455921496801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=INDo2VOjqTeA%2BKfI1uCaQ%2Bo%2BNslTFKiSYfgNmsG6yRI%3D&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@redhat.com<mailto:mlombard@redhat.com>>
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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2F20191028123822.5864-2-mlombard%40redhat.com&data=04%7C01%7Cawarkentin%40vmware.com%7C473c92002e324bbfc8e108d8fec1de08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637539455921496801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ZfdaQ5i39zXRcaPO%2BgH4I22XDg1hCDHoC1GKeIUZ6cg%3D&reserved=0>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com<mailto:mlombard@redhat.com>>
Tested-by: Chris Leech <cleech@redhat.com<mailto:cleech@redhat.com>>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com<mailto:martin.petersen@oracle.com>>

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

Regards,
Daniel


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: [EXTERNAL] Re: [edk2-rfc] removing CHAP-MD5 from IScsiDxe

Samer El-Haj-Mahmoud
 

+ Andrei for VMware ESXi feedback on the iSCSI CHAP support. I know that UEFI iSCSI boot is supported and used by those users.


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

Let me see what I can find...

- Bret

From: Rabeda, Maciej<mailto:maciej.rabeda@linux.intel.com>
Sent: Tuesday, April 6, 2021 3:37 AM
To: Daniel P. Berrangé<mailto:berrange@redhat.com>
Cc: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Samer El-Haj-Mahmoud<mailto:Samer.El-Haj-Mahmoud@arm.com>; simo@redhat.com<mailto:simo@redhat.com>; Laszlo Ersek<mailto:lersek@redhat.com>; Wu, Jiaxin<mailto:jiaxin.wu@intel.com>; Fu, Siyuan<mailto:siyuan.fu@intel.com>; Yash Mankad<mailto:ymankad@redhat.com>; Pete Batard<mailto:pete@akeo.ie>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Jose Barreto<mailto:Jose.Barreto@microsoft.com>
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@redhat.com<mailto:mlombard@redhat.com>>
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@redhat.com<mailto:mlombard@redhat.com>>
Tested-by: Chris Leech <cleech@redhat.com<mailto:cleech@redhat.com>>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com<mailto:martin.petersen@oracle.com>>

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

Regards,
Daniel
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: removing CHAP-MD5 from IScsiDxe

Laszlo Ersek
 

On 04/12/21 14:36, Rabeda, Maciej wrote:
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?
Considering the origin of the idea, it comes from the Red Hat crypto
team, with regard to edk2 virtual firmware included RHEL9. So the origin
is as local as it gets. In turn, in order to avoid downstream-only
patches as much as possible ("upstream first"), we're trying to make
this change in upstream edk2, considering especially that MD5 has been
removed already from other parts of edk2. Taking it as far as UEFI spec
changes or iSCSI RFC changes, that's a bit too much for me, given the
huge delays and red tape it would mean.

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.
Unfortunately, this is not something I can act on. "Consensus between
iSCSI target providers" is not tangible. People in that loosely defined
set don't care about this mailing list, so this is the same as the
standardization path (USWG and/or IETF (RFC)), which is a black hole.

The alternative, MD5 opt-out, is technically doable, but the *least
ugly* option for that, namely duplicating the "mHashInfo" table from
"SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c", is *still* frickin' ugly.
I'm OK to do it, but I'd like you to confirm that you're OK with it.

Can you please advise so that I can start writing code?

Thanks
Laszlo


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@redhat.com; Laszlo Ersek
<lersek@redhat.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>; Wu, Jiaxin
<jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Daniel P.
Berrangé <berrange@redhat.com>; Yash Mankad <ymankad@redhat.com>;
Pete Batard <pete@akeo.ie>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>
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@redhat.com>; edk2-rfc-groups-io
<rfc@edk2.groups.io>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>; Jiaxin Wu
<jiaxin.wu@intel.com>; Siyuan Fu <siyuan.fu@intel.com>; Daniel P.
Berrangé <berrange@redhat.com>; Yash Mankad
<ymankad@redhat.com>
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.






141 - 160 of 753