Date   

TianoCore Community Design Meeting Minutes - Apr 3, 2020

Ni, Ray
 

Topic:

  1. EDK2 Redfish Implementation Review (Directory/File Structure)

Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0403/EDK2%20Redfish%20Implementation%20Review.pdf

  • RedfishPkg

    • /IndustryStandard: Industry standard definitions should be in MdePkg.
    • /Protocol: UEFI/PI protocols should be in MdePkg

    @Felix: A general guideline is don't use EFI_ prefix if a protocol is not defined in UEFI/PI spec.

    @Ray: For protocols planned to be in UEFI/PI spec, encourage to use code first process (https://edk2.groups.io/g/devel/topic/72500372).

    • /Pcd: Looks good

    UINTN to UINT32 change is good to Siyuan/Jiaxin/Fan.

    @Ray: Suggest to submit a bugzilla for structure pcd tool issue.

  • EmulatorPkg

    • /Application/RedfishPlatformConfig: Location looks good.
    • /Library
    • RedfishPlatformHostInterfaceLib: platform specific lib consuming variables created by /Application/RedfishPlatformConfig. Location looks good.
    • RedfishPlatformCredentialLib: Location looks good.
    • WinSnp
    • New PCD PcdEmuNetworkInterface to select network interface by index.

    @Siyuan: Suggest to use existing PCD by put the index integer in string format.

  • NetworkPkg: NETWORK_HTTP_BOOT_ENABLE macro

Do not include HttpDxe driver when NETWORK_HTTP_BOOT_ENABLE is FALSE to hide HTTP boot option from boot option list.

@igork: SMBIOS 42 contains field pointing to URL so please include DnsDxe driver even when NETWORK_HTTP_BOOT_ENABLE is FALSE.

@Abner: Will evaluate today's RedfishPlatformHostInterfaceLib to support IP address and URL.

@Felix: Can you put RestEx driver in NetworkPkg because RestEx does not only support Redfish stack.


TianoCore Community Meeting Minutes - April

Soumya Guptha
 

TianoCore Community Meeting Minutes

April 2, 2020





Events (Soumya Guptha):

Spring 2020 UEFI PLUGFEST<https://uefi.org/Spring2020Plugfest> has been cancelled due to the Coronavirus. More details are published here - https://uefi.org/events/upcoming

We are exploring to do a virtual meeting for the Tianocore Community members to discuss on TianoCore topics.

Please send if you have any topics to contribute or hear to Soumya Guptha (soumya.k.guptha@...<mailto:soumya.k.guptha@...>) by April 17th.

Soumya will communicate further on virtual meeting details.



Stable Tag Updates (Soumya Guptha/Liming Gao):

1. Edk2 stable tag 202005 feature development in progress. Features are listed in: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning

Community Action: Please send if any feature requests that needs to be added to the next stable tag release.


Features Completed:

* ArmVirtPkg Implement support for TPM2 measured boot<https://bugzilla.tianocore.org/show_bug.cgi?id=2560>
* OVMF Implement support for Linux v5.7+ initrd and mixed mode loading<https://bugzilla.tianocore.org/show_bug.cgi?id=2564>
* OVMF Use loadimage/startimage for loading the kernel passed via the QEMU command line<https://bugzilla.tianocore.org/show_bug.cgi?id=2566>
* OVMF Support booting from Fusion-MPT SCSI controllers<https://bugzilla.tianocore.org/show_bug.cgi?id=2390>
* OVMF Support booting from VMware PVSCSI controllers<https://bugzilla.tianocore.org/show_bug.cgi?id=2567>
* OVMF RFE: VCPU hotplug with SMM<https://bugzilla.tianocore.org/show_bug.cgi?id=1512>
Features In Progress:

* RegularExpressionDxe: Use submodule way to access third party Oniguruma<https://bugzilla.tianocore.org/show_bug.cgi?id=2073>
* BrotliCustomDecompressLib: Use submodule way to access third party brotli<https://bugzilla.tianocore.org/show_bug.cgi?id=2559>
* BaseTools: Use submodule way to access third party brotli<https://bugzilla.tianocore.org/show_bug.cgi?id=2558>
* Add support RISC-V arch platforms<https://bugzilla.tianocore.org/show_bug.cgi?id=2532>
* Ensure NV Variable Confidentiality and Integrity for Platforms Supporting RPMC<https://bugzilla.tianocore.org/show_bug.cgi?id=2594>

Stewards Meeting download (Mike Kinney)

1) Issues with Mergify service. Pass CI and Mergify service. Waiting the result. See this issue, and ask Admin to refresh operation. Continue to monitor open CI.

2) Code First Process (Leif started in the mailing list and got some feedback from the community) . Need approval from the community, then can follow the process. Use Edk2 staging branch for code development, validation, and spec ECR. Document this process in wiki page for the developer reference.

3) Evaluation of code review process moving to github. Github web UI for code review, and email archive for community. Agreement to the stable and reliable service of Github Pull service. RFC will include the test repo for user evaluation.

4) Line ending conversion. Dos line ending --> Linux line ending. Local setting enables auto conversion based on Windows OS. Linux line ending is the standard git defaulting.





