Date 1 - 1 of 1
TianoCore Community Design Meeting Minutes - Feb 21, 2020
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
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.
@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.
|1 - 1 of 1|