Hi Bret, I am looking at the latest version of the content on your branch. I am confused by MdePkg/Test/MdePkgTest.dsc. It makes references to lib classes and packages that do not exist.

No problem for me. Thank you Yao Jiewen Sent: Tuesday, December 17, 2019 5:28 AM To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; bret.barkelew@...; Andrew Fish

Hi Jiewen, Many of your responses are related to fuzz testing. Can we focus current infrastructure on host based unit testing and minimizing the content to support that testing type. Then, add a

Answer the question 5,6,7,8, which are related to HBFA. For other MSFT unit test, I don't have strong opinion. I am OK with that. Thank you Yao Jiewen Sent: Saturday, December 14, 2019 8:47 AM To:

The host-based tests now build on Linux/GCC, but the final executables don’t seem to get created. Don’t know where the disconnect is there. I can see the test get compiled (along with all the

Mike, I think I’ve gotten all the feedback here and all the action items from our call. The current branch should be good to go, minus the couple of things that Intel was going to look

1. I see that MdePkg adds a dependency on UnitTestPkg. This makes UnitTestPkg the root package when building and running host based unit tests. This makes sense, but good to highlight that all

Andrew, I agree with your points. Mike, You’ve got a lot more there. Let me take a look and update the draft. I’ll ping back ASAP. - Bret Sent: Wednesday, December 4, 2019 9:50 AM To:

Mike, I like and agree with your comments. On the UnitTestPkg(s) dependency issue I think it would make sense to move as much as possible into the *Pkg/Test/ ( *Pkg/HostLibrary,

Hi Bret, Thanks for posting this content. Host based unit testing is a very valuable addition to the CI checks. I have the following comments: 1. I see that MdePkg adds a dependency on

No objection from me. Thank you for managing the SFF / HFF process, and the release, again, Liming! Laszlo

Hi, all Today, I review all patches in edk2 mail list. There is no patches for EDK II Stable Tag edk2-stable201911. Based on edk2-stable201911 tag planning, it will be released at 2019-11-29. So, I

Hi Mike, I think the point # 2 you are making is also the implementation we have proposed. Also, if we can have a two tier approach then we may be in a position to improve code flexibility: 1.

As Sean points out, different components in a platform may have different hash requirements. If we want to go down the path where we have a few modules that produce Protocols/PPIs for the

Hi Sean and Amol, I believe the OBB and FV/PE image verification can still benefit from the unified API, if we add one more parameter to HashApiIinit() to force using a hash algorithm or add a PCD to

Hi Sean, A few examples that we want to target are - HDD Password verification - Capsule Verification (Platform recovery) - Bios Guard Platform Data Table - More importantly, Boot Guard Event Log

Amol, I am interested to hear more about the actual use cases. I like the idea of abstracting the API so that a calling driver doesn't have to change when the hashing algorithm requirements change

Hi Mike and Nate, With our implementation we are trying to address the following in EDKII: 1. A common Hashing API for UEFI drivers to consume instead of the current API that directly calls into the

Thanks, Nate and Mike! I am going through the code and comments and will respond shortly. In the meantime, here is the GitHub link to my PoC for the community to look at and comment:

Nate and Amol, There is some work already started by Sean and Matt that implements a PEIM, DXE Driver, and SMM Driver to produce Protocol/PPI that wraps the BaseCryptLib services. This content