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