public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Bret Barkelew" <bret.barkelew@microsoft.com>
To: Yao, Jiewen <jiewen.yao@intel.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative
Date: Thu, 06 Feb 2020 22:00:05 -0800	[thread overview]
Message-ID: <15873.1581055205006059831@groups.io> (raw)
In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F918A9C@shsmsx102.ccr.corp.intel.com>

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

I agree with you that this function is extremely sensitive and important, and I kinda like your idea of splitting the protocol into a "policy" and "policy control", but I don't think it make practical sense to split them this way. At the very least, you end up with a chicken and egg problem where we would need to read mfg state to decide whether we need to publish the other protocol, but mfg state would also determine whether we used the protocol to disable the protection.

Furthermore, there may be architectural (e.g. off-Soc) implementations of this that would still require a "lock" signal to disable their ability to receive the disable command. These solutions wouldn't have a concept of building with a "I want more security" PCD.

Our recommendation would be to make sure that "lock" is called prior to leaving TCB, similar to SMM or other hardware locks (which the platform already has to coordinate).

Two points to help manage this:
1) We would be willing to discuss adding a HSTI bit or DeviceState flag to indicate to an OS or attestation authority that the protections are disabled for the current boot.
2) We would recommend running the VarLockAudit test that we've provided with the release to make sure that not only are protections enabled, but the parameters of your policies are configured the way the platform wants them. It was very useful to us when trying to understand the overall system state we wanted.
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra/UefiTestingPkg/AuditTests/UefiVarLockAudit

Looking forward to your thoughts.
Thanks!
- Bret

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

  reply	other threads:[~2020-02-07  6:00 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
     [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           ` Bret Barkelew [this message]
2020-02-07  8:19             ` [edk2-devel] " 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=15873.1581055205006059831@groups.io \
    --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