AR review from March:

1. Sean requested a few features (variable policy, TLS 1.3 etc.) for stable tag Q2 release. Sean will follow up with Liming on those features to get them added to Q2 stable tag.

* (Soumya) Follow up with liming on the features requested by Sean listed here<https://edk2.groups.io/g/devel/message/55621?p=,,,20,0,0,0::Created,,community+meeting,20,2,0,71766249>

2. Discussion around Bugzilla - Liming to explore adding more detailed information on bugzilla wiki page

3. Governance and the process: Intel (Mike Kinney) has been evaluating the possibility of using git hub for the code review process. Expect RFCs in the month of early April.



Community Opens:

1. Rebecca - BHYVE support (need this by May). Rebecca to open a Bugzilla request. Community will evaluate.
2. Mike Kinney - we are using legacy GitBooks process/format. GitBooks will discontinue by end of April. We need to migrate our documents<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Draft-Specification> from legacy service to GitBooks current one. Mike Kinney will update the community on the migration status in the upcoming week. Mike will evaluate the migration tools for this migration and update the process.
3. We will be switching to zoom for all community meetings, please check the latest calendar on tianocore.



Acknowledgments:







Regards,

Soumya


Soumya Guptha
Open Source Program Manager, SFP/IAGS


Re: TianoCore Community Meeting tonight - Please note the time change reflecting daylight savings..

Soumya Guptha
 

Sorry, Correction.
The meeting is scheduled from 7.30pm-8.30pm (PST). Please note the time.
_____________________________________________
From: Guptha, Soumya K
Sent: Thursday, April 2, 2020 4:23 PM
To: 'announce@edk2.groups.io' <announce@edk2.groups.io>; devel@edk2.groups.io
Subject: TianoCore Community Meeting tonight - Please note the time change reflecting daylight savings..


Dear Community Members,
Please note the time change on tonight's TianoCore Community meeting, reflecting the US daylight savings time change as we moved clocks an hour earlier during March.

The community meeting will start from 7.30pm-8.30pm (PST).
You can view the calendar here - https://edk2.groups.io/g/devel/viewevent?repeatid=23293&eventid=700773&calstart=2020-04-16
Or use the invite below.

Thanks,
Soumya

