[edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020
Ni, Ray
ray.ni at intel.com
Wed Mar 4 03:46:03 UTC 2020
Variable policy works well on protecting a whole variable.
But the BootOrder in Sunny's case may require a partial protection, which means portion of the variable buffer needs to be read-only.
Today's variable policy proposal doesn't take this into consideration.
If we could enhance variable policy to support partial protection, @Sunny can you please check whether it can meet your requirement?
The enhancement I think of is: Introduce two fields to the policy structure Offset and Length.
Offset (-1) indicates a whole variable protection.
Offset (>= 0) indicates a partial variable protection and the protection range starts from Offset with Length bytes.
This enhancement is also useful when some policy fields inside a big policy structure needs to be read-only.
Protecting multiple discontinuous ranges of a variable can be achieved by adding multiple policy entries with different Offset/Length.
Thanks,
Ray
> -----Original Message-----
> From: announce at edk2.groups.io <announce at edk2.groups.io> On Behalf Of Ni, Ray
> Sent: Friday, February 21, 2020 5:17 PM
> To: announce at edk2.groups.io
> Subject: [edk2-announce] TianoCore Community Design Meeting Minutes - Feb 21, 2020
>
> 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
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55355): https://edk2.groups.io/g/devel/message/55355
Mute This Topic: https://groups.io/mt/71718822/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list