On Sat, Aug 1, 2020 at 03:47 PM, Laszlo Ersek wrote: On 08/01/20 00:19, Artem Shchygel wrote:> Hi, All>> In this RFC we're proposing slight changes to Git commit message format tomake it more

Hints are very welcome, but not in subject lines. Please use Name: value Name: value # comment style tags near the end of the commit messages instead. Subject lines are primarily for human

Hi, All In this RFC we're proposing slight changes to Git commit message format to make it more informative and more friendly for automation tools. Here is the list of changes proposed Start subject

Hi Sean, The binary to be signed is a blob of data to be consumed by BIOS. In the example mentioned the signed blob is packaged in an FV, but the solution should be flexible to work with other

Thanks for the info. I would like to break my continued comments into two distinct parts. 1. Still interested in why we need new abstractions for the data blob. From your use case i would suggest

Hi Ethin Unfortunately I didn't have a chance to continue this work on the last months. Code sample can be found here: https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility At YouTube

Hi Divneil, Good News, thanks for your update.

Hello all, Raising this from (the seeming) silence it's been in since the 30th of Oct. of 2019. What is the status on this? Also, is there a bit of source code you guys can share with me for

Hi Guomin, I have moved forward from the last discussion, and the tools work okay for RSA2048/SHA256. Once I have the next update, I will notify it here. Regards, Divneil

Well as far as I'm concerned it's a simple rule. If a structure is serialized from RAM into a disk file, or to the network, then the structure should be packed. If it's only exchanged in RAM, on a

Curtis, Not sure I fully follow your proposal. Can you provide more on the use case? Is the "blob" a FV or is the signed_sub_region a raw section in a ffs file? or something else like binary at

Thanks for the link.  I agree that this change will make the StatusCodeHandler driver more modular, and is a step in the right direction. But I think it could go further, with almost no additional

Hi Laszlo, Please see my comments below. Thanks, Amol

Hi Brian, In this new design, we still use register status code handler Protocol/Ppi to register the handler logic. We just want to change the StatusCodeHandler driver. We try to split the register

Hi, I don't have a stake in this feature, but because the presentation isn't long, I've briefly skimmed it: - It's unclear whether the public data structures describe a wire format. If they do, they

Dandan, The Status Code Protocol/PPI is the high-level interface which is being implemented.  The ReportStatusCodeRouter module implements this in terms of the ReportStatusCodeHandler

Friendly reminder to review and provide feedback on the RFC. We are looking to target a WW34 deadline with this design. Best, Curtis

Hi, I filed a proposal for a new library to handle UEFI BIOS sub-regions athttps://bugzilla.tianocore.org/show_bug.cgi?id=2808. Attached is a slide deck with design overview of the new library.

Hi Sahil, Your proposal interests us too. I got a question for you. Are you planning to use or leverage SPCI library interfaces for interaction between OP-TEE and Standalone MM?

Hm... OK. Thanks Laszlo