-----Original Appointment-----
From: Gao, Liming
Sent: Wednesday, April 1, 2020 8:05 PM
To: Gao, Liming; Guptha, Soumya K
Cc: EDKII Package Maintainers
Subject: TianoCore Community Meeting - APAC/NAMO
When: Friday, April 3, 2020 10:30 AM-11:30 AM (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi.
Where: https://bluejeans.com/889357567?src=join_info


All edk2 package maintainers:
This is the monthly open source meeting. This one is on APAC time zone. Another one is on US time zone. Soumya chairs them both. If you want to know the latest information on open source edk2 project and community, you can join this meeting.

Meeting URL
https://bluejeans.com/889357567?src=join_info

Meeting ID
889 357 567

Want to dial in from a phone?

Dial one of the following numbers:
+1.408.740.7256 (US (San Jose))
+1.408.317.9253 (US (Primary, San Jose))
(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #


TianoCore Community Meeting tonight - Please note the time change reflecting daylight savings..

Soumya Guptha
 

Dear Community Members,
Please note the time change on tonight's TianoCore Community meeting, reflecting the US daylight savings time change as we moved clocks an hour earlier during March.

The community meeting will start from 6.30pm-7.30pm (PST).
You can view the calendar here - https://edk2.groups.io/g/devel/viewevent?repeatid=23293&eventid=700773&calstart=2020-04-16
Or use the invite below.

Thanks,
Soumya

-----Original Appointment-----
From: Gao, Liming
Sent: Wednesday, April 1, 2020 8:05 PM
To: Gao, Liming; Guptha, Soumya K
Cc: EDKII Package Maintainers
Subject: TianoCore Community Meeting - APAC/NAMO
When: Friday, April 3, 2020 10:30 AM-11:30 AM (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi.
Where: https://bluejeans.com/889357567?src=join_info


All edk2 package maintainers:
This is the monthly open source meeting. This one is on APAC time zone. Another one is on US time zone. Soumya chairs them both. If you want to know the latest information on open source edk2 project and community, you can join this meeting.

Meeting URL
https://bluejeans.com/889357567?src=join_info

Meeting ID
889 357 567

Want to dial in from a phone?

Dial one of the following numbers:
+1.408.740.7256 (US (San Jose))
+1.408.317.9253 (US (Primary, San Jose))
(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #


TianoCore Community Design Meeting Minutes - Mar 25, 2020 (extended)

Ni, Ray
 

Topic:

1. RISC-V EDK2 Port with OpenSBI Architecture (Abner Chang/HPE)

Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0325/RISC-V%20EDK2%20Port%20Design%20Architecture.pptx

Abner showed the overall picture of how to enable open SBI in edk2. Discussion was started from a DxeIpl dependency issue.

1. Goal and plans (page #2)

Development work is in phase 1 now. Two RISC-V platforms are to be enabled.

Daniel Schaefer (HPE German) is working on phase 2 (OS boot enabling).

Phase 3 will provide wrapper protocol over OpenSBI for PEI/DXE modules.

2. OpenSBI Introduction (page #3)

HART = hardware thread; ZSBL = Zero Stage Bootloader; FSBL = First Stage Bootloader; OpenSBI = RISC-V Open Source Supervisor Binary Interface.

Four privilege modes: Machine, Supervisor, Hypervisor (it was not listed in minutes, a mistake.), User. Hypervisor mode is for virtualization only and reserved now.

Generally, firmware runs in Machine mode and operation system runs in Supervisor mode. Linux can run in Machine mode.

Initial mode after power on is Machine mode.

OS calls OpenSBI through "ecall" CPU instruction, like "sysenter" in x86.

3. Principle of using OpenSBI in edk2 (page #4)

@Mike: Why "Build OpenSBI from edk2 build environment" is required? It can be built in its own environment.
@Abner: Try to make developers' life easy.
@Mike: OpenSBI change may cause build issue in EDKII. Separate eco, separate build environment.
@Abner: OpenSBI community is very supportive and we are working very closely.

4. Integration of OpenSBI library in edk2 (page #5)

@Mike: it's not a real library that can be linked to multiple modules. It's a firmware that provides services before edk2. It's complicated to figure out the relationship between OpenSBI and edk2.
@Leif: Agree. Natural of RISC-V is to cause less pain.

5. OpenSBI with uBoot (page #6)

​ Today's RISC-V firmware jumps from OpenSBI from M mode to uBoot in S mode then to OS.

6. OpenSBI with edk2 (page #7)

@Ray: uBoot flow looks cleaner that doesn't require call internal APIs such as opensbi_init(). Why not switch to S mode in beginning of EDK2 flow?
@Mike: All architectures have the trend to enable paging in PEI to have more protections. You can start S mode in PEI and create static library to wrapper "ecall" to OpenSBI as uBoot.
@Abner: OpenSBI interface doesn't provide support to change MTRR which may be required in HW initialization.
@Ard: PEI in M mode and DXE in S mode may have different requirements to PE loader and dispatcher.
@Mike: Can follow ARM way that PE loader and dispatcher always run in S mode. individual module can go back to M mode.
@Abner: Agree to put PEI in S mode and have protocol to switch to M mode.

7. UefiCpuPkg content criteria

Abner wants to confirm that UefiCpuPkg will contain all CPU architectures content and ARM content will be moved to UefiCpuPkg. Mike will start email discussions on this topic in community.


TianoCore Community Design Meeting Minutes - Mar 20, 2020

Ni, Ray
 

Topic:

1. EDK2 DxeIpl Abstraction (Abner Chang/HPE)

Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf



Today's meeting was extended to 2 hours to discuss the overall RISC-V support in EDKII. It makes sense because low-level design depends on the finalize of high-level design.

Today's RISC-V enabling in EDKII work is to provide a UEFI wrapper over RISC-V OpenSBI (Open Source Supervisor Binary Interface), which is an open-source reference implementation (https://github.com/riscv/opensbi) of RISC-V SBI specification (https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc).

OpenSBI itself is a boot loader. If RISC-V SBI specification is treated as UEFI spec and OpenSBI is treated as the EDKII.

Right now, Abner's work is the only effort that enables UEFI in RISC-V platforms.

The EDKII RISC-V environment consists of three phases: SEC-PEI-DXE. A RISC-V specific SEC module statically linked with OpenSBI exposes all interfaces required by the UEFI wrapper.

There are 3 sub-topics discussed in the meeting:

1. Which mode DXE phase is running at?

RISC-V defines three privileged modes: Machine/Supervisor/User Mode.
SEC and PEI run in M mode and DXE can run either in M mode or S mode which is the platform's choice.
If DXE runs in S mode, some of the resources cannot be accessed.
UEFI spec says RISC-V only runs in M mode during post including DXE. Spec needs update.

2. How to resolve MdeModulePkg's dependency on RiscVPkg?

The dependency is because the M to S mode switch
Abner's solution tries to address this dependency issue by introducing another abstract layer. (see slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf)
Mike proposes another solution: RiskVPkg exposes the mode switch interfaces (sbi_init ?) through PPI and the PPI definition can be in MdePkg which might be included by PI spec.

3. Location of RiscVPkg and RiscVPlatformPkg

RiscVPkg in @edk2-platforms/Silicon/... directory.
RiscVPlatformPkg in @edk2-platforms/Platform/... directory.
Long term goal is to put all CPU implementation that follows industry standard to UefiCpuPkg, including ARM and RISC-V.

4. Which changes can be in edk2

Need Abner to look at all the changes again. But at least the INF/C changes that enable individual drivers to be built by RISC-V compiler can.

Thanks,
Ray


TianoCore Community Design Meeting Minutes - Mar 6, 2020

Ni, Ray
 

Open

1. @Ray: Add two fields to VARIABLE_POLICY_ENTRY structure in the variable policy design for partial protection: Offset/Length. It may solve HPE's needs. Offset -1 indicates full variable protection.
@Sean: It might introduce more complexity since when more entries protect the same ranges. Need a way to have a determined priority for each one.
@Sunny: I will come back to discuss whether this feature can be added if it does solve HPE's needs.

2. @Ray: Will use Zoom for future meetings because the recent two meetings ran better (no delay) using Zoom.

Topic

1. New variable attribute: EFI_VARIABLE_FW_CONTROL
Presenter: Sunny Wang
Slides: [https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Libraries%20for%20Supporting%20UEFI%20Variable%20Resiliency.pdf](https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform Libraries for Supporting UEFI Variable Resiliency.pdf)

The new attribute is a way to inform OS whether a variable is controlled by a firmware.
BIOS sets this bit when the protection machanism is enabled to let OS to know.

@Sean: Curious about OSV's favor of this.
@Sunny: Haven't checked with any OSVs. Will bring to USWG for discussion.
@Sean: We don't always lock the variables. A new return status code would be helpful.
@Sunny: Error status code breaks OS functionality. New bit would be no harm to old OS. It's from backward compatibility consideration.
@Mike: Was ECR shared with USWG forum? Once you shared that, you cannot talk in the open source community any more. Leif proposed the code first process (https://edk2.groups.io/g/devel/message/53420). I suggest you discuss with HPE USWG rep about which way to go. Audio and PCIE spec change are doing in the code first process.
@Mike: Spec gives freedom to interfaces to return any error status. So there might be no backward compatibility issue if SetVariable() returns a new error status.
@Sean: OS may expect some pre-defined status code. Returning undefined status code causes OS complains something is wrong in the firmware in realworld. Expect the bit is set on the fly and not stored in the SPI storage.
@Sunny: This bit is set and success is returned. New value is returned in a immediate get. Value may be changed in next boot.
@Mike: What OS can do with this extra bit set?
@Sunny: Prompt to user that protection mechanism is enabled. Ask user to disable the protection for installation.
@Mike: It's a general feature can be applied to any variables. OS doesn't know what value will be set in next boot. It might be a terrible user experience. Why not SetVariable just returns error status to OS?
@Carl: Agree on forward looking when defining spec interfaces.
@Sunny: The bit is for the OS that cannot handle some error status. A WA for old OS.
@Mike: Firmware can verify the value OS sets and return success if the value is ok. Error is only returned when the value is not OK from firmware's perspective. Back to problem statement. OS wants to set BootOrder/Boot#### during installation. Firmware doesn't want OS to modify BootOrder. right?
@Sunny: right.

@Mike: UEFI spec has already considerred the case that OEM wants to run some code before booting to OS. SysPrep#### is defined in UEFI spec for this case.
@Sunny: SysPrep#### is only for boot case. There is some other platform security related variables.
@Mike: Complication appears because of no clear ownership with this new bit between firmware and OS. Try to remove this complication.
@Sean: Surface does have the feature to lock the Boot####/BootOrder.
@Mike: Suggest to evaluate SysPrep####
@Sunny: Sounds like a good idea to use SysPrep####. Will evaluate it.

Thanks,
Ray


Re: TianoCore Community Meeting Minutes - March

Sean
 

@Gao, Liming - here is my AR to list things desired for 2020 02 stable tag.

At minimum

2516 Tianocor Code sean.brogan@... CONF --- Add new package for XML support in Edk2 2020-02-20
2517 Tianocor Code sean.brogan@... CONF --- Add a target based unit test reporting library that outputs XML in a commonly accepted schema 2020-02-20
2522 Tianocor Code michael.d.kinney@... CONF --- Adopt VariablePolicy, Deprecate VarLock and VarCheckPolicy. 2020-02-20
2424 Tianocor Code yonghong.zhu@... UNCO --- TLSv1.3 support 2020-02-20
2513 EDK2 Code sean.brogan@... CONF --- HostBasedUnitTestRunner plugin only runs on Windows and thus HostUnitTests are only automatically run during CI on windows. Fix this by enabling Linux in plugin

And then at least these bugs

1871 EDK2 Code jian.j.wang@... IN_P --- OpensslLib should use proper entropy sources, not the timestamp counter
1463 EDK2 Code zhichao.gao@... CONF --- Exception with HeapGuard active and using FvSimpleFileSystemDxe
2506 EDK2 Code michael.d.kinney@... CONF --- When setting a new PK in setup mode, PK should not be required to be self-signed
2459 EDK2 Code michael.d.kinney@... UNCO --- Buffer double free caused use-after-free assert
2419 EDK2 Code michael.d.kinney@... CONF --- DisplayUpdateProgressLibGraphics should allow configuration of the background color.
2411 EDK2 Code jian.j.wang@... CONF --- heapguard.c faults when Use after free is enabled 2019-12-12
2416 EDK2 Code michael.d.kinney@... UNCO --- SMI generation IO port number is unsupported on AMD systems
2273 EDK2 Code siyuan.fu@... UNCO --- ip6ConfigReadConfigData causes an exception by accessing beyond the end of a read variable
1969 EDK2 Code dandan.bi@... CONF --- Report Status Code router issues related to handler dispatch at level lower than TPL_HIGH
1563 EDK2 Code jiaxin.wu@... CONF --- SnpDxe assumes Io/MemIo bar indices
1562 EDK2 Code jiaxin.wu@... CONF --- SnpDxe ExitBootServices handler should run at TPL_CALLBACK, not TPL_NOTIFY
1488 EDK2 Code jiaxin.wu@... CONF --- Events not closed on error paths
2094 EDK2 Code ard.biesheuvel@... UNCO --- PrePiLib: incorrect population of FV2 HOB FvName field
2029 EDK2 Code jian.j.wang@... CONF --- CryptoPkg Broken on MSVC after upgrade to 1.1.1b
1959 EDK2 Code liming.gao@... CONF --- BaseLib.h linked list macros should define "delete safe iterator loop" instead of having EFI_LIST_FOR_EACH_SAFE defined numerous places in edk2 code
2350 EDK2 Code michael.d.kinney@... UNCO --- Error when processing custom makefiles: CustomMakefile object has no attribute DependencyHeaderFileSet 2019-11-15
2351 EDK2 Code michael.d.kinney@... UNCO --- AutoGenWorker doesn't bubble up error status to main build script
2459 EDK2 Code michael.d.kinney@... UNCO --- Buffer double free caused use-after-free assert


Hope that helps.

Thanks
Sean

-----Original Message-----
From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Soumya Guptha via Groups.Io
Sent: Thursday, March 5, 2020 8:32 PM
To: announce@edk2.groups.io; devel@edk2.groups.io
Cc: announce@edk2.groups.io
Subject: [EXTERNAL] [edk2-announce] TianoCore Community Meeting Minutes - March

TianoCore Community Meeting Minutes
March 5, 2020

Stable Tag Updates:

1. Edk2 stable tag 202002 has been released: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Freleases%2Ftag%2Fedk2-stable202002&;data=02%7C01%7Csean.brogan%40microsoft.com%7C9361fdb850884f3d7fea08d7c187601f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637190659490667577&amp;sdata=zUfKzxMXqnHfim2zDCUzTd7YA5pe%2Fog8AnEFVS4%2ByNs%3D&amp;reserved=0

2. Edk2 stable tag 202005 feature planning has started.

* Features are listed in: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Release-Planning&;data=02%7C01%7Csean.brogan%40microsoft.com%7C9361fdb850884f3d7fea08d7c187601f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637190659490667577&amp;sdata=TGjI9N1xvWL0pz58NGO%2BI4HI0UvBfCvD%2BEwWd%2BMqVHw%3D&amp;reserved=0
Community Action: Please send if any feature requests that needs to be added to the upcoming stable tag release.
Opens:

1. Sean requested a few features (variable policy, TLS 1.3 etc.) for stable tag Q2 release. Sean will follow up with Liming on those features to get them added to Q2 stable tag.


2. Kevin - Need a fix in EDK2. Insyde engineers don't know where to start. Documentation is stale or assumes that you understand the open source project.

* Action: We discussed this issue. Kevin to follow the link - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Development-Process&;data=02%7C01%7Csean.brogan%40microsoft.com%7C9361fdb850884f3d7fea08d7c187601f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637190659490667577&amp;sdata=o6C36uSYZTbFWVbA9CctD%2BUUXUUlcGddWMn9hLadbck%3D&amp;reserved=0 , this should provide some guidance to the engineers on how to make a fix in EDK2.


3. Discussion around Bugzilla - Liming to explore adding more detailed information on bugzilla wiki page


TianoCore Bug Triage - APAC / NAMO Meeting time:

* Scheduled currently from 9:00 ~ 9:30 AM PRC time. Even after the US daylight saving during March, plan is to keep this meeting from 9:00~9:30AM PRC time. This time is working well and close to TianoCore Design Meeting, developers can plan their time and attend these two meetings together.

Community consensus received on the timeslot.

Events:
SPRING 2020 UEFI PLUGFEST<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuefi.org%2FSpring2020Plugfest&;data=02%7C01%7Csean.brogan%40microsoft.com%7C9361fdb850884f3d7fea08d7c187601f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637190659490667577&amp;sdata=oQdTtof682zr0lcS3xGcxlSYfJaFcE37sc8PjQVrn6I%3D&amp;reserved=0> has been postponed due to the Coronavirus situation. More details are published here - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuefi.org%2Fevents%2Fupcoming&;data=02%7C01%7Csean.brogan%40microsoft.com%7C9361fdb850884f3d7fea08d7c187601f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637190659490667577&amp;sdata=fEa3MDs%2FMJXmIXQCDzO16qJ1tMtBXYT0cpjFZs2lS8A%3D&amp;reserved=0

Community issues that were brought up last month on the governance and the process:

1. RFC: The RFC process seems to get only minimal comments and a lot gets lost in the noise of the lists. There isn't a good "final" state where all approved RFCs can be seen. The process is entirely driven by the submitter and thus there is little consistency. I wanted to highlight another project and how they handle this. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frust-lang%2Frfcs&;data=02%7C01%7Csean.brogan%40microsoft.com%7C9361fdb850884f3d7fea08d7c187601f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637190659490667577&amp;sdata=jqvd7YU%2FUxll5taVU7bk8kegfBxh6HIRWTszQFLM59Q%3D&amp;reserved=0 As a casual observer it is very easy to review their RFCs (in flight and approved/rejected) as well as understand how to create and submit one if so desired. The tooling is just git/github so it is familiar to the target audience and has a strong ability to track progress, show history, and be backed up like any code project. They also leverage github issue tracker for pre rfc conversation and discussions.

2. Bugs/Features/Releases: First the bug triage and scrub is not very well attended. I know it is hard to get a ww audience together on a call but i think part of the goal was to offer a public process and a place to learn/discuss. Is there a better way that still meets those goals? Secondly, the number of bugs that get discussed is pretty small and the list of open bugzillas are grower faster than the triage effort. Third, the results are pretty minimal. Usually a change in owner and a very short comment asking the owner to look at it is the result of the triage. There is sometimes good conversation (assuming knowledgeable parties are in attendance) but this is impractical to capture into the bugzilla while still keeping forward progress. Finally, as a submitter of a lot of open/unconfirmed bugs it is not very easy to understand the owners priorities and when the bug will be fixed and merged to master/stable tag. I am happy to contribute effort to making a new process but want to understand if others are frustrated by this as well.

Intel Response: We are evaluating the possibility of using git hub for the code review process. Expect RFCs in the month of March.

Regards,
Soumya

Soumya Guptha
Open Source Program Manager, Intel Corporation


EDK II Python development process specification -draft

Purma, Kondal R
 

Hi,

The draft specification for EDK II Python development process for presentation made earlier now available .

Presentation thread :

https://edk2.groups.io/g/announce/message/92

Wiki Page link for specification document:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Draft-Specification

GitBook link for specification document:
https://edk2-docs.gitbooks.io/edk-ii-python-development-process-speicfication

PDF version can be downloaded from:

https://legacy.gitbook.com/download/pdf/book/edk2-docs/edk-ii-python-development-process-speicfication

Draft version available for 2 week review period and seeking for feedback.

Thanks,
Kondal.


TianoCore Community Meeting Minutes - March

Soumya Guptha
 

TianoCore Community Meeting Minutes
March 5, 2020

Stable Tag Updates:

1. Edk2 stable tag 202002 has been released: https://github.com/tianocore/edk2/releases/tag/edk2-stable202002

2. Edk2 stable tag 202005 feature planning has started.

* Features are listed in: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
Community Action: Please send if any feature requests that needs to be added to the upcoming stable tag release.
Opens:

1. Sean requested a few features (variable policy, TLS 1.3 etc.) for stable tag Q2 release. Sean will follow up with Liming on those features to get them added to Q2 stable tag.


2. Kevin - Need a fix in EDK2. Insyde engineers don't know where to start. Documentation is stale or assumes that you understand the open source project.

* Action: We discussed this issue. Kevin to follow the link - https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process , this should provide some guidance to the engineers on how to make a fix in EDK2.


3. Discussion around Bugzilla - Liming to explore adding more detailed information on bugzilla wiki page


TianoCore Bug Triage - APAC / NAMO Meeting time:

* Scheduled currently from 9:00 ~ 9:30 AM PRC time. Even after the US daylight saving during March, plan is to keep this meeting from 9:00~9:30AM PRC time. This time is working well and close to TianoCore Design Meeting, developers can plan their time and attend these two meetings together.

Community consensus received on the timeslot.

Events:
SPRING 2020 UEFI PLUGFEST<https://uefi.org/Spring2020Plugfest> has been postponed due to the Coronavirus situation. More details are published here - https://uefi.org/events/upcoming

Community issues that were brought up last month on the governance and the process:

1. RFC: The RFC process seems to get only minimal comments and a lot gets lost in the noise of the lists. There isn't a good "final" state where all approved RFCs can be seen. The process is entirely driven by the submitter and thus there is little consistency. I wanted to highlight another project and how they handle this. https://github.com/rust-lang/rfcs As a casual observer it is very easy to review their RFCs (in flight and approved/rejected) as well as understand how to create and submit one if so desired. The tooling is just git/github so it is familiar to the target audience and has a strong ability to track progress, show history, and be backed up like any code project. They also leverage github issue tracker for pre rfc conversation and discussions.

2. Bugs/Features/Releases: First the bug triage and scrub is not very well attended. I know it is hard to get a ww audience together on a call but i think part of the goal was to offer a public process and a place to learn/discuss. Is there a better way that still meets those goals? Secondly, the number of bugs that get discussed is pretty small and the list of open bugzillas are grower faster than the triage effort. Third, the results are pretty minimal. Usually a change in owner and a very short comment asking the owner to look at it is the result of the triage. There is sometimes good conversation (assuming knowledgeable parties are in attendance) but this is impractical to capture into the bugzilla while still keeping forward progress. Finally, as a submitter of a lot of open/unconfirmed bugs it is not very easy to understand the owners priorities and when the bug will be fixed and merged to master/stable tag. I am happy to contribute effort to making a new process but want to understand if others are frustrated by this as well.

Intel Response: We are evaluating the possibility of using git hub for the code review process. Expect RFCs in the month of March.

Regards,
Soumya

Soumya Guptha
Open Source Program Manager, Intel Corporation


Re: [edk2-devel] EDK II Stable Tag release edk2-stable202002 completed

Laszlo Ersek
 

On 03/05/20 06:53, Gao, Liming wrote:
Laszlo:
Got them. I have added them all in the feature planning. Please help check.
Thank you, it looks good!
Laszlo


Re: [edk2-devel] EDK II Stable Tag release edk2-stable202002 completed

Liming Gao
 

Laszlo:
Got them. I have added them all in the feature planning. Please help check.

Thanks
Liming

-----Original Message-----
From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Thursday, March 5, 2020 2:24 AM
To: devel@edk2.groups.io; Gao, Liming <liming.gao@...>; announce@edk2.groups.io
Cc: Guptha, Soumya K <soumya.k.guptha@...>; Kinney, Michael D <michael.d.kinney@...>; afish@...;
leif@...; Ard Biesheuvel <ard.biesheuvel@...>; Liran Alon <liran.alon@...>; Nikita Leshenko
<nikita.leshchenko@...>
Subject: Re: [edk2-announce] [edk2-devel] EDK II Stable Tag release edk2-stable202002 completed

Hi Liming,

On 03/04/20 10:03, Liming Gao wrote:

If you have ideas for features in the next stable tag, please enter a
Bugzilla for evaluation. Please let me know if there are existing
open Bugzilla entries that should be targeted at this next stable
tag.
Apologies for responding for the third time in a day, to the same call
from you :) It's not easy to keep all the sudden virtualization-related
feature request BZs :)

So please include the following three RFEs too, from Ard:
- https://bugzilla.tianocore.org/show_bug.cgi?id=2560
- https://bugzilla.tianocore.org/show_bug.cgi?id=2564
- https://bugzilla.tianocore.org/show_bug.cgi?id=2566

(So in total we have 6 ArmVirt / OVMF BZs planned, at this moment, for
the next stable tag: 2560, 2564, 2566 from Ard; 2390 and 2567 from Liran
and Nikita at Oracle; and 1512 from yours truly.)

Thank you!
Laszlo



Re: [edk2-devel] EDK II Stable Tag release edk2-stable202002 completed

Laszlo Ersek
 

Hi Liming,

On 03/04/20 10:03, Liming Gao wrote:

If you have ideas for features in the next stable tag, please enter a
Bugzilla for evaluation. Please let me know if there are existing
open Bugzilla entries that should be targeted at this next stable
tag.
Apologies for responding for the third time in a day, to the same call
from you :) It's not easy to keep all the sudden virtualization-related
feature request BZs :)

So please include the following three RFEs too, from Ard:
- https://bugzilla.tianocore.org/show_bug.cgi?id=2560
- https://bugzilla.tianocore.org/show_bug.cgi?id=2564
- https://bugzilla.tianocore.org/show_bug.cgi?id=2566

(So in total we have 6 ArmVirt / OVMF BZs planned, at this moment, for
the next stable tag: 2560, 2564, 2566 from Ard; 2390 and 2567 from Liran
and Nikita at Oracle; and 1512 from yours truly.)

Thank you!
Laszlo


Re: [edk2-devel] EDK II Stable Tag release edk2-stable202002 completed

Laszlo Ersek
 

Hi Liming,

On 03/04/20 10:03, Liming Gao wrote:

If you have ideas for features in the next stable tag, please enter a Bugzilla for evaluation. Please let me know if there are existing open Bugzilla entries that should be targeted at this next stable tag.
Can you please include (in the plan for edk2-stable202005):
- https://bugzilla.tianocore.org/show_bug.cgi?id=2390
- https://bugzilla.tianocore.org/show_bug.cgi?id=2567

Thanks!
Laszlo


Re: EDK II Stable Tag release edk2-stable202002 completed

Laszlo Ersek
 

On 03/04/20 10:03, Gao, Liming wrote:
Hi, all

The tag edk2-stable202002 has been created. https://github.com/tianocore/edk2/releases/tag/edk2-stable202002
git clone -b edk2-stable202002 https://github.com/tianocore/edk2.git

The tag edk2-stable202002 has been added into the main EDK II Wiki page.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II

The quiet period has now ended. Thank you for your cooperation and patience. Normal commits can now be resumed.

Next edk2 stable tag (edk2-stable202005) planning has been added into wiki page.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.

If you have ideas for features in the next stable tag, please enter a Bugzilla for evaluation. Please let me know if there are existing open Bugzilla entries that should be targeted at this next stable tag.
I've included <https://bugzilla.tianocore.org/show_bug.cgi?id=1512> (for
which I've just merged the patches).

Thanks
Laszlo


EDK II Stable Tag release edk2-stable202002 completed

Liming Gao
 

Hi, all

The tag edk2-stable202002 has been created. https://github.com/tianocore/edk2/releases/tag/edk2-stable202002
git clone -b edk2-stable202002 https://github.com/tianocore/edk2.git

The tag edk2-stable202002 has been added into the main EDK II Wiki page.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II

The quiet period has now ended. Thank you for your cooperation and patience. Normal commits can now be resumed.

Next edk2 stable tag (edk2-stable202005) planning has been added into wiki page.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.

If you have ideas for features in the next stable tag, please enter a Bugzilla for evaluation. Please let me know if there are existing open Bugzilla entries that should be targeted at this next stable tag.

Thanks
Liming


EDK II Stable Tag edk2-stable202002 will be created based on commit 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70

Liming Gao
 

Hi, all
edk2-stable202002 tag will be created on Mar 4th (UTC-8 00:00:00). It will base on current edk2 trunk (the latest commit https://github.com/tianocore/edk2/commit/4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70 UefiCpuPkg/MpInitLib: Skip reading PlatformId on AMD processors). If you have any comments, please reply the mail. If no concern or objection, I will create tag and send another announce mail that edk2-stable202002 is completed and normal commit is resumed.

Thanks
Liming


Re: Extend Hard Feature Freeze by a few days for edk2-stable202002

Liming Gao
 

Hi, all
Thanks for your patience. Based on the discussion https://edk2.groups.io/g/devel/message/55092, edk2-stable202002 tag will be created on Mar 4th (UTC ? 8 00:00:00). Once the tag is created, I will send the announcement.

Thanks
Liming

-----Original Message-----
From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Liming Gao
Sent: 2020年2月28日 16:23
To: announce@edk2.groups.io; devel@edk2.groups.io
Cc: Guptha, Soumya K <soumya.k.guptha@...>; Kinney, Michael D <michael.d.kinney@...>; afish@...; Laszlo Ersek <lersek@...>; leif@...
Subject: [edk2-announce] Extend Hard Feature Freeze by a few days for edk2-stable202002

Hi, all
Yesterday, one critical issue was reported. Its fix required more time to be reviewed and verified. Here is the discussion https://edk2.groups.io/g/devel/message/55047. So, two stewards suggested to extend Hard Feature Freeze by a few days. Now, we are still in Hard Feature Freeze phase until edk2-stable202002 tag is created. Once the release date is decided, I will send the announcement. Please keep patience, normal commits will come soon.

Thanks
Liming


Extend Hard Feature Freeze by a few days for edk2-stable202002

Liming Gao
 

Hi, all
Yesterday, one critical issue was reported. Its fix required more time to be reviewed and verified. Here is the discussion https://edk2.groups.io/g/devel/message/55047. So, two stewards suggested to extend Hard Feature Freeze by a few days. Now, we are still in Hard Feature Freeze phase until edk2-stable202002 tag is created. Once the release date is decided, I will send the announcement. Please keep patience, normal commits will come soon.

Thanks
Liming


TianoCore Community Design Meeting Minutes - Feb 21, 2020

Ni, Ray
 

OPEN:
Today's meeting is using Zoom because of the long latency using BlueJeans.
The URL to join meeting is changed. Make sure to check https://edk2.groups.io/g/devel/calendar for details.
We will try Zoom for next meeting as well. If everything is good, we will continue to use Zoom.

1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE)
Presenter: Sunny Wang
Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Libraries%20for%20Supporting%20UEFI%20Variable%20Resiliency.pdf

Problem: Support UEFI variable resiliency to compliant to security related guidelines and requirements. #page 2

Locking BootOrder causes issues in OSes which is not acceptable.
EDKII is lack of interfaces for adding platform variable protection.
Today's presentation is to propose a solution.
Basic rule of how variable resiliency manages BootOrder changes: #5-#6
- Put down untrusted changes
- Keep trusted changes

@Mike: Where is the reference data stored?
@Sunny: In BMC.

<Can variable policy protocol help?>
@Mike: Would like to see a small enhancement in variable policy protocol proposed by Microsoft to meet your case.
@Sunny: I checked the variable policy proposal by Microsoft. Using that might be complicated.
@Sean: We (Microsoft) have looked this. Variable hook in DXE phase not in SMM is a security hole. Don't like the way of managing BootOrder by allowing OS to change BootOrder and reverting. Boot#### may contain critical data for OS and reverting that may cause troubles.
@Sunny: I cannot think of solutions for OS runtime change.

<Problem discussion>
@Mike: I would break the big problem to 3 smaller ones:
1. variable data corruption
It requires a way to detect corruption and recovery.
2. critical platform variables
It usually requires a lock mechanism and variable policy proposal is more general for this protection.
3. UEFI variables with multiple producers
How to protect them could be a topic for USWG.
@Sean: The scope of the problem discussed in this presentation is huge. Can a platform module run at a different point of time to manage the variable storage instead of using hook way?
@Sunny: BootOrder is just one of the variables that need protection.

<Can using a separate platform module instead of hooking help?>
@Mike: Using a separate platform module might be better because it will also check the variables not changed by firmware.
@Sean: PEI modules may access the wrong data modified by untrusted entity.
@Ray: Is the protection based on not just the variable GUID/name, but also who requests the change?
@Sunny: Yes. Following sides (#page 10+) will talk about protection from non-trusted entity.
@Ray: Let's move to email discussion first. Identify the scope of the problem first.

Thanks,
Ray

161 - 180 of 289