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

Hi Amol, With regard to verifying code hashes, it makes much more sense to me to have a GUID defined that represents the hash function to use versus a PCD. The reason for this is the method for

Hello, Currently the UEFI drivers using the SHA/SM3 hashing algorithms use hard-coded API to calculate the hash, such as, sha_256(...), etc. Since SHA384 and/or SM3 are being increasingly adopted, it

Hi Ethin I think you have entered the community after the code was sent at this discussion. Attached the latest code we have received from Andrew. Not sure if this is really the latest version, but

This is incredible progress! I'd love to help where I can when you release the src. -- Signed, Ethin D. Probst

Ethin, I've made progress using the EmulatorPkg. I've ported my test C command line application into the EmulatorPkg Host (OS C command line application part of the EmulatorPkg), so the the host now

Hi Ethin I think you can start by studying the EmulatorPkg at the edk2 repository. Try to compile and use it, and after that you could try the software developed by Andrew to check if it works

Has there been any progress on this? I wish I could help, but I have no experience in developing for EDK2... -- Signed, Ethin D. Probst

Thanks. Can you please write a QEMU patch for the ACPI generator such that hotplugging a VCPU writes value 4 to IO port 0xB2? That will allow me to experiment with OVMF. (I can experiment with some

Rebecca, I have not setup or integrated a Doxygen build as part of this. I think that is something that should happen and it should be done by a cloud build on a regular cadence but is independent

"Laszlo Ersek" <lersek@...> wrote: yep, you can use it to iterate over hotplugged CPUs. hw side (QEMU) uses cpu_hotplug_ops as IO write/read handlers and firmware side (ACPI) scannig for

Do you have a location set up for where you'll publish the results of the Doxygen builds? -- Rebecca Cran