public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"bret.barkelew@microsoft.com" <bret.barkelew@microsoft.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>
Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative
Date: Wed, 5 Feb 2020 12:58:03 +0000	[thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F91480C@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <CY4PR21MB0743AEB168EFF09EF1D22B72EF030@CY4PR21MB0743.namprd21.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 4551 bytes --]

HI Bret
Thanks for the work. The design doc is very good.

Some feedback/questions below:


  1.  We have 2 variable related protocol - EDKII_VARIABLE_LOCK_PROTOCOL and EDKII_VAR_CHECK_PROTOCOL. Do you want to deprecate both? Or only deprecate EDKII_VARIABLE_LOCK_PROTOCOL?
  2.  The Function - DumpVariablePolicy() - makes me confused in the beginning. In my thought, "Dump" means to show some debug message. But here, you want to return the policy. Can we change the name to GetVariablePolicy()?
  3.  The function - DisableVariablePolicy(). Does it disable current policy engine? Does it disable any future policy engine? Does it block RegisterVariablePolicy() call?
  4.  The function - LockVariablePolicy() - Can it lock the DisableVariablePolicy() call?
  5.  The use case "In MFG Mode Variable Policy Engine is disabled, thus these VPD variables can be created. These variables are locked with lock policy type LockNow, so that these variables can't be tampered with in Customer Mode."

This seems a perfect potential attack point. If the attacker wants to modify a read-only variable. He or she may trigger the MFG mode, then no variable is locked. Then the attacker can update the RO variable then reset the system to normal mode. Is that threat considered?

Thank you
Yao Jiewen


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via Groups.Io
Sent: Tuesday, February 4, 2020 4:08 PM
To: devel@edk2.groups.io; rfc@edk2.groups.io
Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

Expanding the audience beyond the RFC list....
If no one has additional input, I'll try to start formatting these as patches later this week. Thanks!

- Bret

From: Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Sent: Tuesday, January 28, 2020 5:36 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Subject: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

All,

VariablePolicy is our proposal for an expanded "VarLock-like" interface to constrain and govern platform variables.
I brought this up back in May to get initial comments on the interface and implications of the interface and the approach. We implemented it in Mu over the summer and it is not our defacto variable solution. It plugs in easily to the existing variable infrastructure, but does want to control some of the things that are currently managed by VarLock.

There are also some tweaks that would be needed if this were desired to be 100% optional code, but that's no different than the current VarLock implementation which has implementation code directly tied to some of the common variable code.

I've structured this RFC in two pieces:

  *   The Core piece represents the minimum changes needed to implement Variable Policy and integrate it into Variable Services. It contains core driver code, central libraries and headers, and DXE driver for the protocol interface.
  *   The Extras piece contains recommended code for a full-feature implementation including a replacement for the VarLock protocol that enables existing code to continue functioning as-is. It also contains unit and integration tests. And as a bonus, it has a Rust implementation of the core business logic for Variable Policy.

The code can be found in the following two branches:
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra

A convenient way to see all the changes in one place is to look at a comparison:
https://github.com/corthon/edk2/compare/master...corthon:personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc_core...corthon:personal/brbarkel/var_policy_rfc_extra

There's additional documentation in the PPT and DOC files in the core branch:
https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Proposal%20Presentation.pptx https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Whitepaper.docx
(You'd need to download those to view.)

My ultimate intention for this is to submit it as a series of patches for acceptance into EDK2 as a replacement for VarLock. For now, I'm just looking for initial feedback on any broad changes that might be needed to get this into shape for more detailed code review on the devel list.

Thanks!

- Bret




[-- Attachment #2: Type: text/html, Size: 17223 bytes --]

  parent reply	other threads:[~2020-02-05 12:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CY4PR21MB0743C5076F418E1E53646FBFEF050@CY4PR21MB0743.namprd21.prod.outlook.com>
2020-02-04  8:07 ` [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative Bret Barkelew
2020-02-04 23:28   ` [edk2-devel] " Kevin@Insyde
2020-02-06  5:18     ` [EXTERNAL] " Bret Barkelew
2020-02-05 12:58   ` Yao, Jiewen [this message]
     [not found]     ` <26732.1581025767115155527@groups.io>
     [not found]       ` <74D8A39837DF1E4DA445A8C0B3885C503F918A49@shsmsx102.ccr.corp.intel.com>
2020-02-06 22:15         ` [edk2-rfc] " Yao, Jiewen
2020-02-07  6:00           ` [edk2-devel] " Bret Barkelew
2020-02-07  8:19             ` Yao, Jiewen
2020-02-07 10:44 ` 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=74D8A39837DF1E4DA445A8C0B3885C503F91480C@shsmsx102.ccr.corp.intel.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