From: "Wang, Sunny (HPS SW)" <sunnywang@hpe.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"ray.ni@intel.com" <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
Date: Wed, 4 Mar 2020 07:52:31 +0000 [thread overview]
Message-ID: <DF4PR8401MB0585908BE7AA206CC284D31CA8E50@DF4PR8401MB0585.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C47A6B3@SHSMSX104.ccr.corp.intel.com>
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
> >
> >
>
>
>
>
>
>
next prev parent reply other threads:[~2020-03-04 7:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <15F5603A467A59A4.15709@groups.io>
2020-03-04 3:46 ` TianoCore Community Design Meeting Minutes - Feb 21, 2020 Ni, Ray
2020-03-04 4:11 ` [edk2-devel] " Wang, Sunny (HPS SW)
2020-03-04 7:25 ` Ni, Ray
2020-03-04 7:52 ` Wang, Sunny (HPS SW) [this message]
[not found] ` <15F90A9131621A63.2806@groups.io>
2020-03-06 3:16 ` Wang, Sunny (HPS SW)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DF4PR8401MB0585908BE7AA206CC284D31CA8E50@DF4PR8401MB0585.NAMPRD84.PROD.OUTLOOK.COM \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox