Re: TianoCore Community Design Meeting Minutes - Feb 21, 2020

Re: TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Ni, Ray]

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@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Ni, Ray
> Sent: Friday, February 21, 2020 5:17 PM
> To: announce@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
> 
> 

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Wang, Sunny (HPS SW)]

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.brogan@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Ni, Ray <ray.ni@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: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of 
> Ni, Ray
> Sent: Friday, February 21, 2020 5:17 PM
> To: announce@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
> 
> 

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Ni, Ray]

Sunny,
Let's discuss in this week's meeting to see whether the below enhancement proposal can be aligned first.

Thanks,
Ray

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Wang, Sunny (HPS SW)
> Sent: Wednesday, March 4, 2020 12:12 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Sean Brogan <sean.brogan@microsoft.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Wei, Kent (HPS SW) <kent.wei@hpe.com>; Spottswood, Jason
> <jason.spottswood@hpe.com>
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020
> 
> 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.brogan@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Sunny (HPS SW)
> <sunnywang@hpe.com>
> Cc: Ni, Ray <ray.ni@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: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of
> > Ni, Ray
> > Sent: Friday, February 21, 2020 5:17 PM
> > To: announce@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
> >
> >
> 
> 
> 
> 
> 
> 

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Wang, Sunny (HPS SW)]

Sure!

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 3:26 PM
To: devel@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Sean Brogan <sean.brogan@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Spottswood, Jason <jason.spottswood@hpe.com>
Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

Sunny,
Let's discuss in this week's meeting to see whether the below enhancement proposal can be aligned first.

Thanks,
Ray

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Wang, 
> Sunny (HPS SW)
> Sent: Wednesday, March 4, 2020 12:12 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Sean Brogan 
> <sean.brogan@microsoft.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Wei, Kent (HPS SW) 
> <kent.wei@hpe.com>; Spottswood, Jason <jason.spottswood@hpe.com>
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - 
> Feb 21, 2020
> 
> 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.brogan@microsoft.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
> Cc: Ni, Ray <ray.ni@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: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of 
> > Ni, Ray
> > Sent: Friday, February 21, 2020 5:17 PM
> > To: announce@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-2520Sup
> > po 
> > rting-2520UEFI-2520Variable-25&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z
> > 9c 
> > LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=U5okqrn3H585vxU4GwALnIBwi
> > 0s 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
> >
> >
> 
> 
> 
> 
> 
> 

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Wang, Sunny (HPS SW)]

Hi Mike, Sean, and Ray, 

A BIG thanks to you guys. It was really good to have the EDK2 design meetings to talk to you guys. I got a lot of valuable feedback from you guys. The following are what I got from today's meeting and the follow-up I will do. Feel free to let me know anything I missed or misunderstood. 
    1. Use SystemPrep#### and lock them to protect the boot priority of the target boot options. This is really a good idea. I will further check this. 
    2. Partially lock - No real use case at this moment. The only real use case is BootOrder. Therefore, I may not work on this until we find a real case.
    3. For protecting other critical variables, locking them won't cause any problem with OS, so let's use variable lock (variable policy) for them.
    4. For recovering other critical variables, we can have a platform code to check and recover them at a specific timing before locking them. If you guys think adding the recovery mechanism into the variable policy is a good idea, let me know. I will look into this.
    5. As for the new variable attribute bit, we don't need it because of no use case at this moment either. OS can check SystemPrep#### instead and show the message to users.

Regards,
Sunny Wang

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Wang, Sunny (HPS SW)
Sent: Wednesday, March 4, 2020 3:53 PM
To: devel@edk2.groups.io; ray.ni@intel.com; Sean Brogan <sean.brogan@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Spottswood, Jason <jason.spottswood@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

Sure!

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 3:26 PM
To: devel@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Sean Brogan <sean.brogan@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Spottswood, Jason <jason.spottswood@hpe.com>
Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

Sunny,
Let's discuss in this week's meeting to see whether the below enhancement proposal can be aligned first.

Thanks,
Ray

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Wang, 
> Sunny (HPS SW)
> Sent: Wednesday, March 4, 2020 12:12 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Sean Brogan 
> <sean.brogan@microsoft.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Wei, Kent (HPS SW) 
> <kent.wei@hpe.com>; Spottswood, Jason <jason.spottswood@hpe.com>
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - 
> Feb 21, 2020
> 
> 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.brogan@microsoft.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
> Cc: Ni, Ray <ray.ni@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: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of 
> > Ni, Ray
> > Sent: Friday, February 21, 2020 5:17 PM
> > To: announce@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-2520Sup
> > po
> > rting-2520UEFI-2520Variable-25&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z
> > 9c
> > LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=U5okqrn3H585vxU4GwALnIBwi
> > 0s 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
> >
> >
> 
> 
> 
> 
> 
>