Sorry for not making any progress since last meeting.
Sure! I will work on enhancing the variable policy to support partial 
protection and recovery. However, the update will be late because I need to 
first deal with other urgent stuff.
By the way, thanks for giving a lot of valuable comments at our offline 
discussion, Ray.  :)

Regards,
Sunny Wang

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni, Ray
Sent: Wednesday, March 4, 2020 11:46 AM
To: Sean Brogan <sean.bro...@microsoft.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Wang, Sunny (HPS SW) <sunnyw...@hpe.com>
Cc: Ni, Ray <ray...@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 
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: annou...@edk2.groups.io <annou...@edk2.groups.io> On Behalf Of 
> Ni, Ray
> Sent: Friday, February 21, 2020 5:17 PM
> To: annou...@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:
> INVALID URI REMOVED
> devel_files_Designs_2020_0221_Platform-2520Libraries-2520for-2520Suppo
> rting-2520UEFI-2520Variable-25&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9c
> LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=U5okqrn3H585vxU4GwALnIBwi0s
> 0dQ0hYIDuFj2z-4Y&s=oG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e=
> 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 (#55356): https://edk2.groups.io/g/devel/message/55356
Mute This Topic: https://groups.io/mt/71718822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to